From jlaurens@cisco.com Sun Feb 2 14:02: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 517751A010E for ; Sun, 2 Feb 2014 14:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 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, RP_MATCHES_RCVD=-0.535, 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 gV-T1VQK0Vom for ; Sun, 2 Feb 2014 14:02:22 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9231A00E8 for ; Sun, 2 Feb 2014 14:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15363; q=dns/txt; s=iport; t=1391378538; x=1392588138; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qbCAp89DVJfFA8RiH6/HOx1WtdWmQso6WkQxZKo+Bxw=; b=Af90GyHb9AxbpxhX5wJWW6DtciEVz1WHetzjJpWCM/R6wzbl9+JDcEXw kGCp2ezYQxS8JMQAJ9cuhXCGSwyvZW1Q4bTGZHEn3usCf7SDKRlTdBMZD JJ56aaKh3hEdXTp1Lca0PoyfGmpaGJJBlAQZcFxZgL1yALTv33sZRiZv0 k=; X-Files: smime.p7s : 4459 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAGK/7lKtJV2c/2dsb2JhbABagww4V71DT4EBFnSCJQEBAQIBAQEBAWsLEAIBCA44AiULJQIEDgUJBYdvCA3MIBeOOAEBTweDJIEUBJA/gTKGOZIhgy2BcTk X-IronPort-AV: E=Sophos;i="4.95,767,1384300800"; d="p7s'?scan'208,217";a="301321305" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 02 Feb 2014 22:02:17 +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 s12M2H1c012994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 2 Feb 2014 22:02:17 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.52]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Sun, 2 Feb 2014 16:02:17 -0600 From: "Jeremy Laurenson (jlaurens)" To: Cullen Jennings Thread-Topic: [rtcweb] Video codecs and the staw poll Thread-Index: AQHPIGJvWwji5s2uuECqN+RDdMY5sg== Date: Sun, 2 Feb 2014 22:02:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.245.71] Content-Type: multipart/signed; boundary="Apple-Mail=_30CDF2B8-13AD-4AF5-8573-39F25E206704"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs and the staw poll X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Feb 2014 22:02:24 -0000 --Apple-Mail=_30CDF2B8-13AD-4AF5-8573-39F25E206704 Content-Type: multipart/alternative; boundary="Apple-Mail=_0AC77AAB-6BA0-49BB-8456-CCE94B740894" --Apple-Mail=_0AC77AAB-6BA0-49BB-8456-CCE94B740894 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 Silence is golden=20 On Jan 28, 2014, at 12:13 AM, Cullen Jennings wrote: >=20 > Dear WG, >=20 > After reviewing the poll results found here: = http://www.ietf.org/mail-archive/web/rtcweb/current/pdfWd2PIhOY9y.pdf = the chairs concludes that the working group still believes that an MTI = is required for the WebRTC ecology to develop. There are a number of = options which did not garner significant support; essentially only = options 1, 2, 3, 4 seem to have enough support that they might be the = eventual basis of working group consensus. The chairs do not view the = other options as having sufficient support to warrant further working = group activity or discussion. >=20 > There is no obvious leader between VP8 and H.264, however, nor obvious = support for selecting both. Each has similar numbers of supporting = positions and objections, and both have the support of well over half = the participants in the straw poll. Given that, we are no closer to = being able to choose between them at this time. =20 >=20 > The chairs therefore propose tabling the discussion of a mandatory to = implement video codec until about 6 week before the start of the IETF 91 = meeting in November 2014. This is so that the working group can focus = its energy on completing other work. We do expect to begin work on the = video document (draft-ietf-rtcweb-video) to meet its milestone of = December, but initially without specifying which of the two codecs is = the WG consensus for MTI. >=20 > When we return to the discussion, the working group chairs currently = expect to run a consensus call on support for each codec to be mandatory = to implement. This expectation may change, however, based on new = information or working group experience. >=20 > If anyone has concerns about tabling this discussion until September = 29, 2014 please let us know by February 4. >=20 > Thank you,=20 >=20 > Cullen, Magnus, Ted >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_0AC77AAB-6BA0-49BB-8456-CCE94B740894 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1
Silence is golden 


On Jan 28, 2014, at 12:13 AM, Cullen Jennings <fluffy@iii.ca> wrote:


Dear = WG,

After reviewing the poll results found here: http://www.ietf.org/mail-archive/web/rtcweb/current/pdfWd2PIhOY9y.pdf= the chairs concludes that the working group still believes that an = MTI is required for the WebRTC ecology to develop. =    There are a number of options which did not garner = significant support; essentially only options 1, 2, 3, 4 seem to have = enough support that they might be the eventual basis of working group = consensus.  The chairs do not view the other options as having = sufficient support to warrant further working group activity or = discussion.

There is no obvious leader between VP8 and H.264, = however, nor obvious support for selecting both.  Each has similar = numbers of supporting positions and objections, and both have the = support of well over half the participants in the straw poll. =  Given that, we are no closer to being able to choose between them = at this time.  

The chairs therefore propose tabling the = discussion of a mandatory to implement video codec until about 6 week = before the start of the IETF 91 meeting in November 2014. This is so = that the working group can focus its energy on completing other work. =  We do expect to begin work on the video document = (draft-ietf-rtcweb-video) to meet its milestone of December, but = initially without specifying which of the two codecs is the WG consensus = for MTI.

When we return to the discussion, the working group = chairs currently expect to run a consensus call on support for each = codec to be mandatory to implement.  This expectation may change, = however, based on new information or working group experience.

If = anyone has concerns about tabling this discussion until September 29, = 2014 please let us know by February 4.

Thank you,

Cullen, = Magnus, Ted <the = chairs>




____________________________________________= ___
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb

= --Apple-Mail=_0AC77AAB-6BA0-49BB-8456-CCE94B740894-- --Apple-Mail=_30CDF2B8-13AD-4AF5-8573-39F25E206704 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSTCCBkIw ggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIxMDgzMTIzNTk1OVowgaYxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQD Ey5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn/R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEi VzAhJZCao/SsKsaIF4ZhchN2LuwDyyebjyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+Dey xtmSSq5937hEH5u6P4wG/tgjT0hRI2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/ xhR7DtryBeTTgwKmxWlwtKnkVunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28 ODC7iCbDZ2ZmtLR3+cChxw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQAB o4ICRDCCAkAwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVy aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBS MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpo dHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAY BgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXECl4aATCB 8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZl cmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWdu IENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaPwdqbiPKzbE0fWC+6AVFddMFG6MO4 e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKMYJsrnGVJlMSiOCRIpVylUEto6WIip5Po mSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBiTe/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP9 5WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26tlcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4 OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXi dE0HbYQwggb/MIIF56ADAgECAhBMB51Pnvlk8cSmNt8H9SnjMA0GCSqGSIb3DQEBBQUAMIGmMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UE AxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEw MTEwMDAwMDBaFw0xNDEwMTIyMzU5NTlaMIHEMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQgLSAxMzgxNDg5MjU3Mzg2MSEwHwYJKoZIhvcNAQkBFhJqbGF1cmVuc0BjaXNjby5jb20xDzAN BgNVBAsMBlMvTUlNRTEeMBwGA1UECwwVUGVyc29uYSBOb3QgVmFsaWRhdGVkMR8wHQYDVQQLDBZT eW1hbnRlYyBUcnVzdCBOZXR3b3JrMR0wGwYDVQQKDBRTeW1hbnRlYyBDb3Jwb3JhdGlvbjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK/+Nq7kMnqR6fQzT7AdPZqAFXEHu2WpnwBLsyXj TZLjXzU4sk37efasq1jwJ6bhYarwFOnnM32PAtmEjWsWYrVC/yerrjDiQetD+ja7mEidL/SrOKNt 9oVnOO8SNdOYeFwydzx/mIFlQXLWA3DOj+xxHkonk9Zvz6kU4aOMC9eodawruobR5rBwn7dybplc e9m3BbDpIIKDIhkNjXQw8nesBtpwj40wIMsdPKh+YauCZW1mhh3LCAbU8JnJ9ruDKO6w+9EEFeFA 6F3DFqaHAnNdQj/bPVulnYpDqhNjOZqrp4677+fnCmWpHMqla0KuB6ujLY6rwc2T1ocpeT+zfb8C AwEAAaOCAwcwggMDMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMCAGA1UdJQEB/wQWMBQG CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU6AbcYQIy/DM74yCnYa/NhoUDAbowHQYDVR0R BBYwFIESamxhdXJlbnNAY2lzY28uY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoB MIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3Rvcnku dmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFs JTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90 JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUy QyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NB Q2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1 dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmww bAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1 dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTArBgpg hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85vFgUxMDkyMjA5BgpghkgBhvhFARAFBCsw KQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUA A4IBAQCaq/WPMAj7VTYbcIaIj4ejrezJkEdvtM7qG49B8Q/FG1nDEkyeQ6me9VcYMauVoP92PzB9 f9jaHRUPFPJ5O/HIZ3OrK4B9Ejc6zMO20Nlbf0hAX+9vJfOfz8iVYyfY0/7pO1bw2W/2u0S+KLL+ nocRFuDLiKaaKNeXaXb9spxSUer97n3oT862+cSWfbMHv4x1GeHAyRyWZfkHi2USNbetMaJ87uxy drfB/tkaik47F+0O6bSk5bGO/qklOHtdAiZvWyqzODKRTmtSeY7WjvhWkQaUKNjMuVZP7KIGJXUn UJoycIMIHCOBX+WMKDPjSib+FchE77R5wPJE3lUTnScgMYID5DCCA+ACAQEwgbswgaYxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSm Nt8H9SnjMAkGBSsOAwIaBQCgggH9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE0MDIwMjIyMDIxNlowIwYJKoZIhvcNAQkEMRYEFGY+W6qknCaeipVSKr4tKAlXBwCi MIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSmNt8H9SnjMIHOBgsqhkiG9w0BCRACCzGBvqCB uzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQC EEwHnU+e+WTxxKY23wf1KeMwDQYJKoZIhvcNAQEBBQAEggEAQRXe5feFaH13C0FzEPVcwT15YdyJ ZPYQEutyETZjgDiEgtEoVeVQ8rQ4oJEKyF14imgK46hczEe7mhKrXeFi0YuA9yWCaXJDOvzE3Hlx rvG0m0s/oPgfEQGNLW1NA7NMImTTU3QoHLmpcIFo9kjIQhbpJFjgJR1mEuWy+S4GOcJbni4Z0R0+ paJH4GlqkZhSnMOpGPzaiZVW8QzP1MOX9C2BTc4Dd8RQXPu+9dXZPciSQ1vXNMK7yeN1Q3AU82h5 1ZWxAXi4ygJkRap2rX9gwuSdvxkpYXCjOdPsM+i20P3lejUQu/0umijeyKsZA347ZvWX/8RRjsId q3PcPq15UQAAAAAAAA== --Apple-Mail=_30CDF2B8-13AD-4AF5-8573-39F25E206704-- From tireddy@cisco.com Mon Feb 3 07: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 B540F1A016B for ; Mon, 3 Feb 2014 07:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.535, 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 XmfMmSRnNRxi for ; Mon, 3 Feb 2014 07:41:30 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 115E01A016A for ; Mon, 3 Feb 2014 07:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8405; q=dns/txt; s=iport; t=1391442090; x=1392651690; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Jk9kfkgtjdkYcNZv1PB/+Hc+jK6irBuqypzXWwyST8I=; b=X20fiobxRFSnnDaZs1LTaOPpelJObVxCDtCI4Bf2fClzCyVY6ya+7/WD 0YHj7MAz1RaIknm3mopuDOSLneksTgbnqsW1GQJ+0adavhdlWs9uBNSoS 903rqVGYgNncJC8Eke57G8paK0rLdgTWnkWvFmi8cIMgreUnknnQILAuR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAF2371KtJV2Z/2dsb2JhbABZgww4V705T4EKFnSCJQEBAQMBAQEBCRtHCwwCAgIBCBEEAQEBCh0HGwYGCxQJCAEBBAENBQgBEodWAwkIDcNEDYkzFwSMb4FFAQEeMQIFBoMegRQEiRGNLYMeiyyFQ4JRXIFxOQ X-IronPort-AV: E=Sophos;i="4.95,773,1384300800"; d="scan'208";a="301573331" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 03 Feb 2014 15:41:29 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s13FfTKQ005547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 15:41:29 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 09:41:29 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Magnus Westerlund , Parthasarathi R , "'Cb B'" , "'Simon Perreault'" Thread-Topic: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 Thread-Index: Ac8ZZ7Ny5kA1i047TzKQusAUHYEHIwAgUgUwAMd1NgAAU7vrAAAP5c4AAJfvh4A= Date: Mon, 3 Feb 2014 15:41:28 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242A6A02@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2428E32D@xmb-rcd-x10.cisco.com> <009601cf17ca$5723cb70$056b6250$@co.in> <1447FA0C20ED5147A1AA0EF02890A64B1CF32B82@ESESSMB209.ericsson.se> <004501cf18a1$913c4080$b3b4c180$@co.in> <52E27630.3030300@viagenie.ca> <001c01cf1920$a00c9220$e025b660$@co.in> <52E2952A.2010503@viagenie.ca> <002001cf1927$b502eb00$1f08c100$@co.in> <52E2AE42.5060903@viagenie.ca> <001701cf19ec$f99791b0$ecc6b510$@co.in> <52E8C9D4.30205@ericsson.com> <00a001cf1e23$7a168aa0$6e439fe0$@co.in> <52EB6672.5090704@ericsson.com> In-Reply-To: <52EB6672.5090704@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.51.29] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 15:41:32 -0000 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus > Westerlund > Sent: Friday, January 31, 2014 2:32 PM > To: Parthasarathi R; 'Cb B'; 'Simon Perreault' > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and- > requirements-12 >=20 > Hi Partha, >=20 > Personal opinion: >=20 > I think the below places the text in the wrong context. The note is in my= mind > relevant in the context of the general NAT/FW traversal requirements, not > the one discussing need to support multiple NAT/FW traversal servers. Thu= s, > I think Section 3.3.2 and thus requirement F29. > Or potentially regarding Requirement F2. Is more appropriate places to > include this. F29, F2 does not mention any NAT/FW traversal techniques. F29 just discusse= s the problems with NAT but IPv6 Firewalls could also be configured to bloc= k UDP traffic. F19 Requirement seems to be missing in the latest version. -Tiru. >=20 > Cheers >=20 > Magnus >=20 > On 2014-01-31 02:26, Parthasarathi R wrote: > > Hi Magnus, > > > > I can live with Simon text in case it is documented in Sec 4.2 as > > > > F31 The browser must be able to use several STUN > > and TURN servers. Note that TURN support being mandatory > > does not preclude the browser from supporting > > additional traversal mechanisms. > > ---------------------------------------------------------------- > > F32 There browser must support that STUN and TURN > > servers to use are supplied by other entities > > than via the web application (i.e. the network > > provider). Note that TURN support being mandatory > > does not preclude the browser from supporting > > additional traversal mechanisms. > > > > and also Appendix A: > > > > A22 The Web API must provide means for the > > application to specify several STUN and/or > > TURN servers to use. Note that TURN support being mandatory > > does not preclude a Web API from supporting > > additional traversal mechanisms. > > > > Please let me know in case you have any issue in the above text. > > > > BTW, just for the record, > > draft-ietf-rtcweb-use-cases-and-requirements-12 > > does not specify the list of traversal mechanism requirements for > > WebRTC Gateway/Server. > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: Wednesday, January 29, 2014 2:59 PM > >> To: Parthasarathi R; 'Cb B'; 'Simon Perreault' > >> Cc: rtcweb@ietf.org > >> Subject: Re: [rtcweb] Query/Comment on > >> draft-ietf-rtcweb-use-cases-and- > >> requirements-12 > >> > >> Hi Partha and WG, > >> > >> I don't see any support for the changes you proposes in this > >> discussion. > >> What I see some support for is to add a statement making clear that > >> there might be additional NAT/Firewall traversal mechanisms than > >> STUN/TURN. Simon proposed: > >> > >> "Note that TURN support being mandatory does not preclude a WebRTC > >> endpoint from supporting additional traversal mechanisms." > >> > >> However, looking at the document as it is currently written, I am > >> uncertain where this would be added. The first mention of TURN is in > >> Section 3.3.4.1, and that section is focused on the global service > >> provider perspective and the need for location based provisioning of > >> NAT/Firewall traversal server resources. > >> > >> I think it can be added to Section 3.3.5.1 without being misplaced, > >> but it would be given a slightly narrower scope. > >> > >> I any of you want to be more explicit where this should be included, > >> please be. If you are not forthcoming I will request the authors to > >> add this in what they consider sensible position. > >> > >> Cheers > >> > >> Magnus > >> > >> > >> On 2014-01-25 17:46, Parthasarathi R wrote: > >>> Hi Simon, > >>> > >>> > >>> > >>> Thanks for your understanding about my firewall/NAT related problem > >>> statement in this draft. > >>> > >>> > >>> > >>> I have proposed the firewall/NAT related text by which the specific > >>> mechanism is not highlighted in the requirement document as there is > >> no > >>> WG consensus for any of the mechanism including TURN. It is possible > >> to > >>> argue hypothetically in PNTAW alias that PCP is the only mechanism > >>> required in WebRTC endpoint. Also, I'm more interested in WebRTC > >>> gateway/server (Sec 4.3. of > >>> draft-ietf-rtcweb-use-cases-and-requirements-12) requirements > >>> wherein > >> it > >>> is not required to support TURN and the related mail thread is > >>> http://www.ietf.org/mail-archive/web/pntaw/current/msg00181.html. > >>> > >>> > >>> > >>> IMO, my proposed text without mentioning any firewall/NAT mechanism > >> in > >>> the requirement document helps to move forward without depend on > the > >>> solution discussion in PNTAW alias. > >>> > >>> > >>> > >>> Thanks > >>> > >>> Partha > >>> > >>> > >>> > >>> *From:*Cb B [mailto:cb.list6@gmail.com] > >>> *Sent:* Saturday, January 25, 2014 6:22 AM > >>> *To:* Simon Perreault > >>> *Cc:* rtcweb@ietf.org; Parthasarathi R > >>> *Subject:* Re: [rtcweb] Query/Comment on > >>> draft-ietf-rtcweb-use-cases-and-requirements-12 > >>> > >>> > >>> > >>> > >>> On Jan 24, 2014 10:17 AM, "Simon Perreault" > >> >>> > wrote: > >>>> > >>>> Le 2014-01-24 12:14, Parthasarathi R a =E9crit : > >>>> > >>>>> Please note that when non-IETFers read this requirement document, > >>> they come > >>>>> to the conclusion that IETF RTCWeb WG recommends TURN and not > >>>>> other mechanisms. I'm saying that requirement document should not > >>>>> be used > >>> as the > >>>>> mechanism to eliminate the other alternatives when there is a > >> discussion > >>>>> going-on in PNTAW alias. So, I'm asking for the change. > >>>> > >>>> > >>>> I would totally agree with that sentiment, although I don't see > >>>> your > >>> proposed text change reflecting it accurately. How about simply: > >>>> > >>>> "Note that TURN support being mandatory does not preclude a > WebRTC > >>> endpoint from supporting additional traversal mechanisms." > >>>> > >>>> > >>> > >>> +1 for the above text. > >>> > >>> CB > >>> > >>>> Simon > >>>> -- > >>>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca > >>>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > >>>> STUN/TURN server --> http://numb.viagenie.ca > >>>> _______________________________________________ > >>>> rtcweb mailing list > >>>> rtcweb@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/rtcweb > >>> > >>> > >>> > >>> _______________________________________________ > >>> rtcweb mailing list > >>> rtcweb@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtcweb > >>> > >> > >> > >> -- > >> > >> Magnus Westerlund > >> > >> --------------------------------------------------------------------- > >> - Services, Media and Network features, Ericsson Research EAB/TXM > >> ---------------------------------------------------------------------- > >> Ericsson AB | Phone +46 10 7148287 > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@ericsson.com > >> --------------------------------------------------------------------- > >> - > > > > > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From juberti@google.com Mon Feb 3 11:27: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 060F01A01D0 for ; Mon, 3 Feb 2014 11:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.887 X-Spam-Level: * X-Spam-Status: No, score=1.887 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.535, 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 Rcf-oSM6M2n6 for ; Mon, 3 Feb 2014 11:27:28 -0800 (PST) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EDC971A010F for ; Mon, 3 Feb 2014 11:27:27 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id le5so5190429vcb.30 for ; Mon, 03 Feb 2014 11:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=bBKhRE/5uzBgp6DDpWIg4it2axc04Cv5eMdPvx92i2c=; b=eWcWiGCy7fyH5dfL6gp2+gEBeCguTWqhpWjYtsLFKmwFZVhNtTm+Qhsozczi/M6VQX mI3Tp0B267ZtItZXlzUfohBmgdc2eH3QX5jMLFRPZ04dcu/Qgt3JxObCPRV11tIEgXhE T3xMGNfKIznmj8cCc5RqDCjQtVMKG/yoGyX/aX7dTUjb/KO67VsWApAOqeWbBaquACGI AGSO1xll2OYi7CplPZaSVVctE+SKFrX4ZUsqZJ60y9nTLaGOCuKAYxcZvltd5x1PhbDz 8g+x6ga5XrCHIAsFpGIcXPnKvPIh4/EGFWcvw+O5WA3u8mcdtzlbW44qYYdDEGrl/e6q uuRw== 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; bh=bBKhRE/5uzBgp6DDpWIg4it2axc04Cv5eMdPvx92i2c=; b=FfjVXd3PQNY9PT92XGyM+g5MXxnvNAClcFG7UvS9T+GJKMLkQWFzypplYOgZz5qnd4 wmbWD3SlhBZkQ/1HQYASoYU9+cTaPyqa1CnoZr9FASf9rLxsPbLLaor3Dgkvty7pR1p7 wTlDPy10Yo12WVHm2cZxFMr6XAWsQ/6j6nMy/7HFcqmHceII9YWi3992wMUjYzbgjdOg Fb0ILvSxidYlmM1d4EP10Un7LehzmL0lPNtx2WfxgDF2w1xtyPmEhhTofXMh7wwobZxZ TaKJ3U72FF5wlEnZ+UOF/C2fzqW2njphbfoF44CB7DtA1F5A0mLOW2OfNQjrL5PWB3Wl ZnyA== X-Gm-Message-State: ALoCoQmxs9tspXgcDWE2s7xetRctMMScQi+VLdMi4tYxP7sbkCbEZCd9fmtp06vKoDz9kLPAQ4Po73h0Pvu6kfS+gC3UGpanzxDoMEUAZa/rm5LUN+NIC2Wvnk6yAKjNnEAYWF1X81hov6jYPRFBSYFZ4527q88ntF0Xgs49lopKAU8QOZ0cl9Nu8OvzpyRPBeDXtPHuG2JE X-Received: by 10.221.30.14 with SMTP id sa14mr36451vcb.44.1391455647020; Mon, 03 Feb 2014 11:27:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 11:27:06 -0800 (PST) From: Justin Uberti Date: Mon, 3 Feb 2014 11:27:06 -0800 Message-ID: To: "rtcweb@ietf.org" , Cullen Jennings Content-Type: multipart/alternative; boundary=001a11336a2e90057e04f1858368 Subject: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 19:27:30 -0000 --001a11336a2e90057e04f1858368 Content-Type: text/plain; charset=UTF-8 While working on the latest JSEP update, I came across the following problem: When a answerer wants to reject a "media stream" in 3264, it sets the m= line port in the answer to zero. However, when an endpoint wants to reject a remote MediaStreamTrack without rejecting the m= line entirely, because it is using the m= line for its own MediaStreamTrack, we don't have a clear way to express that. While setting a=sendonly in the answer will tell the other side to stop sending data, this won't kill the remote track. As far as the remote side is concerned, its track is just 'paused'/'held', and is still associated with the m= line. Note that there is no such problem if an endpoint decides to kill its own local MediaStreamTrack; in the offer it sends to indicate this, in addition to setting the m= line to a=recvonly, it can also remove the MSID of the track from the m= line, indicating the track is gone. In other words, the a=msid attribute serves as the binding of MST to m= line, and its absence indicates the track is gone. Therefore, I think we need some similar way for a receiver to do the same for a remote track. And fortunately, I think we have a surface that can be used for this, namely the "recv-appId" attribute that has been discussed in the context of unified-plan and explained in http://tools.ietf.org/id/draft-even-mmusic-application-token-02.txt and unified-plan. If an endpoint doesn't want to receive a particular track on a m= line, it sets the m= line to a=sendonly and also removes any a=recv-appId. Below is an example of an audio call between A and B, with MediaStreamTracks MSTA and MSTB. A initially generates an offer, and then I show 4 different answer scenarios for various cases. 1) A generates offer with MSTA m=audio X a=msid:MSTA a=recv-appId:1 # use 1 in the header extension when sending MSTA 2a) Normal answer: B adds its own track MSTB, generates answer: m=audio Y a=msid:MSTB a=recv-appId:1 2b) Add+reject answer: B adds its own track MSTB, stops MSTA, generates answer: m=audio Y a=msid:MSB a=sendonly # no appid; A can realize that MSA has been rejected 2c) Reject-only answer: B stops MSTA without adding a stream, generates answer: m=audio 0 # entire m-line has been rejected 2d) Do-nothing answer: B does nothing, generates answer: m=audio Y a=recv-appId:1 a=recvonly If this seems reasonable, I plan to use this mechanism for handling m= line allocation in JSEP. Also, this essentially makes recv-appId the converse of MSID; for simplicity, I think we should consider unifying these concepts into a single document. --001a11336a2e90057e04f1858368 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While working on the latest JSEP update, I came across the following probl= em:

When a answerer = wants to reject a "media stream" in 3264, it sets the m=3D line p= ort in the answer to zero. However, when an endpoint wants to reject a remo= te MediaStreamTrack without rejecting the m=3D line entirely, because it is= using the m=3D line for its own MediaStreamTrack, we don't have a clea= r way to express that. While setting a=3Dsendonly in the answer will tell t= he other side to stop sending data, this won't kill the remote track. A= s far as the remote side is concerned, its track is just 'paused'/&= #39;held', and is still associated with the m=3D line.

Note that there is no = such problem if an endpoint decides to kill its own local MediaStreamTrack;= in the offer it sends to indicate this, in addition to setting the m=3D li= ne to a=3Drecvonly, it can also remove the MSID of the track from the m=3D = line, indicating the track is gone. In other words, the a=3Dmsid attribute = serves as the binding of MST to m=3D line, and its absence indicates the tr= ack is gone.

Therefore, I think we = need some similar way for a receiver to do the same for a remote track. And= fortunately, I think we have a surface that can be used for this, namely t= he "recv-appId" attribute that has been discussed in the context = of unified-plan and explained in http://tools.ietf.org/id/draft-even-m= music-application-token-02.txt and unified-plan. If an endpoint doesn&#= 39;t want to receive a particular track on a m=3D line, it sets the m=3D li= ne to a=3Dsendonly and also removes any a=3Drecv-appId.

Below is an example of= an audio call between A and B, with MediaStreamTracks MSTA and MSTB. A ini= tially generates an offer, and then I show 4 different answer scenarios for= various cases.

1) A generates offer w= ith MSTA
m= =3Daudio X
a=3Dmsid:MSTA
a=3Drecv-appI= d:1 # use 1 in the header extension when sending MSTA

2a) No= rmal answer: B adds its own track MSTB, generates answer:
m=3Daudio Y
a=3Dmsid:MSTB
a=3Drecv-appId:1

2b) Add+reject answer: B adds its own track MSTB, stops MSTA, generates = answer:
m=3Daudio Y
a=3Dmsid:MSB
a=3Dsendonly
# no appid; A can re= alize that MSA has been rejected

2c) Reject-only answer= : B stops MSTA without adding a stream, generates answer:
m=3Daudio 0=C2=A0
# entire m-line has been rejected

2d) Do-nothing answer: B does nothing, generates answer:
m=3Daudio Y
a=3Drecv-appId:1
=
a=3Drecvonly

If t= his seems reasonable, I plan to use this mechanism for handling m=3D line a= llocation in JSEP.

Also, this essentially= makes recv-appId the converse of MSID; for simplicity, I think we should c= onsider unifying these concepts into a single document.
--001a11336a2e90057e04f1858368-- From martin.thomson@gmail.com Mon Feb 3 12:06: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 318D11A022D for ; Mon, 3 Feb 2014 12:06:35 -0800 (PST) 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 yoMx8dcDX6Gq for ; Mon, 3 Feb 2014 12:06:34 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 22D991A0223 for ; Mon, 3 Feb 2014 12:06:33 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id q59so2979971wes.20 for ; Mon, 03 Feb 2014 12:06:33 -0800 (PST) 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=pK/mlwUszZmRbRVvNDwfs5mYTDAY4wG63PlY0cqtDcU=; b=CNbQL3N15H32ggbaq7PehB462cDKtiSniWjaO3fbgCFqTZrQ37uRwL/HfkfdcIVq7K KX9oWYNyln77OT24Vz9hd+yPHElZ6wQnlFQ+d3n751/6NxL7heT/FLzJtB3s1T789N0x yTTPAtLtKeRJKMKGkUokioge1THoIgJ6XGoolp/pHXZuaCGZOF8CFX/rCLsgXGTEr0dk 626ROIEClE60g4bcP+22fIb9s1zk51lhPgW/ARffmTMHjTFkGhjZ65FhJVXeQAza+ko0 jSwrPg/a7HPsdlNIBkX8JG+yjmwPFBf6bSCGgGDztx9ZLWfGEymlg+oGkpRWYYysw40i brBA== MIME-Version: 1.0 X-Received: by 10.180.74.200 with SMTP id w8mr9853377wiv.58.1391457993628; Mon, 03 Feb 2014 12:06:33 -0800 (PST) Received: by 10.227.10.196 with HTTP; Mon, 3 Feb 2014 12:06:33 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Feb 2014 12:06:33 -0800 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 20:06:35 -0000 On 3 February 2014 11:27, Justin Uberti wrote: > 2a) Normal answer: B adds its own track MSTB, generates answer: > m=audio Y > a=msid:MSTB > a=recv-appId:1 Potential problems: recv-appId looks like something that applies to what B is receiving reject looks a little like does not support recv-appid as well I think that the merging appid/msid is worth considering. I think that gets around these minor issues. From christer.holmberg@ericsson.com Mon Feb 3 12:08: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 BD5641A0242 for ; Mon, 3 Feb 2014 12:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.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 ElzlGBw1kBwW for ; Mon, 3 Feb 2014 12:08:37 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 295301A01E1 for ; Mon, 3 Feb 2014 12:08:36 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-d3-52eff7441b52 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 22.02.10875.447FFE25; Mon, 3 Feb 2014 21:08:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0387.000; Mon, 3 Feb 2014 21:08:35 +0100 From: Christer Holmberg To: Justin Uberti , "rtcweb@ietf.org" , Cullen Jennings Thread-Topic: [rtcweb] Rejecting MediaStreamTracks in JSEP Thread-Index: AQHPIRX+Di2Spk3Lw0GdFyTxI3EbsJqj9URm Date: Mon, 3 Feb 2014 20:08:35 +0000 Message-ID: <37s61e9ckw02929t4v3gflwo.1391458112947@email.android.com> References: 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_37s61e9ckw02929t4v3gflwo1391458112947emailandroidcom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvja7L9/dBBrNOKVh0TGaz2DpVyGLt v3Z2B2aPKb83snos2FTqsWTJT6YA5igum5TUnMyy1CJ9uwSujJ7dF9gKFnpUbPq5m62B8aht FyMnh4SAicSajvPMELaYxIV769lAbCGBQ4wSO34qdjFyAdmLGCXOzlgElODgYBOwkOj+pw1S IyJQKHFh4QNGEFtYwFJizew2dpASEQEriZXX0yFMI4neU/UgFSwCKhK7Dn4Hq+YVcJP4NOED K8SmAImWzQfYQWxOgUCJxgdvwS5gBLrm+6k1TCA2s4C4xK0n85kgrhSQWLIH5mJRiZeP/7FC 1ORIrHv6iQVivqDEyZlPWCYwCs9C0j4LSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+ gJF9FSN7bmJmTnq54SZGYKwc3PJbdwfjqXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8q zUktPsTIxMEp1cDoJH997k7PEG5bA83CUolctrs/BL7NL12WOvObyUmOLzlPF6+uMrp9TH7j W5kDliyunF+vrAsJcfgRa9Z/f+OEtMjT87tPH256JrVQY3nWmi1c9/9JHV26PPHzPw/DDo7W KRyBvO21bN+OlWU9P1bV7ztT9re5xW2X9g1rf0xqPSY93eavzq7NSizFGYmGWsxFxYkA5lFs vGMCAAA= Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 20:08:40 -0000 --_000_37s61e9ckw02929t4v3gflwo1391458112947emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Would this be solved by using uni-directional m- lines? Regards, Christer Sent from my Sony Ericsson Xperia arc S Justin Uberti wrote: While working on the latest JSEP update, I came across the following proble= m: When a answerer wants to reject a "media stream" in 3264, it sets the m=3D = line port in the answer to zero. However, when an endpoint wants to reject = a remote MediaStreamTrack without rejecting the m=3D line entirely, because= it is using the m=3D line for its own MediaStreamTrack, we don't have a cl= ear way to express that. While setting a=3Dsendonly in the answer will tell= the other side to stop sending data, this won't kill the remote track. As = far as the remote side is concerned, its track is just 'paused'/'held', and= is still associated with the m=3D line. Note that there is no such problem if an endpoint decides to kill its own l= ocal MediaStreamTrack; in the offer it sends to indicate this, in addition = to setting the m=3D line to a=3Drecvonly, it can also remove the MSID of th= e track from the m=3D line, indicating the track is gone. In other words, t= he a=3Dmsid attribute serves as the binding of MST to m=3D line, and its ab= sence indicates the track is gone. Therefore, I think we need some similar way for a receiver to do the same f= or a remote track. And fortunately, I think we have a surface that can be u= sed for this, namely the "recv-appId" attribute that has been discussed in = the context of unified-plan and explained in http://tools.ietf.org/id/draft= -even-mmusic-application-token-02.txt and unified-plan. If an endpoint does= n't want to receive a particular track on a m=3D line, it sets the m=3D lin= e to a=3Dsendonly and also removes any a=3Drecv-appId. Below is an example of an audio call between A and B, with MediaStreamTrack= s MSTA and MSTB. A initially generates an offer, and then I show 4 differen= t answer scenarios for various cases. 1) A generates offer with MSTA m=3Daudio X a=3Dmsid:MSTA a=3Drecv-appId:1 # use 1 in the header extension when sending MSTA 2a) Normal answer: B adds its own track MSTB, generates answer: m=3Daudio Y a=3Dmsid:MSTB a=3Drecv-appId:1 2b) Add+reject answer: B adds its own track MSTB, stops MSTA, generates ans= wer: m=3Daudio Y a=3Dmsid:MSB a=3Dsendonly # no appid; A can realize that MSA has been rejected 2c) Reject-only answer: B stops MSTA without adding a stream, generates ans= wer: m=3Daudio 0 # entire m-line has been rejected 2d) Do-nothing answer: B does nothing, generates answer: m=3Daudio Y a=3Drecv-appId:1 a=3Drecvonly If this seems reasonable, I plan to use this mechanism for handling m=3D li= ne allocation in JSEP. Also, this essentially makes recv-appId the converse of MSID; for simplicit= y, I think we should consider unifying these concepts into a single documen= t. --_000_37s61e9ckw02929t4v3gflwo1391458112947emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi,=0A=
=0A=
Would this be solved by using uni-directional m- lines?=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Justin Uberti <juberti@google.com> wrote:=0A=
=0A=
While working o= n the latest JSEP update, I came across the following problem:

When a answerer= wants to reject a "media stream" in 3264, it sets the m=3D line = port in the answer to zero. However, when an endpoint wants to reject a rem= ote MediaStreamTrack without rejecting the m=3D line entirely, because it is using the m=3D line for its own MediaStreamTr= ack, we don't have a clear way to express that. While setting a=3Dsendonly = in the answer will tell the other side to stop sending data, this won't kil= l the remote track. As far as the remote side is concerned, its track is just 'paused'/'held', and is still associa= ted with the m=3D line.

Note that there= is no such problem if an endpoint decides to kill its own local MediaStrea= mTrack; in the offer it sends to indicate this, in addition to setting the = m=3D line to a=3Drecvonly, it can also remove the MSID of the track from the m=3D line, indicating the track is g= one. In other words, the a=3Dmsid attribute serves as the binding of MST to= m=3D line, and its absence indicates the track is gone.

Therefore, I th= ink we need some similar way for a receiver to do the same for a remote tra= ck. And fortunately, I think we have a surface that can be used for this, n= amely the "recv-appId" attribute that has been discussed in the context of unified-plan and explained in http://tools.ietf.org/id/draft-even-mmusic-application-token-02.txt and= unified-plan. If an endpoint doesn't want to receive a particular track on= a m=3D line, it sets the m=3D line to a=3Dsendonly and also removes any a= =3Drecv-appId.

Below is an exa= mple of an audio call between A and B, with MediaStreamTracks MSTA and MSTB= . A initially generates an offer, and then I show 4 different answer scenar= ios for various cases.

1) A generates = offer with MSTA
m=3Daudio X
a=3Dmsid:MSTA
a=3Drecv-appId:= 1 # use 1 in the header extension when sending MSTA

2a) Normal answ= er: B adds its own track MSTB, generates answer:
m=3Daudio Y
a=3Dmsid:MSTB
a=3Drecv-appId:= 1

2b) Add+rej= ect answer: B adds its own track MSTB, stops MSTA, generates answer:
m=3Daudio Y
a=3Dmsid:MSB
a=3Dsendonly
# no appid; A c= an realize that MSA has been rejected

2c) Reject-only= answer: B stops MSTA without adding a stream, generates answer:
m=3Daudio 0&nbs= p;
# entire m-line= has been rejected

2d) Do-nothing = answer: B does nothing, generates answer:
m=3Daudio Y
a=3Drecv-appId:= 1
a=3Drecvonly

If this seems r= easonable, I plan to use this mechanism for handling m=3D line allocation i= n JSEP.

Also, this esse= ntially makes recv-appId the converse of MSID; for simplicity, I think we s= hould consider unifying these concepts into a single document.
--_000_37s61e9ckw02929t4v3gflwo1391458112947emailandroidcom_-- From adam@nostrum.com Mon Feb 3 12:20: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 B24AD1A0207 for ; Mon, 3 Feb 2014 12:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.435 X-Spam-Level: X-Spam-Status: No, score=-0.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_18=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 4i57C0d_gPgX for ; Mon, 3 Feb 2014 12:20:01 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3584A1A01FB for ; Mon, 3 Feb 2014 12:20:01 -0800 (PST) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s13KJnth040655 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 3 Feb 2014 14:19:50 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52EFF9E0.40808@nostrum.com> Date: Mon, 03 Feb 2014 14:19:44 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Justin Uberti , "rtcweb@ietf.org" , Cullen Jennings References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000807000107020001010907" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 20:20:03 -0000 This is a multi-part message in MIME format. --------------000807000107020001010907 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/3/14 13:27, Justin Uberti wrote: > Therefore, I think we need some similar way for a receiver to do the > same for a remote track. Yes. > And fortunately, I think we have a surface that can be used for this, > namely the "recv-appId" attribute that has been discussed in the > context of unified-plan and explained in > http://tools.ietf.org/id/draft-even-mmusic-application-token-02.txt > and unified-plan. If an endpoint doesn't want to receive a particular > track on a m= line, it sets the m= line to a=sendonly and also removes > any a=recv-appId. No. The problem is that you're defining semantics to a behavior that is indistinguishable from the behavior exhibited by something that does not support app-id: if the thing on the other end isn't using app-id, then an attempt to put a stream on hold will be misinterpreted as an attempt to reject or remove it. I agree that we want an SDP operation that differentiates between "don't send me this now" and "don't send me this ever" [1] -- but it needs to be explicit. Something more like "a=i-am-rejecting-this-stream", but with a less cumbersome name. /a ____ [1] Along with a Javascript control that allows us to do the same thing, but that's a W3C issue. --------------000807000107020001010907 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 2/3/14 13:27, Justin Uberti wrote:
Therefore, I think we need some similar way for a receiver to do the same for a remote track.

Yes.

And fortunately, I think we have a surface that can be used for this, namely the "recv-appId" attribute that has been discussed in the context of unified-plan and explained in http://tools.ietf.org/id/draft-even-mmusic-application-token-02.txt and unified-plan. If an endpoint doesn't want to receive a particular track on a m= line, it sets the m= line to a=sendonly and also removes any a=recv-appId.

No.

The problem is that you're defining semantics to a behavior that is indistinguishable from the behavior exhibited by something that does not support app-id: if the thing on the other end isn't using app-id, then an attempt to put a stream on hold will be misinterpreted as an attempt to reject or remove it.

I agree that we want an SDP operation that differentiates between "don't send me this now" and "don't send me this ever" [1]  -- but it needs to be explicit. Something more like "a=i-am-rejecting-this-stream", but with a less cumbersome name.

/a


____
[1] Along with a Javascript control that allows us to do the same thing, but that's a W3C issue.
--------------000807000107020001010907-- From juberti@google.com Mon Feb 3 12:20: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 C22581A0225 for ; Mon, 3 Feb 2014 12:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.713 X-Spam-Level: X-Spam-Status: No, score=-0.713 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_14=0.6, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.535, 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 HflDUG0od1SQ for ; Mon, 3 Feb 2014 12:20:05 -0800 (PST) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5C30B1A021D for ; Mon, 3 Feb 2014 12:20:05 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id ks9so5010598vcb.25 for ; Mon, 03 Feb 2014 12:20:05 -0800 (PST) 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=hyHV1p33oWqUnhv6hNwqKFmkzV21u0JIh4zXil06+Wc=; b=giGn4kDrI4TnC7VF5lnQllhYZwc1/wozmWYbg+QHfRb1NSi0QrR5IL4CHmcnvy7qBh 0tJ3Xb+fj4Ga27xZbQi/uvZJp6a+/r6CB1HOJEabWvvOEoDvBIoq5hOwAnYwkgpm/w9x 5yDgR/bNX/JA5ebWUqjI5EPP8t/n55CNG/qeCv7pP7a0bVop9bqCOn2L/9jZkGNo+VwK zeF9ax52HbSRduQaWC4Z15m1+d8x6x6I97Kv7fhQZEXBeKTzUlCpGE6SDweEsh/jHrGR VEHcp/hCCayphcGT24vkFIMJ4308+yi9QgwPASwW9g+hOFlgYszFqPi/1Bp95IsYOK0w wKHg== 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=hyHV1p33oWqUnhv6hNwqKFmkzV21u0JIh4zXil06+Wc=; b=KngPgYisSMHYZ9YsN6IgQs+R340Q78vDfEmGRf49F0/Q1CSip9KY5RPBlzFhPwF0uW TxIDd2FYuRbL+gpoEwdeRbR6RNrLVAx7lCEjxIg0tCANoND4amboqU9CBwcZab0XtuO6 H6hkBTzjEcRnOPASmEmSvVdYC65sMOOa7IcUhpXEKYtID7Nb8eIN/jQEQXt3OzSHfcyY AJbhrD9OGMQgkoL6dspzD11dszZ8gVq1TvJdOrsLEaSwqbljgYc954UlGPDWwz5n1p+8 FPprzWO/t0zYQO8cVRV9iwaBwAyxaCldm0SQpW4GOZCWsAp2RuBDKAq+lzJMI6TE3Suj YnEw== X-Gm-Message-State: ALoCoQmF2Qq9U+qg98vqADMGE6VxLUp6x3wqYzLUTGTCCCtj+is2puLFvn+aC9nqDWarQPgxadXv2/EDWRjZJVy3cyXnH9gKPIUOEOGoOFpsUjlMBT+BqdcF93RccmI6YGT/YwdOFwmooOTvgwKcrNKa5EGGaYk/1BslU13flhyb1AzGSBnLojvL/qgMSrpZEAOJDsvlJdEW X-Received: by 10.58.90.202 with SMTP id by10mr28822294veb.6.1391458805017; Mon, 03 Feb 2014 12:20:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 12:19:44 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Mon, 3 Feb 2014 12:19:44 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1136a478cb09ac04f1863ff7 Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 20:20:07 -0000 --001a1136a478cb09ac04f1863ff7 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 3, 2014 at 12:06 PM, Martin Thomson wrote: > On 3 February 2014 11:27, Justin Uberti wrote: > > 2a) Normal answer: B adds its own track MSTB, generates answer: > > m=audio Y > > a=msid:MSTB > > a=recv-appId:1 > > Potential problems: > > recv-appId looks like something that applies to what B is receiving > It does, in fact. In B's answer, a=msid indicates what B is sending; a=recv-appId indicates that B wants to receive the MST from A that is associated with this m-line. > reject looks a little like does not support recv-appid as well > True. But if, as you say, we merge appid and msid, then the only possible ambiguity comes from the legacy no-msid, no-appid case, and even that is not an issue since all the possible outcomes are separable: full duplex (m=audio Y), one-way reject (m=audio Y, a=sendonly), full reject (m=audio 0). Of course, we can't know that the one-way reject is final, but the number of add/remove stream operations done by legacy devices should be limited. > I think that the merging appid/msid is worth considering. I think > that gets around these minor issues. --001a1136a478cb09ac04f1863ff7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 3, 2014 at 12:06 PM, Martin Thomson &= lt;martin.tho= mson@gmail.com> wrote:
On 3 February 2014 11:27, Justin Uberti = <juberti@google.com> wrote:=
> 2a) Normal answer: B adds its own track MSTB, generates answer:
> m=3Daudio Y
> a=3Dmsid:MSTB
> a=3Drecv-appId:1

Potential problems:

recv-appId looks like something that applies to what B is receiving

It does, in fact. In B's answer, a=3Dmsid = indicates what B is sending; a=3Drecv-appId indicates that B wants to recei= ve the MST from A that is associated with this m-line.
=C2=A0
reject looks a little like does not support recv-appid as well

True. But if, as you say, we merge appid and msid, = then the only possible ambiguity comes from the legacy no-msid, no-appid ca= se, and even that is not an issue since all the possible outcomes are separ= able: full duplex (m=3Daudio Y), one-way reject (m=3Daudio Y, a=3Dsendonly)= , full reject (m=3Daudio 0). Of course, we can't know that the one-way = reject is final, but the number of add/remove stream operations done by leg= acy devices should be limited.


I think that the merging appid/msid is worth considering. =C2=A0I think
that gets around these minor issues.=C2=A0
--001a1136a478cb09ac04f1863ff7-- From juberti@google.com Mon Feb 3 12:21: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 4D6461A0222 for ; Mon, 3 Feb 2014 12:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.487 X-Spam-Level: X-Spam-Status: No, score=0.487 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_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.535, 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 W9XtJiUC8GCW for ; Mon, 3 Feb 2014 12:21:14 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E2B1D1A0221 for ; Mon, 3 Feb 2014 12:21:13 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id lf12so5209924vcb.3 for ; Mon, 03 Feb 2014 12:21:13 -0800 (PST) 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=HW5iTtjxIbLeEfVUgoFaPaxjtC4YyYn1mkSlJE/2iZk=; b=Ztx/uN2s/3Jz5DCPtCvl1isGxxHXCaxAhjYr69npKhJdjRx/8qQzUMJUfrQ/hgeGum Y9pgZhtmzcluqyPvUhcQfVxEOH4m+ndDK8+0Kj5Mm3DtWNGFd9K9LTqpXNZa5kqCIJtX /clRCT8k2fUFO0h0GEfhMZn9qs1XyBAFaOhL0E4p4YG7+EWd5+2/q2VksJQdXEKEs/te zqRl/vQL7fBr+U7TbWEE/oIeSEqmsic5uhqUrzZTRuCZLYlPmpMpOEROKftOJ3Gv557K jMAPvwkVPVgVMVJ7n8eqxwMWBilIK0UZ58ZC7BlY5QE+HQMfuYyfrGM3WqTkh2VCcjDk RkuA== 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=HW5iTtjxIbLeEfVUgoFaPaxjtC4YyYn1mkSlJE/2iZk=; b=hiATLCoFnBvFbmzKnB/oHadPhquUVuFtkXOkI/Mu+tkIixXlF2HzM4axMBsAfD9Q1r 1FrG+rvttFw4LA6P0VWJ5+FJgUh9nf9eObbqzkh68aSHAHmyXwCTYs86diBRngRFSnIj H4ZuPr90uz3T0ye6kACiCZc3W5R9u6vl8wE1SUb9+J2icvuaL7neaOeK4KztaNDmEO8k 2oRXXx9SpXaX1JegaisVsqDek/6fierI+VUCs+of7pYUT68K3aqP4THfiPn803myTt7U ZYNY05JIPlcJAFui9mLhcxRqrYR4ZRe2DNoCpEX+ETBG4xipTrI+ZDknVe21z33uzWEG 3v+A== X-Gm-Message-State: ALoCoQky2d5kDklKO1XKIsQiNhV2yiRVgXz5Gg7btEIiMSdLeUUuOHxYjRgzv3fTdQywMThV0ypo21lIJE47h4aIKxH6sEBjO0x7gv4wQjcoHxpvGPvkVxcxRT8cjU2xL4zLwVoZxxCiMDDoqirrw/JH/nCtrLnThNwn/WN6vY6CJ1c8/9kG8hZAywrdrJ20yLU52XMKGJ+5 X-Received: by 10.58.181.71 with SMTP id du7mr2626091vec.25.1391458873539; Mon, 03 Feb 2014 12:21:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 12:20:53 -0800 (PST) In-Reply-To: <37s61e9ckw02929t4v3gflwo.1391458112947@email.android.com> References: <37s61e9ckw02929t4v3gflwo.1391458112947@email.android.com> From: Justin Uberti Date: Mon, 3 Feb 2014 12:20:53 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b873810e0cb5004f186434c Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 20:21:16 -0000 --047d7b873810e0cb5004f186434c Content-Type: text/plain; charset=UTF-8 On Mon, Feb 3, 2014 at 12:08 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Would this be solved by using uni-directional m- lines? > > Yes, but at the cost of compatibility with legacy. There has been broad support for bidirectional m= lines each time this has come up. > > Regards, > > Christer > > Sent from my Sony Ericsson Xperia arc S > > Justin Uberti wrote: > > > While working on the latest JSEP update, I came across the following > problem: > > When a answerer wants to reject a "media stream" in 3264, it sets the m= > line port in the answer to zero. However, when an endpoint wants to reject > a remote MediaStreamTrack without rejecting the m= line entirely, because > it is using the m= line for its own MediaStreamTrack, we don't have a clear > way to express that. While setting a=sendonly in the answer will tell the > other side to stop sending data, this won't kill the remote track. As far > as the remote side is concerned, its track is just 'paused'/'held', and is > still associated with the m= line. > > Note that there is no such problem if an endpoint decides to kill its > own local MediaStreamTrack; in the offer it sends to indicate this, in > addition to setting the m= line to a=recvonly, it can also remove the MSID > of the track from the m= line, indicating the track is gone. In other > words, the a=msid attribute serves as the binding of MST to m= line, and > its absence indicates the track is gone. > > Therefore, I think we need some similar way for a receiver to do the > same for a remote track. And fortunately, I think we have a surface that > can be used for this, namely the "recv-appId" attribute that has been > discussed in the context of unified-plan and explained in > http://tools.ietf.org/id/draft-even-mmusic-application-token-02.txt and > unified-plan. If an endpoint doesn't want to receive a particular track on > a m= line, it sets the m= line to a=sendonly and also removes any > a=recv-appId. > > Below is an example of an audio call between A and B, with > MediaStreamTracks MSTA and MSTB. A initially generates an offer, and then I > show 4 different answer scenarios for various cases. > > 1) A generates offer with MSTA > m=audio X > a=msid:MSTA > a=recv-appId:1 # use 1 in the header extension when sending MSTA > > 2a) Normal answer: B adds its own track MSTB, generates answer: > m=audio Y > a=msid:MSTB > a=recv-appId:1 > > 2b) Add+reject answer: B adds its own track MSTB, stops MSTA, generates > answer: > m=audio Y > a=msid:MSB > a=sendonly > # no appid; A can realize that MSA has been rejected > > 2c) Reject-only answer: B stops MSTA without adding a stream, generates > answer: > m=audio 0 > # entire m-line has been rejected > > 2d) Do-nothing answer: B does nothing, generates answer: > m=audio Y > a=recv-appId:1 > a=recvonly > > If this seems reasonable, I plan to use this mechanism for handling m= > line allocation in JSEP. > > Also, this essentially makes recv-appId the converse of MSID; for > simplicity, I think we should consider unifying these concepts into a > single document. > --047d7b873810e0cb5004f186434c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 3, 2014 at 12:08 PM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:
Hi,

Would this be solved by using uni-directional m- lines?
Yes, but at the cost of compatibility with legacy. There has been= broad support for bidirectional m=3D lines each time this has come up.
Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Justin Uberti <j=
uberti@google.com> wrote:
While working on= the latest JSEP update, I came across the following problem:

When a answerer = wants to reject a "media stream" in 3264, it sets the m=3D line p= ort in the answer to zero. However, when an endpoint wants to reject a remo= te MediaStreamTrack without rejecting the m=3D line entirely, because it is using the m=3D line for its own MediaStreamTr= ack, we don't have a clear way to express that. While setting a=3Dsendo= nly in the answer will tell the other side to stop sending data, this won&#= 39;t kill the remote track. As far as the remote side is concerned, its track is just 'paused'/'held', and = is still associated with the m=3D line.

Note that there = is no such problem if an endpoint decides to kill its own local MediaStream= Track; in the offer it sends to indicate this, in addition to setting the m= =3D line to a=3Drecvonly, it can also remove the MSID of the track from the m=3D line, indicating the track is g= one. In other words, the a=3Dmsid attribute serves as the binding of MST to= m=3D line, and its absence indicates the track is gone.

Therefore, I thi= nk we need some similar way for a receiver to do the same for a remote trac= k. And fortunately, I think we have a surface that can be used for this, na= mely the "recv-appId" attribute that has been discussed in the context of unified-plan and explained in http://tools.ietf.org/id/draft-even-mmusic-application-token-02.txt and= unified-plan. If an endpoint doesn't want to receive a particular trac= k on a m=3D line, it sets the m=3D line to a=3Dsendonly and also removes an= y a=3Drecv-appId.

Below is an exam= ple of an audio call between A and B, with MediaStreamTracks MSTA and MSTB.= A initially generates an offer, and then I show 4 different answer scenari= os for various cases.

1) A generates o= ffer with MSTA
m=3Daudio X
a=3Dmsid:MSTA
a=3Drecv-appId:1= # use 1 in the header extension when sending MSTA

2a) Normal answe= r: B adds its own track MSTB, generates answer:
m=3Daudio Y
a=3Dmsid:MSTB
a=3Drecv-appId:1=

2b) Add+reject a= nswer: B adds its own track MSTB, stops MSTA, generates answer:
m=3Daudio Y
a=3Dmsid:MSB
a=3Dsendonly
# no appid; A ca= n realize that MSA has been rejected

2c) Reject-only = answer: B stops MSTA without adding a stream, generates answer:
m=3Daudio 0=C2= =A0
# entire m-line = has been rejected

2d) Do-nothing a= nswer: B does nothing, generates answer:
m=3Daudio Y
a=3Drecv-appId:1=
a=3Drecvonly

If this seems re= asonable, I plan to use this mechanism for handling m=3D line allocation in= JSEP.

Also, this essen= tially makes recv-appId the converse of MSID; for simplicity, I think we sh= ould consider unifying these concepts into a single document.

--047d7b873810e0cb5004f186434c-- From juberti@google.com Mon Feb 3 12:26: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 14C8A1A020C for ; Mon, 3 Feb 2014 12:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.313 X-Spam-Level: X-Spam-Status: No, score=-1.313 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_18=0.6, RP_MATCHES_RCVD=-0.535, 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 Q1M90oAMMEIj for ; Mon, 3 Feb 2014 12:26:03 -0800 (PST) Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 49F4C1A015A for ; Mon, 3 Feb 2014 12:26:03 -0800 (PST) Received: by mail-vb0-f42.google.com with SMTP id i3so5195099vbh.1 for ; Mon, 03 Feb 2014 12:26:03 -0800 (PST) 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=WilmkZSIp/Ei5CTTk8fOUXOeezBIRlvTnyFH29hkTOw=; b=Mvk6kDsfthe+oxLf685Fbc+tQd2ZY4gAqGGbuByZLZfNuR+q65YsQVy8hkHeXc//kO ZXceb6pPJQ6kjJcmURWPBcm2VWvepQtJByqDN73xK6/ZVCnnh7f4NE4pROIOAFCux95I ZYKju+erNlNeDDWTNJtG2w+HUICZhbK473OFVSopcKfFBkW3mgXpA1Mjx64yBkxwH1/6 mnKkFZ7R/RwcVPWpYz8HkP8tplqixLHcTs76ommE+qIAmaTbR+yBpSDTIt3XJ3aD+XWh LL422Q7EDMNG8hOpochv7j/pqT7NF8y64ONavabGL60tTu0okor4n60fzwntkUJQfxu4 kutw== 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=WilmkZSIp/Ei5CTTk8fOUXOeezBIRlvTnyFH29hkTOw=; b=MGACLfEhyftPJPCbcWPfB4D1WqsZaiT4JL1gqWkrMXz4uHaTHeIyu9O4dnew7SR0Qd Dva/J8TaX97dtA+kstl3L8TP7yZmmywoggMZ2dz+I5kd/9CokfVy/AVGfUhZCB2OUwQb rlmJpqCzMLn0D0J/8xt9GP6QqjxVHebWvdICWkKgjWOyFN/8yey+i/E+DwLdCr3PUICx cTErZrnPJwcD7dOeCR8zS5gtcUcG7zy5aBjJUuluPAS9cme21yvD+GRdb9n8Tk6tew+x ZMPh4CWN2dpEr0YD9Xhl4uZ6ZLv2Fy2RA2E4ZTl5mJ7Ytg6p31xkZwlFWqNKqCBvS9yn dlBg== X-Gm-Message-State: ALoCoQmfXVrjdfaFjsYewdGcHD/N6zb+kGCB3iTS/PrkBeSAXKFY8KUMe4AtBHkeFYEhVvoYrJ9RC2wpYrutyZYgkhgjZL6NI/wTytpACFZNSwTjzF44qUNQWcFmTP/Vo+ed9yr/1tok5rb4/A5sIy1yh8rDOqFJ+DZVCFIY0Pqt7cRKKYXwNOb8wIvmdDsMaOLtswfvKhO1 X-Received: by 10.58.66.137 with SMTP id f9mr29839224vet.11.1391459162947; Mon, 03 Feb 2014 12:26:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 12:25:42 -0800 (PST) In-Reply-To: <52EFF9E0.40808@nostrum.com> References: <52EFF9E0.40808@nostrum.com> From: Justin Uberti Date: Mon, 3 Feb 2014 12:25:42 -0800 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=047d7b33d85620aa3104f1865571 Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 20:26:05 -0000 --047d7b33d85620aa3104f1865571 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 3, 2014 at 12:19 PM, Adam Roach wrote: > On 2/3/14 13:27, Justin Uberti wrote: > > Therefore, I think we need some similar way for a receiver to do the same > for a remote track. > > > Yes. > > > And fortunately, I think we have a surface that can be used for this, > namely the "recv-appId" attribute that has been discussed in the context of > unified-plan and explained in > http://tools.ietf.org/id/draft-even-mmusic-application-token-02.txt and > unified-plan. If an endpoint doesn't want to receive a particular track on > a m= line, it sets the m= line to a=sendonly and also removes any > a=recv-appId. > > > No. > > The problem is that you're defining semantics to a behavior that is > indistinguishable from the behavior exhibited by something that does not > support app-id: if the thing on the other end isn't using app-id, then an > attempt to put a stream on hold will be misinterpreted as an attempt to > reject or remove it. > See my response to Martin. Putting a stream on hold will never result in that being misinterpreted as a reject; on the contrary, without appid, there is no way to 'fully' reject half of a stream, and, as a problem confined to pre-unified-plan devices, I think that is probably OK. > > I agree that we want an SDP operation that differentiates between "don't > send me this now" and "don't send me this ever" [1] -- but it needs to be > explicit. Something more like "a=i-am-rejecting-this-stream", but with a > less cumbersome name. > > It's not clear to me that adding a new attribute would solve any problem that appid doesn't solve; you still need to deal with the "other end not using it" issue. > ____ > [1] Along with a Javascript control that allows us to do the same thing, > but that's a W3C issue. > Agree. But while we're on the subject, I am thinking that MST.stop() == "not ever", and RtpReceiver.active = false causes "not now". --047d7b33d85620aa3104f1865571 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 3, 2014 at 12:19 PM, Adam Roach <<= a href=3D"mailto:adam@nostrum.com" target=3D"_blank">adam@nostrum.com&g= t; wrote:
=20 =20 =20
On 2/3/14 13:27, Justin Uberti wrote:
Therefore, I think we need some similar way for a receiver to do the same for a remote track.

Yes.


And fortunately, I think we have a surface that can be used for this, namely the "recv-appId" attribute that has been dis= cussed in the context of unified-plan and explained in http://tools.ietf.org/id/draft-even-mmusic-application-token-02.txt and unified-plan. If an endpoint doesn't want to receive a particular track on a m=3D line, it sets the m=3D line to a=3Dsendo= nly and also removes any a=3Drecv-appId.

No.

The problem is that you're defining semantics to a behavior that is indistinguishable from the behavior exhibited by something that does not support app-id: if the thing on the other end isn't using app-id, then an attempt to put a stream on hold will be misinterpreted as an attempt to reject or remove it.

See my response to Martin. Putting a stream on hold= will never result in that being misinterpreted as a reject; on the contrar= y, without appid, there is no way to 'fully' reject half of a strea= m, and, as a problem confined to pre-unified-plan devices, I think that is = probably OK.=C2=A0

I agree that we want an SDP operation that differentiates between "don't send me this now" and "don't send me this= ever" [1]=C2=A0 -- but it needs to be explicit. Something more like "a=3Di-am-rejecting-this-stream", but with a less cumbersome = name.

It's not clear to me that adding a= new attribute would solve any problem that appid doesn't solve; you st= ill need to deal with the "other end not using it" issue.
=C2=A0
____
[1] Along with a Javascript control that allows us to do the same thing, but that's a W3C issue.

Agree. But while we're on the subject, I am thinking that MST.sto= p() =3D=3D "not ever", and RtpReceiver.active =3D false causes &q= uot;not now".=C2=A0

--047d7b33d85620aa3104f1865571-- From juberti@google.com Mon Feb 3 12:28: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 DF5571A020C for ; Mon, 3 Feb 2014 12:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.313 X-Spam-Level: X-Spam-Status: No, score=-1.313 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_18=0.6, RP_MATCHES_RCVD=-0.535, 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 awIryt7uaJE5 for ; Mon, 3 Feb 2014 12:28:24 -0800 (PST) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 38B411A0162 for ; Mon, 3 Feb 2014 12:28:24 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id w8so5051775vbj.37 for ; Mon, 03 Feb 2014 12:28:23 -0800 (PST) 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=gY7dhRCqeeuxmz32DkOn8pNKGysfddcfXlHgGFzi198=; b=CaiMYuA8Xrn1iSiyUVZkqL4XTOh37QKSJmn/qoKO21gB3SYle+Vi7I/G5AqKX1drrZ +Q7fqu+5JQi1HzwaNVvFsScA4O03IlaZgqFkXfDD1kQX293d7zIBNhlHGyhQ9Gqd8QzE MZeqZE9ESqsYPAf3XRAVf97Zf1+0AxfPtwgkDJCG/UNlRptPsjbTgDZLkdu+1PJxUInW KcpcgsBoPtflD3AbqpT2Gu8zZm5bZWN4RyFJebTa3FJJ1N6oBmAzXAvXNvfdRDgwKFmd 2X2GyqerbTkp8v4ClIPzG3YPm2jwQyzlM4Jtt+GH84d1ulScAT8c8wCjNo51HorIfpok vj4Q== 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=gY7dhRCqeeuxmz32DkOn8pNKGysfddcfXlHgGFzi198=; b=OExTeePOymYW7YY2J9KbT2PEnw/AR3AaBjORDvb0oxpBFF1oMuN+4da8hmwr+VavSW g94NrRC70fFiPIe0q07La1HkO/0PNERen9CgB5ik8uQlKIQ7uOLjrttyepfxctZL9ZoV KRGjHAF6liYu4n/JzmxQW9jzW1c3kU5OAO6xznfoFirTYDs6INrONIF1SUlCAb+hMF/5 L54UOc6oA5eNszoGc0cGB9+Zy3rPWvAbnYb7WvoA+E8TWAU31ofD9wdP35RAYV2w8r01 y+LWWluV0Sghen14UaTNyGNfmIzhBym3EBpmrbrbZg4g5yFiVDHFu2cHvuk+NSUt5BbQ tunw== X-Gm-Message-State: ALoCoQmRbSwKyout8gvaO8Iq/VmivccLSPMEh3ytClelqMvqzwiXoEmVuaUSuvFLNgDdx+gDJn0QQuMaTubsyp8AM3gVii8ahkPMfl9eKBh79jgYI+cCryif7gU6SdNy2xdHjDLLgxAg8Qw8aJflu+fsqukvbkM3+W9LiK5oyfuySWR7BamyFeukzXJ0GbuZwSM08TwlTizJ X-Received: by 10.220.48.194 with SMTP id s2mr87223vcf.43.1391459303878; Mon, 03 Feb 2014 12:28:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 12:28:03 -0800 (PST) In-Reply-To: References: <52EFF9E0.40808@nostrum.com> From: Justin Uberti Date: Mon, 3 Feb 2014 12:28:03 -0800 Message-ID: To: Adam Roach , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1e7fc8718b604f1865d89 Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 20:28:26 -0000 --001a11c1e7fc8718b604f1865d89 Content-Type: text/plain; charset=UTF-8 +mmusic (meant to include the first time around) On Mon, Feb 3, 2014 at 12:25 PM, Justin Uberti wrote: > > > > On Mon, Feb 3, 2014 at 12:19 PM, Adam Roach wrote: > >> On 2/3/14 13:27, Justin Uberti wrote: >> >> Therefore, I think we need some similar way for a receiver to do the same >> for a remote track. >> >> >> Yes. >> >> >> And fortunately, I think we have a surface that can be used for this, >> namely the "recv-appId" attribute that has been discussed in the context of >> unified-plan and explained in >> http://tools.ietf.org/id/draft-even-mmusic-application-token-02.txt and >> unified-plan. If an endpoint doesn't want to receive a particular track on >> a m= line, it sets the m= line to a=sendonly and also removes any >> a=recv-appId. >> >> >> No. >> >> The problem is that you're defining semantics to a behavior that is >> indistinguishable from the behavior exhibited by something that does not >> support app-id: if the thing on the other end isn't using app-id, then an >> attempt to put a stream on hold will be misinterpreted as an attempt to >> reject or remove it. >> > > See my response to Martin. Putting a stream on hold will never result in > that being misinterpreted as a reject; on the contrary, without appid, > there is no way to 'fully' reject half of a stream, and, as a problem > confined to pre-unified-plan devices, I think that is probably OK. > >> >> I agree that we want an SDP operation that differentiates between "don't >> send me this now" and "don't send me this ever" [1] -- but it needs to be >> explicit. Something more like "a=i-am-rejecting-this-stream", but with a >> less cumbersome name. >> >> It's not clear to me that adding a new attribute would solve any problem > that appid doesn't solve; you still need to deal with the "other end not > using it" issue. > > >> ____ >> [1] Along with a Javascript control that allows us to do the same thing, >> but that's a W3C issue. >> > > Agree. But while we're on the subject, I am thinking that MST.stop() == > "not ever", and RtpReceiver.active = false causes "not now". > > --001a11c1e7fc8718b604f1865d89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+mmusic (meant to include the first time around)


On Mon, Feb 3, 20= 14 at 12:25 PM, Justin Uberti <juberti@google.com> wrote:



On Mon, Feb 3, 201= 4 at 12:19 PM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 2/3/14 13:27, Justin Uberti wrote:
Therefore, I think we need some similar way for a receiver to do the same for a remote track.

Yes.


And fortunately, I think we have a surface that can be used for this, namely the "recv-appId" attribute that has been dis= cussed in the context of unified-plan and explained in http://tools.ietf.org/id/draft-even-mmusic-application-token-02.txt and unified-plan. If an endpoint doesn't want to receive a particular track on a m=3D line, it sets the m=3D line to a=3Dsendo= nly and also removes any a=3Drecv-appId.

No.

The problem is that you're defining semantics to a behavior that is indistinguishable from the behavior exhibited by something that does not support app-id: if the thing on the other end isn't using app-id, then an attempt to put a stream on hold will be misinterpreted as an attempt to reject or remove it.

See my response to Martin. Putting a stream o= n hold will never result in that being misinterpreted as a reject; on the c= ontrary, without appid, there is no way to 'fully' reject half of a= stream, and, as a problem confined to pre-unified-plan devices, I think th= at is probably OK.=C2=A0

I agree that we want an SDP operation that differentiates between "don't send me this now" and "don't send me this= ever" [1]=C2=A0 -- but it needs to be explicit. Something more like "a=3Di-am-rejecting-this-stream", but with a less cumbersome = name.

It's not clear to me that ad= ding a new attribute would solve any problem that appid doesn't solve; = you still need to deal with the "other end not using it" issue.
=C2=A0
____
[1] Along with a Javascript control that allows us to do the same thing, but that's a W3C issue.

Agree. But while we're on the subject, I am thinking that M= ST.stop() =3D=3D "not ever", and RtpReceiver.active =3D false cau= ses "not now".=C2=A0


--001a11c1e7fc8718b604f1865d89-- From adam@nostrum.com Mon Feb 3 12:42: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 293D21A0213 for ; Mon, 3 Feb 2014 12:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 sL-N1_p8IhNz for ; Mon, 3 Feb 2014 12:42:51 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3769C1A020C for ; Mon, 3 Feb 2014 12:42:51 -0800 (PST) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s13KghI7041649 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 3 Feb 2014 14:42:44 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52EFFF3E.9080705@nostrum.com> Date: Mon, 03 Feb 2014 14:42:38 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Justin Uberti References: <52EFF9E0.40808@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 20:42:52 -0000 On 2/3/14 14:25, Justin Uberti wrote: > It's not clear to me that adding a new attribute would solve any > problem that appid doesn't solve; you still need to deal with the > "other end not using it" issue. Regardless of whether you think there's a problem in the legacy interop case, the big benefit here is that an explicit indicator by definition makes the operation explicit, and that in-and-of-itself is a good thing. The core issue is that you're trying to make the operation implicit; your proposal edges awfully close to the DWIM model of design, which we know causes problems when we try to add further extensions. /a From juberti@google.com Mon Feb 3 13:03: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 D46E51A0213 for ; Mon, 3 Feb 2014 13:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DI7s7tqbWoV for ; Mon, 3 Feb 2014 13:03:43 -0800 (PST) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 81F731A015A for ; Mon, 3 Feb 2014 13:03:43 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id oy12so5531713veb.28 for ; Mon, 03 Feb 2014 13:03:43 -0800 (PST) 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=gfnYGtb004uADYqh6wRLQqzGDvftjOdAliIrf+dAjsA=; b=Gv3Z7RsKTxJiXMezr3iSKQYAuj3aJxLeex5MF1h8YlJkMSa4fp9CtyX0NDwugxxjzG r58u9bhcnSjsU86qB1L1BExJ9s1Eg0MgUV9TPObApkSJd09s1CbZ4uSn/uWySDzRG5E/ Lv6K0GPVFSMgyPXQjjXVV8mmoLWlN8t8JPoNiqJnM9Tdrjj6XCK/pzG1bC+6NYl4npBF MAdxPBLAe3MZtAhd4iPpFPSjBUHDxaqYAmSnOPbM0pNvH8ad48rA4iwlq48WK0wnSeuN cXHMUrObQD1uUTT8yNn64Ze832F8BYUcDt4YlUlycQYSe1+vbuzMut/WVt/7Kt9SgOLO xFKA== 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=gfnYGtb004uADYqh6wRLQqzGDvftjOdAliIrf+dAjsA=; b=iNMdeRzpI7RgfTzzkEDFUuUqeSylrRQnZUT85p2l6RtvslK+uxXkqjjqYCtgKqO4WS BquK8V6ml7bXkMPo11LtDNWhcejzh3spD4FjK5NI0IEupIrtiuu4YwO0gT3NdItu8F9Q ANwNW34snqjawwjiT8DFRyF3+NY6d6GxLAPhgP71WalbOtJuZN2ZjvgX/GRU7cWY1VyG FOFGAZ9lbFlSmmt/BQ+rekEhr434PxQ3D/Eg2a3JQ8tXYJClQNFiub45Bz37dJvoIYrX Oxw7xT9hM+XWNCncc1M/J4sMz8wqYlTsI1l35z60cnIY0LUs90fLDF8NgchpDjlljPNc fH6Q== X-Gm-Message-State: ALoCoQnWUb8jID5bD7vJPgHIiiIn8MCP//sRj3J1+gaz1tjO2MJJ4MuCbOsY+CE8itnxQqRwHq587HUSK786Z+P5ONioKn31lvRahduAS4Fvgi78HAxkyfKc20YJSnWnp5F1VPBkHOQ3PNHfe5umRZCwWWoywQNIXoc2sI2USXcdvfT3hb283xSetSfNKaCgezVpP2vSOXrP X-Received: by 10.220.139.136 with SMTP id e8mr1363403vcu.34.1391461423130; Mon, 03 Feb 2014 13:03:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 13:03:22 -0800 (PST) In-Reply-To: <52EFFF3E.9080705@nostrum.com> References: <52EFF9E0.40808@nostrum.com> <52EFFF3E.9080705@nostrum.com> From: Justin Uberti Date: Mon, 3 Feb 2014 13:03:22 -0800 Message-ID: To: Adam Roach , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=047d7b343296d8404004f186db09 Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 21:03:45 -0000 --047d7b343296d8404004f186db09 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 3, 2014 at 12:42 PM, Adam Roach wrote: > On 2/3/14 14:25, Justin Uberti wrote: > >> It's not clear to me that adding a new attribute would solve any problem >> that appid doesn't solve; you still need to deal with the "other end not >> using it" issue. >> > > Regardless of whether you think there's a problem in the legacy interop > case, the big benefit here is that an explicit indicator by definition > makes the operation explicit, and that in-and-of-itself is a good thing. > > The core issue is that you're trying to make the operation implicit; your > proposal edges awfully close to the DWIM model of design, which we know > causes problems when we try to add further extensions. Good point, but since we are still defining exactly what appId does, I think we have the opportunity to make it explicit. --047d7b343296d8404004f186db09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 3, 2014 at 12:42 PM, Adam Roach <<= a href=3D"mailto:adam@nostrum.com" target=3D"_blank">adam@nostrum.com&g= t; wrote:
On 2/3/14 14:25, Justin Ub= erti wrote:
It's not clear to me that adding a new attribute would solve any proble= m that appid doesn't solve; you still need to deal with the "other= end not using it" issue.

Regardless of whether you think there's a problem in the legacy interop= case, the big benefit here is that an explicit indicator by definition mak= es the operation explicit, and that in-and-of-itself is a good thing.

The core issue is that you're trying to make the operation implicit; yo= ur proposal edges awfully close to the DWIM model of design, which we know = causes problems when we try to add further extensions.

Good point, but since we are still defining exactly what app= Id does, I think we have the opportunity to make it explicit.=C2=A0

--047d7b343296d8404004f186db09-- From adam@nostrum.com Mon Feb 3 13:11: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 223021A0237; Mon, 3 Feb 2014 13:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=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 4NHfvP_FhSrm; Mon, 3 Feb 2014 13:11:04 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E32131A0225; Mon, 3 Feb 2014 13:11:03 -0800 (PST) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s13LAo5f042807 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 3 Feb 2014 15:10:51 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52F005D5.1020702@nostrum.com> Date: Mon, 03 Feb 2014 15:10:45 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Justin Uberti , "mmusic@ietf.org" References: <52EFF9E0.40808@nostrum.com> <52EFFF3E.9080705@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020506060903060308030504" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 21:11:05 -0000 This is a multi-part message in MIME format. --------------020506060903060308030504 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/3/14 15:03, Justin Uberti wrote: > > On Mon, Feb 3, 2014 at 12:42 PM, Adam Roach > wrote: > > On 2/3/14 14:25, Justin Uberti wrote: > > It's not clear to me that adding a new attribute would solve > any problem that appid doesn't solve; you still need to deal > with the "other end not using it" issue. > > > Regardless of whether you think there's a problem in the legacy > interop case, the big benefit here is that an explicit indicator > by definition makes the operation explicit, and that > in-and-of-itself is a good thing. > > The core issue is that you're trying to make the operation > implicit; your proposal edges awfully close to the DWIM model of > design, which we know causes problems when we try to add further > extensions. > > > Good point, but since we are still defining exactly what appId does, I > think we have the opportunity to make it explicit. > I think I agree, but this isn't congruent with the proposal you made before. Omitting app-id as a means of rejecting a stream is an implicit operation, regardless of how well it's documented. If you want to have something like "a=recv-appId:reject", that would be suitably explicit, but I really have a hard time imagining how something like that would be preferable to just having a new attribute. /a --------------020506060903060308030504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 2/3/14 15:03, Justin Uberti wrote:

On Mon, Feb 3, 2014 at 12:42 PM, Adam Roach <adam@nostrum.com> wrote:
On 2/3/14 14:25, Justin Uberti wrote:
It's not clear to me that adding a new attribute would solve any problem that appid doesn't solve; you still need to deal with the "other end not using it" issue.

Regardless of whether you think there's a problem in the legacy interop case, the big benefit here is that an explicit indicator by definition makes the operation explicit, and that in-and-of-itself is a good thing.

The core issue is that you're trying to make the operation implicit; your proposal edges awfully close to the DWIM model of design, which we know causes problems when we try to add further extensions.

Good point, but since we are still defining exactly what appId does, I think we have the opportunity to make it explicit. 


I think I agree, but this isn't congruent with the proposal you made before. Omitting app-id as a means of rejecting a stream is an implicit operation, regardless of how well it's documented.

If you want to have something like "a=recv-appId:reject", that would be suitably explicit, but I really have a hard time imagining how something like that would be preferable to just having a new attribute.

/a
--------------020506060903060308030504-- From juberti@google.com Mon Feb 3 13:22: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 DEEC21A0251 for ; Mon, 3 Feb 2014 13:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 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, RP_MATCHES_RCVD=-0.535, 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 ArPW2fY4g3Qf for ; Mon, 3 Feb 2014 13:22:21 -0800 (PST) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 91A691A0248 for ; Mon, 3 Feb 2014 13:22:21 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id jy13so5305709veb.41 for ; Mon, 03 Feb 2014 13:22:21 -0800 (PST) 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=CT8HpjzuF3dDIPq1GNmETpLO6uN8fsES7N0mPgKKAAw=; b=oYOWbY+QnFRsZOly+J9xKGdelKg/C9yuGFA7FKy4CSSV6IcTxRjH632+923Ih2GBze JHEC3Q+Ah2zlhv7Pugh8uwHbPSHYgAV0bwk8S9Cmhsymf82PpkY5uDdOCSLaRb1/5IVs MvVlCI0Iby8CmzCY2Po8ug3JqsjcjonG06wCE1kdxhEF/lZRQGs21MGN3IvLXX3eg6hp 5eQ7wxVqa4PWY296YIm4XxSdaWh81sYwhDgfp9uibKUnsmy0XooaaUqW+YH74Ve+wIsZ jf7Rj4bmcJ4K9M2/YuzFnCRaZTk6kcs6JbiU/SaGQ4vkurgE7tjCFPi6shdNPokc3VJm hD0w== 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=CT8HpjzuF3dDIPq1GNmETpLO6uN8fsES7N0mPgKKAAw=; b=gHZWNjDIERvznMmvFYiqyvXlrAmeM49mWy6E/ZKXm4tcCCWbTS2C2bDo7OROyLYLVY yk2MnoAMOiU369U9rc3dzEH+lGsdV8rV97sfK2fALo9OYVcXzJmghVMZvV/EgBd+wczK HU1QAZ8/zkVMYcOIv0EAGW5PjaMW71h1JeN2WvFKdSvG89kb5vZM8786Uf0IFJIHoDEz nO44k46qcKKWBdiSrtEKp7/r05jD79J6GE+NyRkk6WekOZGrGTa25AST4gsjZDpH5Mru yEc5+ORtVLTUbg5tZBnUDRThzwuoNefnYIu24K5yRNcIeFjgWwWGTvpBh4P6oTAKQuh6 JJlQ== X-Gm-Message-State: ALoCoQnH4S/l/cP3OwJe3XhD+urnvounPcSE3Fxq77FEws+w5zqf6dqlL2Pfr9/GjmzZ12t+vamyxbW83WYpdIKV5PfEBr0kpDO0BQzMiUi57nsx5+RykziAZynKF+eV9BYHHbWZlTxxo7233ERuAVeJZ/6kcIMwf97ovO2YF1E8tmo8HLWSA9QBbqS6WUb2CcGC8EfnwPeR X-Received: by 10.52.95.233 with SMTP id dn9mr25200434vdb.3.1391462541077; Mon, 03 Feb 2014 13:22:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 13:22:00 -0800 (PST) In-Reply-To: <52F005D5.1020702@nostrum.com> References: <52EFF9E0.40808@nostrum.com> <52EFFF3E.9080705@nostrum.com> <52F005D5.1020702@nostrum.com> From: Justin Uberti Date: Mon, 3 Feb 2014 13:22:00 -0800 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a1136b6107ac4b404f1871e5f Cc: Cullen Jennings , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 21:22:25 -0000 --001a1136b6107ac4b404f1871e5f Content-Type: text/plain; charset=UTF-8 On Mon, Feb 3, 2014 at 1:10 PM, Adam Roach wrote: > On 2/3/14 15:03, Justin Uberti wrote: > > > On Mon, Feb 3, 2014 at 12:42 PM, Adam Roach wrote: > >> On 2/3/14 14:25, Justin Uberti wrote: >> >>> It's not clear to me that adding a new attribute would solve any problem >>> that appid doesn't solve; you still need to deal with the "other end not >>> using it" issue. >>> >> >> Regardless of whether you think there's a problem in the legacy interop >> case, the big benefit here is that an explicit indicator by definition >> makes the operation explicit, and that in-and-of-itself is a good thing. >> >> The core issue is that you're trying to make the operation implicit; your >> proposal edges awfully close to the DWIM model of design, which we know >> causes problems when we try to add further extensions. > > > Good point, but since we are still defining exactly what appId does, I > think we have the opportunity to make it explicit. > > > I think I agree, but this isn't congruent with the proposal you made > before. Omitting app-id as a means of rejecting a stream is an implicit > operation, regardless of how well it's documented. > > If you want to have something like "a=recv-appId:reject", that would be > suitably explicit, but I really have a hard time imagining how something > like that would be preferable to just having a new attribute. > I was thinking a=recv-appId:0, which is both explicit, and has parallels with the zero port form of rejecting a m= line. --001a1136b6107ac4b404f1871e5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 3, 2014 at 1:10 PM, Adam Roach <adam@nostrum.com>= ; wrote:
=20 =20 =20
On 2/3/14 15:03, Justin Uberti wrote:

On Mon, Feb 3, 2014 at 12:42 PM, Adam Roach <adam@nostrum.com> wrote:
On 2/3/14 14:25, Justin Uberti wrote:
It's not clear to me that adding a new attribute woul= d solve any problem that appid doesn't solve; you still need to deal with the "other end not using it" = issue.

Regardless of whether you think there's a problem in the legacy interop case, the big benefit here is that an explicit indicator by definition makes the operation explicit, and that in-and-of-itself is a good thing.

The core issue is that you're trying to make the operatio= n implicit; your proposal edges awfully close to the DWIM model of design, which we know causes problems when we try to add further extensions.

Good point, but since we are still defining exactly what appId does, I think we have the opportunity to make it explicit.=C2=A0


I think I agree, but this isn't congruent with the proposal you mad= e before. Omitting app-id as a means of rejecting a stream is an implicit operation, regardless of how well it's documented.

If you want to have something like "a=3Drecv-appId:reject", t= hat would be suitably explicit, but I really have a hard time imagining how something like that would be preferable to just having a new attribute.

I was thinking a=3Drec= v-appId:0, which is both explicit, and has parallels with the zero port for= m of rejecting a m=3D line.=C2=A0

--001a1136b6107ac4b404f1871e5f-- From adam@nostrum.com Mon Feb 3 14: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 2FC421A025F; Mon, 3 Feb 2014 14:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 9Uyor261U6mH; Mon, 3 Feb 2014 14:10:36 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 62C951A01EE; Mon, 3 Feb 2014 14:10:36 -0800 (PST) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s13MANLd045159 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 3 Feb 2014 16:10:24 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52F013C9.1090609@nostrum.com> Date: Mon, 03 Feb 2014 16:10:17 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Justin Uberti References: <52EFF9E0.40808@nostrum.com> <52EFFF3E.9080705@nostrum.com> <52F005D5.1020702@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: Cullen Jennings , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 22:10:37 -0000 On 2/3/14 15:22, Justin Uberti wrote: > > I was thinking a=recv-appId:0, which is both explicit, and has > parallels with the zero port form of rejecting a m= line. > I have no objection to such an approach. /a From jonathan@vidyo.com Mon Feb 3 14:32: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 37AA11A01EE; Mon, 3 Feb 2014 14:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, 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 4crGNX-tLnbZ; Mon, 3 Feb 2014 14:32:21 -0800 (PST) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) by ietfa.amsl.com (Postfix) with ESMTP id CF7FA1A015D; Mon, 3 Feb 2014 14:32:20 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/3/2014 5:32:18 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-145/SG:5 2/3/2014 5:32:05 PM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.765737 p=-0.947836 Source White X-Signature-Violations: 0-0-0-6034-c X-Note-419: 0 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/3/2014 5:32:06 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 94746033; Mon, 03 Feb 2014 17:32:18 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Mon, 3 Feb 2014 16:32:17 -0600 From: Jonathan Lennox To: Justin Uberti Thread-Topic: [rtcweb] Rejecting MediaStreamTracks in JSEP Thread-Index: AQHPIS46pADKsTFIzECMWWmLIWbna5qkgc6A Date: Mon, 3 Feb 2014 22:32:17 +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: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_C433A27C348A402AB03607060746FADAvidyocom_" MIME-Version: 1.0 Cc: Cullen Jennings , "rtcweb@ietf.org" , mmusic Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 22:32:22 -0000 --_000_C433A27C348A402AB03607060746FADAvidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Feb 3, 2014, at 2:27 PM, Justin Uberti > wrote: Also, this essentially makes recv-appId the converse of MSID; for simplicit= y, I think we should consider unifying these concepts into a single documen= t. AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream. For example, an m-line which has both a primary encoded stream (of media) a= nd a redundancy stream (of rtx packets) would have two appid values, but on= ly one msid. On the receive side, if you wanted to receive both a primary = encoded stream and a redundancy stream, you would have two recv-appid value= s. As such, appid and msid are solving different (though related) problems, an= d I don't think unifying them is a good idea. Perhaps we need a recv-msid, explicitly? --_000_C433A27C348A402AB03607060746FADAvidyocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <37105A42B50D274697715328E513CDD0@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Feb 3, 2014, at 2:27 PM, Justin Uberti <juberti@google.com> wrote:

Also, this essen= tially makes recv-appId the converse of MSID; for simplicity, I think we sh= ould consider unifying these concepts into a single document.

AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream.

For example, an m-line which has both a primary encoded stream (of med= ia) and a redundancy stream (of rtx packets) would have two appid values, b= ut only one msid.  On the receive side, if you wanted to receive both = a primary encoded stream and a redundancy stream, you would have two recv-appid values.

As such, appid and msid are solving different (though related) problem= s, and I don't think unifying them is a good idea.

Perhaps we need a recv-msid, explicitly?

--_000_C433A27C348A402AB03607060746FADAvidyocom_-- From juberti@google.com Mon Feb 3 15: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 E00E41A0286 for ; Mon, 3 Feb 2014 15:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V77LIujNiSU6 for ; Mon, 3 Feb 2014 15:00:46 -0800 (PST) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 85F381A027B for ; Mon, 3 Feb 2014 15:00:46 -0800 (PST) Received: by mail-vc0-f175.google.com with SMTP id ij19so5170030vcb.6 for ; Mon, 03 Feb 2014 15:00:46 -0800 (PST) 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=yXDPcYNswZrdNXI7EV4hWR3viGWuz2NmMdn10nDDM9U=; b=ny/k+pogMdj3kZG4dEEyTkvH9K0Vh1tvnKB+HA2FX1X00pqscDyIO5PvBuRJ5PCqKc PcELvRRQWtbZ9NPfH640BgOg70dtdXk1tI5IMicy2ELRFk0tXWWlcmmBFyN3unSWX1fT UKZjCbOFOHkf9L22d4XbOzK+Ee6QTGjZcZJDefloq9ueqp+g9Lb5tVsdtuYMNkPA745g iKC2uQm2O3RWy2MyepHBf4I5pDTzciR7ZK1zH2g+iYS4nsY27P/1xBsETXtFLzf7Unvq 3VToi1ef3Cz8dYFFuNRDY5LNiGe7GmCl70OaPKRjF7Y4btIZQykq810qLVd1HNtW/eEw uhDQ== 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=yXDPcYNswZrdNXI7EV4hWR3viGWuz2NmMdn10nDDM9U=; b=hvI9Woae9+NAcJ8mmA5xlc9LCsU2J1ORX1BjQbAEEQkb8cCakeTIjoJhSaXyfjS50l KgQmwHwZMWyUT8l3SkZdrqbcfV8k7wqEw5RVQoIaXf8v7p6MWsvQAP7xPW1PL0m0hE30 zBOao4D9QpOCBhWnZOS7xTTrgpTZyyYi5Udi/Ic8Q4dHjbLO2qaPvZloIiMCwV2yxU6n F0SbBPIwXbRpoaIMa11xYw0LhxCWEtiso39JUcVa/6pO9BUgJJ7SpzJW2gwEyBpo5FwP cdmj7aBhnsJFa42bk0jrixu12VtpPK7NoABwlqBaiL7SPg1RvmBbxuSSBx+bixM6NWdS RAlA== X-Gm-Message-State: ALoCoQndXTJreN0D/vD8rqXNXnR6uumS0nuJa7BefK6rX8ISMJV/abZ5p6CTnDjjKGuStumiYdNj9SBPdPaglyfJb+JhL90wIhBATHYNDlQAySE8JXHRautzqxNz9iRJkfeWNVhNpULyQ8fiSOaIzprZRpXgt0WzdvGdkotSQc/fMe6DjuloeI7Vyv9riJn81dmpUnuqFzf4 X-Received: by 10.58.168.142 with SMTP id zw14mr45602veb.33.1391468446135; Mon, 03 Feb 2014 15:00:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 15:00:26 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Mon, 3 Feb 2014 15:00:26 -0800 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=047d7b6da02872d46104f1887ec4 Cc: Cullen Jennings , "rtcweb@ietf.org" , mmusic Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 23:00:48 -0000 --047d7b6da02872d46104f1887ec4 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox wrote: > On Feb 3, 2014, at 2:27 PM, Justin Uberti wrote: > > Also, this essentially makes recv-appId the converse of MSID; for > simplicity, I think we should consider unifying these concepts into a > single document. > > > AppID (as I envision it, as the author) and MSID (as I understand it) > have rather different scopes, which are visible once sources are sent using > more than one packet stream. > > For example, an m-line which has both a primary encoded stream (of > media) and a redundancy stream (of rtx packets) would have two appid > values, but only one msid. On the receive side, if you wanted to receive > both a primary encoded stream and a redundancy stream, you would have two > recv-appid values. > > As such, appid and msid are solving different (though related) problems, > and I don't think unifying them is a good idea. > > Perhaps we need a recv-msid, explicitly? > That would be fine by me - it would allow a single invention (msid + recv-msid) to focus on solving the three identified problems with MSTs in unified-plan: - correlation of a MediaStreamTrack to m= line in signaling (msid) - correlation of packets from a MST to m= line ahead of signaling (recv-msid) - rejection of an individual MST (recv-msid) Based on your description, appid seems to go one or two levels down from a MST to an individual RTP flow, but we can let that develop on its own, separate from the timetable of webrtc 1.0 and unified plan. --047d7b6da02872d46104f1887ec4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox &= lt;jonathan@vidyo.c= om> wrote:
On Feb 3, 2014, at 2:27 PM, Justin Uberti <juberti@google.com>=C2=A0wrote:

Also, this essen= tially makes recv-appId the converse of MSID; for simplicity, I think we sh= ould consider unifying these concepts into a single document.

AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream.

For example, an m-line which has both a primary encoded stream (of med= ia) and a redundancy stream (of rtx packets) would have two appid values, b= ut only one msid. =C2=A0On the receive side, if you wanted to receive both = a primary encoded stream and a redundancy stream, you would have two recv-appid values.

As such, appid and msid are solving different (though related) problem= s, and I don't think unifying them is a good idea.

Perhaps we need a recv-msid, explicitly?
<= div>
That would be fine by me - it would allow a single inven= tion (msid + recv-msid) to focus on solving the three identified problems w= ith MSTs in unified-plan:
- correlation of a MediaStreamTrack to m=3D line in signaling (msid)
- correlation of packets from a MST to m=3D line ahead of signalin= g (recv-msid)
- rejection of an individual MST (recv-msid)

Based on your description, appid seems to go one or two leve= ls down from a MST to an individual RTP flow, but we can let that develop o= n its own, separate from the timetable of webrtc 1.0 and unified plan.


--047d7b6da02872d46104f1887ec4-- From juberti@google.com Mon Feb 3 15:03: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 067981A0283 for ; Mon, 3 Feb 2014 15:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZf4072sT_nf for ; Mon, 3 Feb 2014 15:03:57 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 777CE1A0267 for ; Mon, 3 Feb 2014 15:03:57 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id ld13so5337905vcb.32 for ; Mon, 03 Feb 2014 15:03:57 -0800 (PST) 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=NmpAjSQu2E+olFt1dvp1OY1A/cy+m+SUFeTgwNNdL5Q=; b=obyp2mdq5j3S15Drjdzo7waV4y2o+zftiRSJfP8aN4ppPCNrCmgZs8OSTzoo27T2X8 OHT0iolbgbgmySnre5/ZpxtTF2W2un2T199xPQWmZ/h+hqouEGDkTabzDBbIh2WpX3v/ zXcofJJBV85DL5rdt4JScnHnvb23BLbYdDKjS+CjhlnLaa42gbBXeX/JlH7rNuunMhs4 tIXH322L8ucw0H++ltzUxLZ8V4bO8biAbJiULHV1BkLNU3oOkjciHlzzmeqnS9WKrQ/L hg0G4CEqIMfVQmTr2VUpCxi2eNyKpS3DitBCLzHFZo8vxMq58TJn2P3IMfqBS39p85tm Ze8A== 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=NmpAjSQu2E+olFt1dvp1OY1A/cy+m+SUFeTgwNNdL5Q=; b=ibGRg6CwLjnPX1Eilav2bAgNhCORssqcXlVEqgm39u31UCEVF6/zuJ+wyDq87QB6RK 4EZMm/clbxQ7EKSZO3o1xGptZ+SvelC6pOVpmqDx208hfwu2FEHygmt7MHVOaixRKyqh /HE6G9CANzJadAR1BAJDgBR530itygx4rPuFgKBhmVpRj3XgJkkMFK3IiGMtz8XeFlTx QAkWFvmKIawpARwJC/Xz24zULifw2vsZtf8P+e/CgQDYtkYfkhXLHU9tLsRYsUVqsepI gtSWngj0BuvqZyD5h/5BWx+VpAnOQuY/2gu6ugu8gkblQcyeJEu1Skv0B+QdUYTiRnqN r6vQ== X-Gm-Message-State: ALoCoQnVbzTShbgvtjrShAcIvoAtwatmhyB+Abql4bcM4VV2lTtSXx2fqMw/YkmmwhLHFn08TqVbTvK5LLhS5Q7h9Oba5LLsYLgMOypwmSfWC8BLVnh/6WWFSIy6iY7k6A2iqfYl+El3ydfWbgCVRZGVyOOSPC11rm/9nGhg4AE1G27eV4T1yGRNFaCqGatLdBW3hIiYIZ88 X-Received: by 10.58.48.133 with SMTP id l5mr54756ven.36.1391468637130; Mon, 03 Feb 2014 15:03:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 15:03:36 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Mon, 3 Feb 2014 15:03:36 -0800 Message-ID: To: Jonathan Lennox , Harald Alvestrand Content-Type: multipart/alternative; boundary=089e011844dad5304004f1888911 Cc: Cullen Jennings , "rtcweb@ietf.org" , mmusic Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 23:03:59 -0000 --089e011844dad5304004f1888911 Content-Type: text/plain; charset=UTF-8 +Harald as this affects the MSID doc On Mon, Feb 3, 2014 at 3:00 PM, Justin Uberti wrote: > > > > On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox wrote: > >> On Feb 3, 2014, at 2:27 PM, Justin Uberti wrote: >> >> Also, this essentially makes recv-appId the converse of MSID; for >> simplicity, I think we should consider unifying these concepts into a >> single document. >> >> >> AppID (as I envision it, as the author) and MSID (as I understand it) >> have rather different scopes, which are visible once sources are sent using >> more than one packet stream. >> >> For example, an m-line which has both a primary encoded stream (of >> media) and a redundancy stream (of rtx packets) would have two appid >> values, but only one msid. On the receive side, if you wanted to receive >> both a primary encoded stream and a redundancy stream, you would have two >> recv-appid values. >> >> As such, appid and msid are solving different (though related) >> problems, and I don't think unifying them is a good idea. >> >> Perhaps we need a recv-msid, explicitly? >> > > That would be fine by me - it would allow a single invention (msid + > recv-msid) to focus on solving the three identified problems with MSTs in > unified-plan: > - correlation of a MediaStreamTrack to m= line in signaling (msid) > - correlation of packets from a MST to m= line ahead of signaling > (recv-msid) > - rejection of an individual MST (recv-msid) > > Based on your description, appid seems to go one or two levels down from a > MST to an individual RTP flow, but we can let that develop on its own, > separate from the timetable of webrtc 1.0 and unified plan. > > > --089e011844dad5304004f1888911 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+Harald as this affects the MSID doc


On Mon, Feb 3, 2014 at 3:00 P= M, Justin Uberti <juberti@google.com> wrote:



On Mon, Feb 3= , 2014 at 2:32 PM, Jonathan Lennox <jonathan@vidyo.com> wro= te:
On Feb 3, 2014, at 2:27 PM, Justin Uberti <juberti@google.com>=C2=A0wrote:

Also, this essen= tially makes recv-appId the converse of MSID; for simplicity, I think we sh= ould consider unifying these concepts into a single document.

AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream.

For example, an m-line which has both a primary encoded stream (of med= ia) and a redundancy stream (of rtx packets) would have two appid values, b= ut only one msid. =C2=A0On the receive side, if you wanted to receive both = a primary encoded stream and a redundancy stream, you would have two recv-appid values.

As such, appid and msid are solving different (though related) problem= s, and I don't think unifying them is a good idea.

Perhaps we need a recv-msid, explicitly?
<= div>
That would be fine by me - it would allow a = single invention (msid + recv-msid) to focus on solving the three identifie= d problems with MSTs in unified-plan:
- correlation of a MediaStreamTrack to m=3D line in signaling (msid)
- correlation of packets from a MST to m=3D line ahead of signalin= g (recv-msid)
- rejection of an individual MST (recv-msid)

Based on your description, appid seems to go one or two leve= ls down from a MST to an individual RTP flow, but we can let that develop o= n its own, separate from the timetable of webrtc 1.0 and unified plan.



--089e011844dad5304004f1888911-- From fluffy@cisco.com Mon Feb 3 15:04: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 E22311A0282; Mon, 3 Feb 2014 15:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.036 X-Spam-Level: X-Spam-Status: No, score=-110.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 GIWZ1aKynrC6; Mon, 3 Feb 2014 15:04:19 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id A7C6B1A0267; Mon, 3 Feb 2014 15:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=556; q=dns/txt; s=iport; t=1391468659; x=1392678259; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zcCQH4Ox3RkF50xRpCJr9xU69MD1zSzBudpf2Xhhbrg=; b=IHuKhNGv5QUQ11YhAS1T1FKvx8UjsCBKpDp5V8DToW3TwlLKhgQi+ioB El6TIMB8MYGHl2X4yzg/wybufAa2W+o0a2L8HCx2DfWSSha4AIwBK7eQp 9V9l4wDc+I1En5FM+PwLlgj028ig4CnG+UQdXOWRY9GDyItjKBPi2f1gl Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFACwg8FKtJXHA/2dsb2JhbABZgwyBD74SgQ4WdIIlAQEBAwF5BQsCAQgYLjIlAgQOBYd9CM4fF4Jci3kzB4MkgRQBA5gqkiGDLYIq X-IronPort-AV: E=Sophos;i="4.95,775,1384300800"; d="scan'208";a="17648626" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-4.cisco.com with ESMTP; 03 Feb 2014 23:04:08 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s13N48Ip015958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 23:04:08 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 17:04:08 -0600 From: "Cullen Jennings (fluffy)" To: Adam Roach Thread-Topic: [rtcweb] Rejecting MediaStreamTracks in JSEP Thread-Index: AQHPIRX6Qu4MP4jRr0y9W7+nB8aK2pqkXPYAgAABqwCAAAS7AIAABcsAgAACEICAAAMlAIAADX2AgAAPCQA= Date: Mon, 3 Feb 2014 23:04:07 +0000 Message-ID: References: <52EFF9E0.40808@nostrum.com> <52EFFF3E.9080705@nostrum.com> <52F005D5.1020702@nostrum.com> <52F013C9.1090609@nostrum.com> In-Reply-To: <52F013C9.1090609@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 23:04:22 -0000 On Feb 3, 2014, at 3:10 PM, Adam Roach wrote: > On 2/3/14 15:22, Justin Uberti wrote: >>=20 >> I was thinking a=3Drecv-appId:0, which is both explicit, and has paralle= ls with the zero port form of rejecting a m=3D line. >>=20 >=20 > I have no objection to such an approach. >=20 > /a +1 with Adam on we need something explicitly somewhere.=20 If we do it with some combination msid / app-id - I just want to make sure = the behavior is still reasonable with things that don=92t low how to signal= ssrc.=20 = From jonathan@vidyo.com Mon Feb 3 15:11: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 962881A027B; Mon, 3 Feb 2014 15:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, 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 eP9ZrWI8L8oD; Mon, 3 Feb 2014 15:11:51 -0800 (PST) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) by ietfa.amsl.com (Postfix) with ESMTP id B53FE1A0268; Mon, 3 Feb 2014 15:11:50 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/3/2014 6:11:48 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: Too many policies to list X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-150/SG:5 2/3/2014 6:11:07 PM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.768449 p=-0.949192 Source White X-Signature-Violations: 0-0-0-12057-c X-Note-419: 15.6005 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/3/2014 6:11:30 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 94759713; Mon, 03 Feb 2014 18:11:48 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Mon, 3 Feb 2014 17:11:47 -0600 From: Jonathan Lennox To: Justin Uberti Thread-Topic: [rtcweb] Rejecting MediaStreamTracks in JSEP Thread-Index: AQHPIS46pADKsTFIzECMWWmLIWbna5qkgc6AgAAH3gCAAAMqAA== Date: Mon, 3 Feb 2014 23:11:46 +0000 Message-ID: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_9E51C939CCFE4EA683BF9B871D64CDA0vidyocom_" MIME-Version: 1.0 Cc: Cullen Jennings , Harald Alvestrand , "rtcweb@ietf.org" , mmusic Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Feb 2014 23:11:52 -0000 --_000_9E51C939CCFE4EA683BF9B871D64CDA0vidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Feb 3, 2014, at 6:00 PM, Justin Uberti > wrote: On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox > wrote: On Feb 3, 2014, at 2:27 PM, Justin Uberti > wrote: Also, this essentially makes recv-appId the converse of MSID; for simplicit= y, I think we should consider unifying these concepts into a single documen= t. AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream. For example, an m-line which has both a primary encoded stream (of media) a= nd a redundancy stream (of rtx packets) would have two appid values, but on= ly one msid. On the receive side, if you wanted to receive both a primary = encoded stream and a redundancy stream, you would have two recv-appid value= s. As such, appid and msid are solving different (though related) problems, an= d I don't think unifying them is a good idea. Perhaps we need a recv-msid, explicitly? That would be fine by me - it would allow a single invention (msid + recv-m= sid) to focus on solving the three identified problems with MSTs in unified= -plan: - correlation of a MediaStreamTrack to m=3D line in signaling (msid) - correlation of packets from a MST to m=3D line ahead of signaling (recv-m= sid) - rejection of an individual MST (recv-msid) Based on your description, appid seems to go one or two levels down from a = MST to an individual RTP flow, but we can let that develop on its own, sepa= rate from the timetable of webrtc 1.0 and unified plan. Points 1 and 3 make sense to me, and are I think what msid is for; but I do= n't think point 2 will work. I don't think a single, m-line-wide, identifier will work for the correlati= on-ahead-of-signaling problem, once you have multiple RTP flows in the m-li= ne. That's why we've designed appid the way we have. I think appid is the right solution to point 2. More specifically, the pro= blem appid is solving is better expressed as the correlation of packets fro= m an RTP flow to an m-line; the correlation from the m-line to a MST is a s= eparate step, and is msid's job. --_000_9E51C939CCFE4EA683BF9B871D64CDA0vidyocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7C716CFFAF8E1542879164DEF9D50ECF@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Feb 3, 2014, at 6:00 PM, Justin Uberti <juberti@google.com>
 wrote:

On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:
On Feb 3, 2014, at 2:27 PM, Justin Uberti <juberti@google.com> wrote:

Also, this essen= tially makes recv-appId the converse of MSID; for simplicity, I think we sh= ould consider unifying these concepts into a single document.

AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream.

For example, an m-line which has both a primary encoded stream (of med= ia) and a redundancy stream (of rtx packets) would have two appid values, b= ut only one msid.  On the receive side, if you wanted to receive both = a primary encoded stream and a redundancy stream, you would have two recv-appid values.

As such, appid and msid are solving different (though related) problem= s, and I don't think unifying them is a good idea.

Perhaps we need a recv-msid, explicitly?

That would be fine by me - it would allow a single invention (msid = 3; recv-msid) to focus on solving the three identified problems with MSTs i= n unified-plan:
- correlation of a MediaStreamTrack to m=3D line in signaling (msid)
- correlation of packets from a MST to m=3D line ahead of signaling (r= ecv-msid)
- rejection of an individual MST (recv-msid)

Based on your description, appid seems to go one or two levels down fr= om a MST to an individual RTP flow, but we can let that develop on its own,= separate from the timetable of webrtc 1.0 and unified plan.

Points 1 and 3 make sense to me, and are I think what msid is for; but= I don't think point 2 will work.

I don't think a single, m-line-wide, identifier will work for the corr= elation-ahead-of-signaling problem, once you have multiple RTP flows i= n the m-line.  That's why we've designed appid the way we have.

I think appid is the right solution to point 2.  More specificall= y, the problem appid is solving is better expressed as the correlation of p= ackets from an RTP flow to an m-line; the correlation from the m-line to a = MST is a separate step, and is msid's job.


--_000_9E51C939CCFE4EA683BF9B871D64CDA0vidyocom_-- From juberti@google.com Mon Feb 3 16:05: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 A29481A02B4 for ; Mon, 3 Feb 2014 16:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.313 X-Spam-Level: X-Spam-Status: No, score=-1.313 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_14=0.6, RP_MATCHES_RCVD=-0.535, 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 F_lo4o1XYpeb for ; Mon, 3 Feb 2014 16:05:37 -0800 (PST) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id B472A1A02A3 for ; Mon, 3 Feb 2014 16:05:36 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id la4so5213932vcb.21 for ; Mon, 03 Feb 2014 16:05:36 -0800 (PST) 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=7T/G6xCNG5X0+ybGVe9syqSR6QssH3tLZ7VPCIXII0Q=; b=mE7oCMucOTZl2CDcWx/RHTiFQKFoon9IrL3dyOAHZfHXZO7N0o7sdmSUokZMLPD+i5 bt4LVo4p17RsGj+4E8zfLgUHcB7MHDiM8J1zQDpeVoY2qRwIR13O5PZ4kHXoMGl1WqhJ Gat82KKN/ZY8noy7ZnqYK5k9NQT9eBlVN0hcOL8HKkK7A17rYIOGNF/DeSCctRF5S6WZ wJkVpndUOAKuhawlSu8YYyha+4reB842NEixQWNiLEnUyIAYtsf1d/ZJHw/6A4OgS1s2 QwoKDu1xiy/K8Hi21/jyqzkcmy0vIsNYclTATnTMte7cXS7lkLheFH1lpJU+bvY4D5ZJ iWLQ== 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=7T/G6xCNG5X0+ybGVe9syqSR6QssH3tLZ7VPCIXII0Q=; b=PC+zVSABZYdVWCK15uVHq4ZaSAGqPTnYCN76pYsgDou7tSuTsSUkt9+ikRhHN+XkBp OEzMLLpEq7AEZd20RvsszSuMtZsRCEzTZsGELYkPdhU7qF1dGEYJMZMv2SjxTjt9wvtv oZJomHsAa0AD2r1XH+AGeBrTtTH/EkGFPB7evfl3iL15uAtsPB90c/wQJtAjOxyMm2kj 22798mvmn/n0raVy4Qp3RGiytejboZe6+nFg756r/F30wzUCdtQTX4Nd1l3zwfHNi7cs peRi7MSQraKV2TVhNmkvbsHlkpNnwJMDLpBI9BzcRj/CBxfu6R0zpOPdFdgjmCLE+nS1 WFMw== X-Gm-Message-State: ALoCoQmsiLI/66tppBfKTnrUO34j2ZIdvxba088HrUYtV5R+GM37P5EMSIibrCE9IOY3Tp9C24qtFy8iPHO1M4b9Sc8rcyFV4C6peUbvu1Dmse/pcsADMhZbg/hxN2viSwvOfdJQ1oygaD/IzozSOjTW6H/FFShWleEhzAEjAlFMA2/EX+xUH80wtiC5TgIGzxCh2jt5rSjm X-Received: by 10.53.1.231 with SMTP id bj7mr611vdd.55.1391472336273; Mon, 03 Feb 2014 16:05:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 16:05:15 -0800 (PST) In-Reply-To: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.com> References: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.com> From: Justin Uberti Date: Mon, 3 Feb 2014 16:05:15 -0800 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a1133ed3a51b0a304f1896696 Cc: Cullen Jennings , Harald Alvestrand , "rtcweb@ietf.org" , mmusic Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Feb 2014 00:05:40 -0000 --001a1133ed3a51b0a304f1896696 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 3, 2014 at 3:11 PM, Jonathan Lennox wrote: > > On Feb 3, 2014, at 6:00 PM, Justin Uberti > wrote: > > On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox wrote: > >> On Feb 3, 2014, at 2:27 PM, Justin Uberti wrote: >> >> Also, this essentially makes recv-appId the converse of MSID; for >> simplicity, I think we should consider unifying these concepts into a >> single document. >> >> >> AppID (as I envision it, as the author) and MSID (as I understand it) >> have rather different scopes, which are visible once sources are sent using >> more than one packet stream. >> >> For example, an m-line which has both a primary encoded stream (of >> media) and a redundancy stream (of rtx packets) would have two appid >> values, but only one msid. On the receive side, if you wanted to receive >> both a primary encoded stream and a redundancy stream, you would have two >> recv-appid values. >> >> As such, appid and msid are solving different (though related) >> problems, and I don't think unifying them is a good idea. >> >> Perhaps we need a recv-msid, explicitly? >> > > That would be fine by me - it would allow a single invention (msid + > recv-msid) to focus on solving the three identified problems with MSTs in > unified-plan: > - correlation of a MediaStreamTrack to m= line in signaling (msid) > - correlation of packets from a MST to m= line ahead of signaling > (recv-msid) > - rejection of an individual MST (recv-msid) > > Based on your description, appid seems to go one or two levels down from > a MST to an individual RTP flow, but we can let that develop on its own, > separate from the timetable of webrtc 1.0 and unified plan. > > > Points 1 and 3 make sense to me, and are I think what msid is for; but I > don't think point 2 will work. > > I don't think a single, m-line-wide, identifier will work for the > correlation-ahead-of-signaling problem, once you have multiple RTP flows in > the m-line. That's why we've designed appid the way we have. > > I think appid is the right solution to point 2. More specifically, the > problem appid is solving is better expressed as the correlation of packets > from an RTP flow to an m-line; the correlation from the m-line to a MST is > a separate step, and is msid's job. > Agree that msid should map m-line to MST, but it would seem recv-msid could map RTP flow to m=line as well as indicate whether the receiver is in fact interested in receiving the MST associated with said m= line. Note that recv-msid doesn't specify an actual MSID; its purpose is to indicate that the receiver wants to receive data from the remote side's MST, and provide a mechanism for the sender to mark the data accordingly. (Which ends up seeming a lot like appid.) Generally, I am hesitant to depend on 3 things if we think we could get by with only 2. --001a1133ed3a51b0a304f1896696 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 3, 2014 at 3:11 PM, Jonathan Lennox &= lt;jonathan@vidyo.c= om> wrote:

On Feb 3, 2014, at 6:00 PM, Justin Uberti <juberti@google.com>
=C2=A0wrote:

On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:
On Feb 3, 2014, at 2:27 PM, Justin Uberti <juberti@google.com>=C2=A0wrote:

Also, this essen= tially makes recv-appId the converse of MSID; for simplicity, I think we sh= ould consider unifying these concepts into a single document.

AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream.

For example, an m-line which has both a primary encoded stream (of med= ia) and a redundancy stream (of rtx packets) would have two appid values, b= ut only one msid. =C2=A0On the receive side, if you wanted to receive both = a primary encoded stream and a redundancy stream, you would have two recv-appid values.

As such, appid and msid are solving different (though related) problem= s, and I don't think unifying them is a good idea.

Perhaps we need a recv-msid, explicitly?

That would be fine by me - it would allow a single invention (msid + r= ecv-msid) to focus on solving the three identified problems with MSTs in un= ified-plan:
- correlation of a MediaStreamTrack to m=3D line in signaling (msid)
- correlation of packets from a MST to m=3D line ahead of signaling (r= ecv-msid)
- rejection of an individual MST (recv-msid)

Based on your description, appid seems to go one or two levels down fr= om a MST to an individual RTP flow, but we can let that develop on its own,= separate from the timetable of webrtc 1.0 and unified plan.

Points 1 and 3 make sense to me, and are I think what msid is for; but= I don't think point 2 will work.

I don't think a single, m-line-wide, identifier will work for the = correlation-ahead-of-signaling=C2=A0problem, once you have multiple RTP flo= ws in the m-line. =C2=A0That's why we've designed appid the way we = have.

I think appid is the right solution to point 2. =C2=A0More specificall= y, the problem appid is solving is better expressed as the correlation of p= ackets from an RTP flow to an m-line; the correlation from the m-line to a = MST is a separate step, and is msid's job.

Agree that msid should ma= p m-line to MST, but it would seem recv-msid could map RTP flow to m=3Dline= as well as indicate whether the receiver is in fact interested in receivin= g the MST associated with said m=3D line. Note that recv-msid doesn't s= pecify an actual MSID; its purpose is to indicate that the receiver wants t= o receive data from the remote side's MST, and provide a mechanism for = the sender to mark the data accordingly. (Which ends up seeming a lot like = appid.)

Generally, I am hesitant to depend on 3 things if we th= ink we could get by with only 2.

--001a1133ed3a51b0a304f1896696-- From christer.holmberg@ericsson.com Tue Feb 4 06: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 586B11A00E9; Tue, 4 Feb 2014 06:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_14=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 HyCz_GhlXBrh; Tue, 4 Feb 2014 06:13:39 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 087FD1A00DB; Tue, 4 Feb 2014 06:13:37 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-dd-52f0f5901be8 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 6B.1F.04853.095F0F25; Tue, 4 Feb 2014 15:13:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Tue, 4 Feb 2014 15:13:36 +0100 From: Christer Holmberg To: Justin Uberti , Jonathan Lennox Thread-Topic: [rtcweb] Rejecting MediaStreamTracks in JSEP Thread-Index: AQHPIRX+Di2Spk3Lw0GdFyTxI3EbsJqkDKaAgAAH3QCAAAMrAIAADvGAgAD9W7A= Date: Tue, 4 Feb 2014 14:13:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15868E@ESESSMB209.ericsson.se> References: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D15868EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3RnfC1w9BBgsumFh0TGazOHHjNLPF /sXnmS22ThWymLr8MYvF2n/t7A5sHlN+b2T1WLCp1GPJkp9MHm3P7rAHsERx2aSk5mSWpRbp 2yVwZVz4NJ+9YEknY8XO/bOYGhjPtDJ2MXJySAiYSMz//4INwhaTuHBvPZgtJHCCUWLxbaUu Ri4gexGjxM5dJ9i7GDk42AQsJLr/aYOYIgI+Em82CYKUMAt0M0pcPNQDNlNYwFLiTsN9doga K4mV19NBwiICfhLfvl9gAbFZBFQkJm6aBmbzCvhKtD++ywKx6giTxPE/R9lBEpwCgRLTV3Uy gdiMQLd9P7UGzGYWEJe49WQ+E8TNAhJL9pxnhrBFJV4+/scKYStKtD9tYAS5gVkgX+LtKR2I XYISJ2c+YZnAKDoLyaRZCFWzkFRBhDUl1u/Sh6hWlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypGyeLU 4uLcdCMDvdz03BK91KLM5OLi/Dy94tRNjMBIPbjlt9EOxpN77A8xSnOwKInzXmetCRISSE8s Sc1OTS1ILYovKs1JLT7EyMTBKdXAmBl8OYO5yLhWdu3NiwaTy06on5JecXTdeY7iIs6+byw9 m66aVi7w9OPf1bDlkfriWEWvTqkd87atnljZk2kj0+P1dvanSk9lwazly9P9JxlWq67O/pvs zMjBwHtJM1JWyq6peHPRq425/yarTHlp0vrg8LQTCU5m7O8V/rMe0TJcuPun3hM/JZbijERD Leai4kQAZrZ5g6ICAAA= Cc: Cullen Jennings , Harald Alvestrand , "rtcweb@ietf.org" , mmusic Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Feb 2014 14:13:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D15868EESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkp1c3QgZm9yIG15IGNsYXJpZmljYXRpb246IG5vbmUgb2YgdGhpcyB3b3VsZCBoYXZl IGFueSBpbXBhY3Qgb24gdHJhbnNwb3J0IGxldmVsIGZlYXR1cmVzIHJlbGF0ZWQgdG8gUlRDUCwg U1RVTiwgZXRjPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IHJ0Y3dlYiBbbWFp bHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0K U2VudDogNC4gaGVsbWlrdXV0YSAyMDE0IDI6MDUNClRvOiBKb25hdGhhbiBMZW5ub3gNCkNjOiBD dWxsZW4gSmVubmluZ3M7IEhhcmFsZCBBbHZlc3RyYW5kOyBydGN3ZWJAaWV0Zi5vcmc7IG1tdXNp Yw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFJlamVjdGluZyBNZWRpYVN0cmVhbVRyYWNrcyBpbiBK U0VQDQoNCg0KDQpPbiBNb24sIEZlYiAzLCAyMDE0IGF0IDM6MTEgUE0sIEpvbmF0aGFuIExlbm5v eCA8am9uYXRoYW5AdmlkeW8uY29tPG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+PiB3cm90ZToN Cg0KT24gRmViIDMsIDIwMTQsIGF0IDY6MDAgUE0sIEp1c3RpbiBVYmVydGkgPGp1YmVydGlAZ29v Z2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4NCiB3cm90ZToNCg0KDQpPbiBNb24s IEZlYiAzLCAyMDE0IGF0IDI6MzIgUE0sIEpvbmF0aGFuIExlbm5veCA8am9uYXRoYW5AdmlkeW8u Y29tPG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+PiB3cm90ZToNCk9uIEZlYiAzLCAyMDE0LCBh dCAyOjI3IFBNLCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVy dGlAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQoNCkFsc28sIHRoaXMgZXNzZW50aWFsbHkgbWFrZXMg cmVjdi1hcHBJZCB0aGUgY29udmVyc2Ugb2YgTVNJRDsgZm9yIHNpbXBsaWNpdHksIEkgdGhpbmsg d2Ugc2hvdWxkIGNvbnNpZGVyIHVuaWZ5aW5nIHRoZXNlIGNvbmNlcHRzIGludG8gYSBzaW5nbGUg ZG9jdW1lbnQuDQoNCkFwcElEIChhcyBJIGVudmlzaW9uIGl0LCBhcyB0aGUgYXV0aG9yKSBhbmQg TVNJRCAoYXMgSSB1bmRlcnN0YW5kIGl0KSBoYXZlIHJhdGhlciBkaWZmZXJlbnQgc2NvcGVzLCB3 aGljaCBhcmUgdmlzaWJsZSBvbmNlIHNvdXJjZXMgYXJlIHNlbnQgdXNpbmcgbW9yZSB0aGFuIG9u ZSBwYWNrZXQgc3RyZWFtLg0KDQpGb3IgZXhhbXBsZSwgYW4gbS1saW5lIHdoaWNoIGhhcyBib3Ro IGEgcHJpbWFyeSBlbmNvZGVkIHN0cmVhbSAob2YgbWVkaWEpIGFuZCBhIHJlZHVuZGFuY3kgc3Ry ZWFtIChvZiBydHggcGFja2V0cykgd291bGQgaGF2ZSB0d28gYXBwaWQgdmFsdWVzLCBidXQgb25s eSBvbmUgbXNpZC4gIE9uIHRoZSByZWNlaXZlIHNpZGUsIGlmIHlvdSB3YW50ZWQgdG8gcmVjZWl2 ZSBib3RoIGEgcHJpbWFyeSBlbmNvZGVkIHN0cmVhbSBhbmQgYSByZWR1bmRhbmN5IHN0cmVhbSwg eW91IHdvdWxkIGhhdmUgdHdvIHJlY3YtYXBwaWQgdmFsdWVzLg0KDQpBcyBzdWNoLCBhcHBpZCBh bmQgbXNpZCBhcmUgc29sdmluZyBkaWZmZXJlbnQgKHRob3VnaCByZWxhdGVkKSBwcm9ibGVtcywg YW5kIEkgZG9uJ3QgdGhpbmsgdW5pZnlpbmcgdGhlbSBpcyBhIGdvb2QgaWRlYS4NCg0KUGVyaGFw cyB3ZSBuZWVkIGEgcmVjdi1tc2lkLCBleHBsaWNpdGx5Pw0KDQpUaGF0IHdvdWxkIGJlIGZpbmUg YnkgbWUgLSBpdCB3b3VsZCBhbGxvdyBhIHNpbmdsZSBpbnZlbnRpb24gKG1zaWQgKyByZWN2LW1z aWQpIHRvIGZvY3VzIG9uIHNvbHZpbmcgdGhlIHRocmVlIGlkZW50aWZpZWQgcHJvYmxlbXMgd2l0 aCBNU1RzIGluIHVuaWZpZWQtcGxhbjoNCi0gY29ycmVsYXRpb24gb2YgYSBNZWRpYVN0cmVhbVRy YWNrIHRvIG09IGxpbmUgaW4gc2lnbmFsaW5nIChtc2lkKQ0KLSBjb3JyZWxhdGlvbiBvZiBwYWNr ZXRzIGZyb20gYSBNU1QgdG8gbT0gbGluZSBhaGVhZCBvZiBzaWduYWxpbmcgKHJlY3YtbXNpZCkN Ci0gcmVqZWN0aW9uIG9mIGFuIGluZGl2aWR1YWwgTVNUIChyZWN2LW1zaWQpDQoNCkJhc2VkIG9u IHlvdXIgZGVzY3JpcHRpb24sIGFwcGlkIHNlZW1zIHRvIGdvIG9uZSBvciB0d28gbGV2ZWxzIGRv d24gZnJvbSBhIE1TVCB0byBhbiBpbmRpdmlkdWFsIFJUUCBmbG93LCBidXQgd2UgY2FuIGxldCB0 aGF0IGRldmVsb3Agb24gaXRzIG93biwgc2VwYXJhdGUgZnJvbSB0aGUgdGltZXRhYmxlIG9mIHdl YnJ0YyAxLjAgYW5kIHVuaWZpZWQgcGxhbi4NCg0KUG9pbnRzIDEgYW5kIDMgbWFrZSBzZW5zZSB0 byBtZSwgYW5kIGFyZSBJIHRoaW5rIHdoYXQgbXNpZCBpcyBmb3I7IGJ1dCBJIGRvbid0IHRoaW5r IHBvaW50IDIgd2lsbCB3b3JrLg0KDQpJIGRvbid0IHRoaW5rIGEgc2luZ2xlLCBtLWxpbmUtd2lk ZSwgaWRlbnRpZmllciB3aWxsIHdvcmsgZm9yIHRoZSBjb3JyZWxhdGlvbi1haGVhZC1vZi1zaWdu YWxpbmcgcHJvYmxlbSwgb25jZSB5b3UgaGF2ZSBtdWx0aXBsZSBSVFAgZmxvd3MgaW4gdGhlIG0t bGluZS4gIFRoYXQncyB3aHkgd2UndmUgZGVzaWduZWQgYXBwaWQgdGhlIHdheSB3ZSBoYXZlLg0K DQpJIHRoaW5rIGFwcGlkIGlzIHRoZSByaWdodCBzb2x1dGlvbiB0byBwb2ludCAyLiAgTW9yZSBz cGVjaWZpY2FsbHksIHRoZSBwcm9ibGVtIGFwcGlkIGlzIHNvbHZpbmcgaXMgYmV0dGVyIGV4cHJl c3NlZCBhcyB0aGUgY29ycmVsYXRpb24gb2YgcGFja2V0cyBmcm9tIGFuIFJUUCBmbG93IHRvIGFu IG0tbGluZTsgdGhlIGNvcnJlbGF0aW9uIGZyb20gdGhlIG0tbGluZSB0byBhIE1TVCBpcyBhIHNl cGFyYXRlIHN0ZXAsIGFuZCBpcyBtc2lkJ3Mgam9iLg0KDQpBZ3JlZSB0aGF0IG1zaWQgc2hvdWxk IG1hcCBtLWxpbmUgdG8gTVNULCBidXQgaXQgd291bGQgc2VlbSByZWN2LW1zaWQgY291bGQgbWFw IFJUUCBmbG93IHRvIG09bGluZSBhcyB3ZWxsIGFzIGluZGljYXRlIHdoZXRoZXIgdGhlIHJlY2Vp dmVyIGlzIGluIGZhY3QgaW50ZXJlc3RlZCBpbiByZWNlaXZpbmcgdGhlIE1TVCBhc3NvY2lhdGVk IHdpdGggc2FpZCBtPSBsaW5lLiBOb3RlIHRoYXQgcmVjdi1tc2lkIGRvZXNuJ3Qgc3BlY2lmeSBh biBhY3R1YWwgTVNJRDsgaXRzIHB1cnBvc2UgaXMgdG8gaW5kaWNhdGUgdGhhdCB0aGUgcmVjZWl2 ZXIgd2FudHMgdG8gcmVjZWl2ZSBkYXRhIGZyb20gdGhlIHJlbW90ZSBzaWRlJ3MgTVNULCBhbmQg cHJvdmlkZSBhIG1lY2hhbmlzbSBmb3IgdGhlIHNlbmRlciB0byBtYXJrIHRoZSBkYXRhIGFjY29y ZGluZ2x5LiAoV2hpY2ggZW5kcyB1cCBzZWVtaW5nIGEgbG90IGxpa2UgYXBwaWQuKQ0KDQpHZW5l cmFsbHksIEkgYW0gaGVzaXRhbnQgdG8gZGVwZW5kIG9uIDMgdGhpbmdzIGlmIHdlIHRoaW5rIHdl IGNvdWxkIGdldCBieSB3aXRoIG9ubHkgMi4NCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D15868EESESSMB209erics_ 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+SnVzdCBmb3IgbXkgY2xhcmlmaWNhdGlvbjogbm9uZSBvZiB0aGlzIHdvdWxkIGhhdmUg YW55IGltcGFjdCBvbiB0cmFuc3BvcnQgbGV2ZWwgZmVhdHVyZXMgcmVsYXRlZCB0byBSVENQLCBT VFVOLCBldGM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9iPiA0LiBoZWxt aWt1dXRhIDIwMTQgMjowNTxicj4NCjxiPlRvOjwvYj4gSm9uYXRoYW4gTGVubm94PGJyPg0KPGI+ Q2M6PC9iPiBDdWxsZW4gSmVubmluZ3M7IEhhcmFsZCBBbHZlc3RyYW5kOyBydGN3ZWJAaWV0Zi5v cmc7IG1tdXNpYzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gUmVqZWN0aW5nIE1l ZGlhU3RyZWFtVHJhY2tzIGluIEpTRVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRmViIDMsIDIwMTQgYXQgMzoxMSBQTSwgSm9u YXRoYW4gTGVubm94ICZsdDs8YSBocmVmPSJtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tIiB0YXJn ZXQ9Il9ibGFuayI+am9uYXRoYW5AdmlkeW8uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAzLCAyMDE0LCBhdCA2OjAw IFBNLCBKdXN0aW4gVWJlcnRpICZsdDs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+anViZXJ0aUBnb29nbGUuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBNb24sIEZlYiAzLCAyMDE0IGF0IDI6MzIgUE0sIEpvbmF0aGFuIExlbm5veCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpvbmF0 aGFuQHZpZHlvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAzLCAyMDE0 LCBhdCAyOjI3IFBNLCBKdXN0aW4gVWJlcnRpICZsdDs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBn b29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+anViZXJ0aUBnb29nbGUuY29tPC9hPiZndDsmbmJz cDt3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWxzbywgdGhpcyBl c3NlbnRpYWxseSBtYWtlcyByZWN2LWFwcElkIHRoZSBjb252ZXJzZSBvZiBNU0lEOyBmb3Igc2lt cGxpY2l0eSwgSSB0aGluayB3ZSBzaG91bGQgY29uc2lkZXIgdW5pZnlpbmcgdGhlc2UgY29uY2Vw dHMgaW50byBhIHNpbmdsZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXBwSUQgKGFz IEkgZW52aXNpb24gaXQsIGFzIHRoZSBhdXRob3IpIGFuZCBNU0lEIChhcyBJIHVuZGVyc3RhbmQg aXQpIGhhdmUgcmF0aGVyIGRpZmZlcmVudCBzY29wZXMsIHdoaWNoIGFyZSB2aXNpYmxlIG9uY2Ug c291cmNlcyBhcmUgc2VudCB1c2luZyBtb3JlIHRoYW4gb25lIHBhY2tldCBzdHJlYW0uDQo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBleGFtcGxlLCBh biBtLWxpbmUgd2hpY2ggaGFzIGJvdGggYSBwcmltYXJ5IGVuY29kZWQgc3RyZWFtIChvZiBtZWRp YSkgYW5kIGEgcmVkdW5kYW5jeSBzdHJlYW0gKG9mIHJ0eCBwYWNrZXRzKSB3b3VsZCBoYXZlIHR3 byBhcHBpZCB2YWx1ZXMsIGJ1dCBvbmx5IG9uZSBtc2lkLiAmbmJzcDtPbiB0aGUgcmVjZWl2ZSBz aWRlLCBpZiB5b3Ugd2FudGVkIHRvIHJlY2VpdmUgYm90aCBhIHByaW1hcnkgZW5jb2RlZCBzdHJl YW0NCiBhbmQgYSByZWR1bmRhbmN5IHN0cmVhbSwgeW91IHdvdWxkIGhhdmUgdHdvIHJlY3YtYXBw aWQgdmFsdWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BcyBzdWNoLCBhcHBpZCBhbmQgbXNpZCBhcmUgc29sdmluZyBkaWZmZXJlbnQgKHRo b3VnaCByZWxhdGVkKSBwcm9ibGVtcywgYW5kIEkgZG9uJ3QgdGhpbmsgdW5pZnlpbmcgdGhlbSBp cyBhIGdvb2QgaWRlYS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UGVyaGFwcyB3ZSBuZWVkIGEgcmVjdi1tc2lkLCBleHBsaWNpdGx5PzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYXQgd291bGQgYmUgZmluZSBieSBtZSAtIGl0IHdvdWxkIGFsbG93 IGEgc2luZ2xlIGludmVudGlvbiAobXNpZCAmIzQzOyByZWN2LW1zaWQpIHRvIGZvY3VzIG9uIHNv bHZpbmcgdGhlIHRocmVlIGlkZW50aWZpZWQgcHJvYmxlbXMgd2l0aCBNU1RzIGluIHVuaWZpZWQt cGxhbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0gY29ycmVsYXRpb24gb2YgYSBNZWRpYVN0cmVhbVRyYWNrIHRvIG09IGxpbmUgaW4gc2lnbmFs aW5nIChtc2lkKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LSBjb3JyZWxhdGlvbiBvZiBwYWNrZXRzIGZyb20gYSBNU1QgdG8gbT0gbGluZSBhaGVh ZCBvZiBzaWduYWxpbmcgKHJlY3YtbXNpZCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gcmVqZWN0aW9uIG9mIGFuIGluZGl2aWR1YWwgTVNUIChy ZWN2LW1zaWQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkJhc2VkIG9uIHlvdXIgZGVzY3JpcHRpb24sIGFwcGlkIHNlZW1zIHRvIGdvIG9uZSBv ciB0d28gbGV2ZWxzIGRvd24gZnJvbSBhIE1TVCB0byBhbiBpbmRpdmlkdWFsIFJUUCBmbG93LCBi dXQgd2UgY2FuIGxldCB0aGF0IGRldmVsb3Agb24gaXRzIG93biwgc2VwYXJhdGUgZnJvbSB0aGUg dGltZXRhYmxlIG9mIHdlYnJ0YyAxLjAgYW5kIHVuaWZpZWQgcGxhbi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UG9pbnRzIDEgYW5kIDMgbWFrZSBzZW5zZSB0byBtZSwgYW5kIGFyZSBJ IHRoaW5rIHdoYXQgbXNpZCBpcyBmb3I7IGJ1dCBJIGRvbid0IHRoaW5rIHBvaW50IDIgd2lsbCB3 b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGRvbid0IHRoaW5rIGEgc2luZ2xlLCBtLWxpbmUtd2lkZSwgaWRlbnRpZmllciB3aWxsIHdv cmsgZm9yIHRoZSBjb3JyZWxhdGlvbi1haGVhZC1vZi1zaWduYWxpbmcmbmJzcDtwcm9ibGVtLCBv bmNlIHlvdSBoYXZlIG11bHRpcGxlIFJUUCBmbG93cyBpbiB0aGUgbS1saW5lLiAmbmJzcDtUaGF0 J3Mgd2h5IHdlJ3ZlIGRlc2lnbmVkIGFwcGlkIHRoZSB3YXkgd2UgaGF2ZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgdGhpbmsgYXBwaWQgaXMgdGhlIHJpZ2h0IHNvbHV0aW9uIHRvIHBvaW50 IDIuICZuYnNwO01vcmUgc3BlY2lmaWNhbGx5LCB0aGUgcHJvYmxlbSBhcHBpZCBpcyBzb2x2aW5n IGlzIGJldHRlciBleHByZXNzZWQgYXMgdGhlIGNvcnJlbGF0aW9uIG9mIHBhY2tldHMgZnJvbSBh biBSVFAgZmxvdyB0byBhbiBtLWxpbmU7IHRoZSBjb3JyZWxhdGlvbiBmcm9tIHRoZSBtLWxpbmUg dG8gYSBNU1QgaXMgYSBzZXBhcmF0ZSBzdGVwLA0KIGFuZCBpcyBtc2lkJ3Mgam9iLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFncmVlIHRoYXQgbXNpZCBzaG91bGQgbWFwIG0tbGluZSB0byBNU1QsIGJ1 dCBpdCB3b3VsZCBzZWVtIHJlY3YtbXNpZCBjb3VsZCBtYXAgUlRQIGZsb3cgdG8gbT1saW5lIGFz IHdlbGwgYXMgaW5kaWNhdGUgd2hldGhlciB0aGUgcmVjZWl2ZXIgaXMgaW4gZmFjdCBpbnRlcmVz dGVkIGluIHJlY2VpdmluZyB0aGUgTVNUIGFzc29jaWF0ZWQgd2l0aCBzYWlkIG09IGxpbmUuIE5v dGUgdGhhdCByZWN2LW1zaWQgZG9lc24ndA0KIHNwZWNpZnkgYW4gYWN0dWFsIE1TSUQ7IGl0cyBw dXJwb3NlIGlzIHRvIGluZGljYXRlIHRoYXQgdGhlIHJlY2VpdmVyIHdhbnRzIHRvIHJlY2VpdmUg ZGF0YSBmcm9tIHRoZSByZW1vdGUgc2lkZSdzIE1TVCwgYW5kIHByb3ZpZGUgYSBtZWNoYW5pc20g Zm9yIHRoZSBzZW5kZXIgdG8gbWFyayB0aGUgZGF0YSBhY2NvcmRpbmdseS4gKFdoaWNoIGVuZHMg dXAgc2VlbWluZyBhIGxvdCBsaWtlIGFwcGlkLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2VuZXJhbGx5LCBJIGFtIGhlc2l0YW50IHRvIGRl cGVuZCBvbiAzIHRoaW5ncyBpZiB3ZSB0aGluayB3ZSBjb3VsZCBnZXQgYnkgd2l0aCBvbmx5IDIu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D15868EESESSMB209erics_-- From pkyzivat@alum.mit.edu Tue Feb 4 08:07: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 7FE181A0100 for ; Tue, 4 Feb 2014 08:07:55 -0800 (PST) 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 paJ1Fcw4kJeL for ; Tue, 4 Feb 2014 08:07:52 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBE81A0169 for ; Tue, 4 Feb 2014 08:07:52 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id NDos1n0051wpRvQ53G7sRr; Tue, 04 Feb 2014 16:07:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id NG7s1n0013ZTu2S3eG7sFK; Tue, 04 Feb 2014 16:07:52 +0000 Message-ID: <52F11057.8040708@alum.mit.edu> Date: Tue, 04 Feb 2014 11:07:51 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391530072; bh=1gRy8Blf94ZSqtu8qbYexKhlk9A53IIM/rJfLc4SW0s=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kwio86+n3MFIHsgUDAotUMiGEw1A2fRh71iwz9pSF8h65dDsgkiNO0R8pE6AAyca6 R9BXxTeLn6nZ3FXhaanN6icq6EOOAbLZLC2pIWM3i0p8c7a8y5mqCIaGZSMzZKSIqP 4hW7s7FdB4fvBdFREILRQWg61dsDBJY05bgnQRw8LVADhvNXN4G4RMyHnXjRDQNKnL Yap8e7jPe0RVmL894K/N+vhTJVIFsJ9foJLABHGFnFpEnIYjHhjutmXMFvBQ2ef74A v68KFN96hdu67XELRy8ikYzjf0tbNzn/LgUAl4VdsLqd5tiqXpAxNQTV9QZdtASACn r40Hkv4aGho1Q== Subject: [rtcweb] Data Channel question: correlating streams with channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Feb 2014 16:07:56 -0000 Section 6.4 of draft-ietf-rtcweb-data-channel-06 says: The realization of a bidirectional Data Channel is a pair of one incoming stream and one outgoing SCTP stream. Note that there's no requirement for the SCTP streams used to create a bidirectional channel have the same number in each direction. How stream values are selected is protocol and implementation dependent. The note seems to be something of a cop-out. But I'll accept for the moment that this can be true when external negotiation is used to define the channels. But I've looked through draft-ietf-rtcweb-data-protocol-01, and I don't find any specification there of how the pairing is done. Section 4 of the protocol draft says: The data channel protocol uses a two way handshake to open a data channel. The side wanting to open a data channel selects an unused Stream and sends a DATA_CHANNEL_OPEN message. The peer responds with a DATA_CHANNEL_ACK message. Then the data channel is open. The side doing the OPEN chooses what will be its outgoing stream id. That then becomes the incoming stream id of the peer. I had always assumed that the same stream id would be used for the ACK. But I find no evidence to support that assumption. For it to be anything else I would think the ACK would need to carry more information to correlate back to the OPEN message. Thanks, Paul From jonathan@vidyo.com Tue Feb 4 08:13: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 C60121A013B; Tue, 4 Feb 2014 08:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_SORBS_WEB=0.77, 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 65G6kVnehdtX; Tue, 4 Feb 2014 08:13:10 -0800 (PST) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1F81A0130; Tue, 4 Feb 2014 08:13:10 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/4/2014 11:13:08 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: Too many policies to list X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-340/SG:5 2/4/2014 11:12:32 AM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.737366 p=-0.935988 Source White X-Signature-Violations: 0-0-0-17513-c X-Note-419: 15.6003 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/4/2014 11:12:55 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 69264762; Tue, 04 Feb 2014 11:13:07 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Tue, 4 Feb 2014 10:13:06 -0600 From: Jonathan Lennox To: Justin Uberti Thread-Topic: [rtcweb] Rejecting MediaStreamTracks in JSEP Thread-Index: AQHPIS46pADKsTFIzECMWWmLIWbna5qkgc6AgAAH3gCAAAMqAIAADvKAgAEOagA= Date: Tue, 4 Feb 2014 16:13:06 +0000 Message-ID: <2DF6D660-78B3-4F53-AF39-B3651E9BBB46@vidyo.com> References: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_2DF6D66078B34F53AF39B3651E9BBB46vidyocom_" MIME-Version: 1.0 Cc: Cullen Jennings , Harald Alvestrand , "rtcweb@ietf.org" , mmusic Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Feb 2014 16:13:12 -0000 --_000_2DF6D66078B34F53AF39B3651E9BBB46vidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Feb 3, 2014, at 7:05 PM, Justin Uberti > wrote: On Mon, Feb 3, 2014 at 3:11 PM, Jonathan Lennox > wrote: On Feb 3, 2014, at 6:00 PM, Justin Uberti > wrote: On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox > wrote: On Feb 3, 2014, at 2:27 PM, Justin Uberti > wrote: Also, this essentially makes recv-appId the converse of MSID; for simplicit= y, I think we should consider unifying these concepts into a single documen= t. AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream. For example, an m-line which has both a primary encoded stream (of media) a= nd a redundancy stream (of rtx packets) would have two appid values, but on= ly one msid. On the receive side, if you wanted to receive both a primary = encoded stream and a redundancy stream, you would have two recv-appid value= s. As such, appid and msid are solving different (though related) problems, an= d I don't think unifying them is a good idea. Perhaps we need a recv-msid, explicitly? That would be fine by me - it would allow a single invention (msid + recv-m= sid) to focus on solving the three identified problems with MSTs in unified= -plan: - correlation of a MediaStreamTrack to m=3D line in signaling (msid) - correlation of packets from a MST to m=3D line ahead of signaling (recv-m= sid) - rejection of an individual MST (recv-msid) Based on your description, appid seems to go one or two levels down from a = MST to an individual RTP flow, but we can let that develop on its own, sepa= rate from the timetable of webrtc 1.0 and unified plan. Points 1 and 3 make sense to me, and are I think what msid is for; but I do= n't think point 2 will work. I don't think a single, m-line-wide, identifier will work for the correlati= on-ahead-of-signaling problem, once you have multiple RTP flows in the m-li= ne. That's why we've designed appid the way we have. I think appid is the right solution to point 2. More specifically, the pro= blem appid is solving is better expressed as the correlation of packets fro= m an RTP flow to an m-line; the correlation from the m-line to a MST is a s= eparate step, and is msid's job. Agree that msid should map m-line to MST, but it would seem recv-msid could= map RTP flow to m=3Dline as well as indicate whether the receiver is in fa= ct interested in receiving the MST associated with said m=3D line. Note tha= t recv-msid doesn't specify an actual MSID; its purpose is to indicate that= the receiver wants to receive data from the remote side's MST, and provide= a mechanism for the sender to mark the data accordingly. (Which ends up se= eming a lot like appid.) Generally, I am hesitant to depend on 3 things if we think we could get by = with only 2. I understand that, but I'm also hesitant to have one mechanism do two (it s= eems to me) fairly unrelated things, especially where the scenarios in whic= h the problems it's solving are applicable vary fairly widely. As far as I can tell, the only use case anyone's identified for MSID is Web= RTC, whereas the disambiguation problem occurs (and thus appid and recv-app= id are applicable) for anything using Bundle with Unified-like semantics. --_000_2DF6D66078B34F53AF39B3651E9BBB46vidyocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Feb 3, 2014, at 7:05 PM, Justin Uberti <juberti@google.com>
 wrote:

On Mon, Feb 3, 2014 at 3:11 PM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:

On Feb 3, 2014, at 6:00 PM, Justin Uberti <juberti@google.com>
 wrote:

On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:
On Feb 3, 2014, at 2:27 PM, Justin Uberti <juberti@google.com> wrote:

Also, this essen= tially makes recv-appId the converse of MSID; for simplicity, I think we sh= ould consider unifying these concepts into a single document.

AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream.

For example, an m-line which has both a primary encoded stream (of med= ia) and a redundancy stream (of rtx packets) would have two appid values, b= ut only one msid.  On the receive side, if you wanted to receive both = a primary encoded stream and a redundancy stream, you would have two recv-appid values.

As such, appid and msid are solving different (though related) problem= s, and I don't think unifying them is a good idea.

Perhaps we need a recv-msid, explicitly?

That would be fine by me - it would allow a single invention (msid = 3; recv-msid) to focus on solving the three identified problems with MSTs i= n unified-plan:
- correlation of a MediaStreamTrack to m=3D line in signaling (msid)
- correlation of packets from a MST to m=3D line ahead of signaling (r= ecv-msid)
- rejection of an individual MST (recv-msid)

Based on your description, appid seems to go one or two levels down fr= om a MST to an individual RTP flow, but we can let that develop on its own,= separate from the timetable of webrtc 1.0 and unified plan.

Points 1 and 3 make sense to me, and are I think what msid is for; but= I don't think point 2 will work.

I don't think a single, m-line-wide, identifier will work for the corr= elation-ahead-of-signaling problem, once you have multiple RTP flows i= n the m-line.  That's why we've designed appid the way we have.

I think appid is the right solution to point 2.  More specificall= y, the problem appid is solving is better expressed as the correlation of p= ackets from an RTP flow to an m-line; the correlation from the m-line to a = MST is a separate step, and is msid's job.

Agree that msid should map m-line to MST, but it would seem recv-msid = could map RTP flow to m=3Dline as well as indicate whether the receiver is = in fact interested in receiving the MST associated with said m=3D line. Not= e that recv-msid doesn't specify an actual MSID; its purpose is to indicate that the receiver wants to receive= data from the remote side's MST, and provide a mechanism for the sender to= mark the data accordingly. (Which ends up seeming a lot like appid.)

Generally, I am hesitant to depend on 3 things if we think we could ge= t by with only 2.

I understand that, but I'm also hesitant to have one mechanism do two (it s= eems to me) fairly unrelated things, especially where the scenarios in whic= h the problems it's solving are applicable vary fairly widely.

As far as I can tell, the only use case anyone's identified for MSID i= s WebRTC, whereas the disambiguation problem occurs (and thus appid and rec= v-appid are applicable) for anything using Bundle with Unified-like semanti= cs.

--_000_2DF6D66078B34F53AF39B3651E9BBB46vidyocom_-- From jonathan@vidyo.com Tue Feb 4 08:13: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 B8CDA1A01D1; Tue, 4 Feb 2014 08:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_SORBS_WEB=0.77, 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 FRJzJCejfRfc; Tue, 4 Feb 2014 08:13:47 -0800 (PST) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) by ietfa.amsl.com (Postfix) with ESMTP id CE44C1A01C1; Tue, 4 Feb 2014 08:13:46 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/4/2014 11:13:44 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: Too many policies to list X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-335/SG:5 2/4/2014 11:13:29 AM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.737767 p=-0.951788 Source White X-Signature-Violations: 0-0-0-25457-c X-Note-419: 15.6005 ms. Fail:1 Chk:1345 of 1345 total X-Note: SCH-CT/SI:1-1345/SG:1 2/4/2014 11:13:34 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 94921056; Tue, 04 Feb 2014 11:13:44 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Tue, 4 Feb 2014 10:13:43 -0600 From: Jonathan Lennox To: Christer Holmberg Thread-Topic: [rtcweb] Rejecting MediaStreamTracks in JSEP Thread-Index: AQHPIS46pADKsTFIzECMWWmLIWbna5qkgc6AgAAH3gCAAAMqAIAADvKAgADtBYCAACGQAA== Date: Tue, 4 Feb 2014 16:13:42 +0000 Message-ID: References: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D15868E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15868E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_B9399713DDEF4680B5E4E9C817372133vidyocom_" MIME-Version: 1.0 Cc: Cullen Jennings , Harald Alvestrand , "rtcweb@ietf.org" , mmusic Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Feb 2014 16:13:50 -0000 --_000_B9399713DDEF4680B5E4E9C817372133vidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MSID doesn't affect the transport level. Appid, however, defines an RTCP S= DES item, and an RTP header extension. On Feb 4, 2014, at 9:13 AM, Christer Holmberg > wrote: Hi, Just for my clarification: none of this would have any impact on transport = level features related to RTCP, STUN, etc? Regards, Christer From: rtcweb [mailto:rtcweb-bounces@ietf.org] On B= ehalf Of Justin Uberti Sent: 4. helmikuuta 2014 2:05 To: Jonathan Lennox Cc: Cullen Jennings; Harald Alvestrand; rtcweb@ietf.org; mmusic Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP On Mon, Feb 3, 2014 at 3:11 PM, Jonathan Lennox > wrote: On Feb 3, 2014, at 6:00 PM, Justin Uberti > wrote: On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox > wrote: On Feb 3, 2014, at 2:27 PM, Justin Uberti > wrote: Also, this essentially makes recv-appId the converse of MSID; for simplicit= y, I think we should consider unifying these concepts into a single documen= t. AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream. For example, an m-line which has both a primary encoded stream (of media) a= nd a redundancy stream (of rtx packets) would have two appid values, but on= ly one msid. On the receive side, if you wanted to receive both a primary = encoded stream and a redundancy stream, you would have two recv-appid value= s. As such, appid and msid are solving different (though related) problems, an= d I don't think unifying them is a good idea. Perhaps we need a recv-msid, explicitly? That would be fine by me - it would allow a single invention (msid + recv-m= sid) to focus on solving the three identified problems with MSTs in unified= -plan: - correlation of a MediaStreamTrack to m=3D line in signaling (msid) - correlation of packets from a MST to m=3D line ahead of signaling (recv-m= sid) - rejection of an individual MST (recv-msid) Based on your description, appid seems to go one or two levels down from a = MST to an individual RTP flow, but we can let that develop on its own, sepa= rate from the timetable of webrtc 1.0 and unified plan. Points 1 and 3 make sense to me, and are I think what msid is for; but I do= n't think point 2 will work. I don't think a single, m-line-wide, identifier will work for the correlati= on-ahead-of-signaling problem, once you have multiple RTP flows in the m-li= ne. That's why we've designed appid the way we have. I think appid is the right solution to point 2. More specifically, the pro= blem appid is solving is better expressed as the correlation of packets fro= m an RTP flow to an m-line; the correlation from the m-line to a MST is a s= eparate step, and is msid's job. Agree that msid should map m-line to MST, but it would seem recv-msid could= map RTP flow to m=3Dline as well as indicate whether the receiver is in fa= ct interested in receiving the MST associated with said m=3D line. Note tha= t recv-msid doesn't specify an actual MSID; its purpose is to indicate that= the receiver wants to receive data from the remote side's MST, and provide= a mechanism for the sender to mark the data accordingly. (Which ends up se= eming a lot like appid.) Generally, I am hesitant to depend on 3 things if we think we could get by = with only 2. --_000_B9399713DDEF4680B5E4E9C817372133vidyocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
MSID doesn't affect the transport level.  Appid, however, defines= an RTCP SDES item, and an RTP header extension.

On Feb 4, 2014, at 9:13 AM, Christer Holmberg <christer.holmberg@ericsson.com>
 wrote:

Hi,
 
Just for my clarification: none of this would have any im= pact on transport level features related to RTCP, STUN, etc?
 
Regards,
 
Christer
 
 
From:=  rtcweb [mailto:rtcweb= -bounces@ietf.org]=  On Behalf Of Justin Ube= rti
Sent: 4. helmikuut= a 2014 2:05
To: Jonathan Lenno= x
Cc: Cullen Jenning= s; Harald Alvestrand; rtcweb@ietf.org; mmusic
Subject: Re: [rtcw= eb] Rejecting MediaStreamTracks in JSEP
 
 

 

On Mon, Feb 3, 2014 at 3:11 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:
 
On Feb 3, 2014, at 6:00 PM, Justin Uberti <juberti@google.com>
 wrote:


On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:
On Feb 3, 2014, at 2:27 PM, Justin Uberti <juberti@google.com> wrote:


Also, thi= s essentially makes recv-appId the converse of MSID; for simplicity, I thin= k we should consider unifying these concepts into a single document.
 
AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream.
 
For example, an m-line which has both a primary encoded stream (of media) a= nd a redundancy stream (of rtx packets) would have two appid values, but on= ly one msid.  On the receive side, if you wanted to receive both a pri= mary encoded stream and a redundancy stream, you would have two recv-appid values.
 
As such, appid and msid are solving different (though related) problems, an= d I don't think unifying them is a good idea.
 
Perhaps we need a recv-msid, explicitly?
 
That would be fine by me - it would allow a single invention (msid + re= cv-msid) to focus on solving the three identified problems with MSTs in uni= fied-plan:
- correlation of a MediaStreamTrack to m=3D line in signaling (msid)
- correlation of packets from a MST to m=3D line ahead of signaling (recv-m= sid)
- rejection of an individual MST (recv-msid)
 
Based on your description, appid seems to go one or two levels down from a = MST to an individual RTP flow, but we can let that develop on its own, sepa= rate from the timetable of webrtc 1.0 and unified plan.
 
Points 1 and 3 make sense to me, and are I think what msid is for; but I do= n't think point 2 will work.
 
I don't think a single, m-line-wide, identifier will work for the correlati= on-ahead-of-signaling problem, once you have multiple RTP flows in the= m-line.  That's why we've designed appid the way we have.<= /div>
 
I think appid is the right solution to point 2.  More specifically, th= e problem appid is solving is better expressed as the correlation of packet= s from an RTP flow to an m-line; the correlation from the m-line to a MST i= s a separate step, and is msid's job.
 
Agree that msid should map m-line to MST, but it would seem recv-msid could= map RTP flow to m=3Dline as well as indicate whether the receiver is in fa= ct interested in receiving the MST associated with said m=3D line. Note tha= t recv-msid doesn't specify an actual MSID; its purpose is to indicate that the receiver wants to receive data f= rom the remote side's MST, and provide a mechanism for the sender to mark t= he data accordingly. (Which ends up seeming a lot like appid.)
 
Generally, I am hesitant to depend on 3 things if we think we could get by = with only 2.
 

--_000_B9399713DDEF4680B5E4E9C817372133vidyocom_-- From rmohanr@cisco.com Tue Feb 4 22:19: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 A1D051A0047 for ; Tue, 4 Feb 2014 22:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.436 X-Spam-Level: X-Spam-Status: No, score=-14.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 DyYlYhSyqJoM for ; Tue, 4 Feb 2014 22:19:18 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8EE1A0045 for ; Tue, 4 Feb 2014 22:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7431; q=dns/txt; s=iport; t=1391581158; x=1392790758; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=IzGkzFchKYBD70bVsRZquVvC22NbOJeRD6SzWlx464c=; b=HKcLFxxbZKZOy5iVoopTfbOidGsdwUAcUPFko2V8V6TXt5uvqkjUZwz/ obU/kZUL+fFsYS+7Jg0N42Gy/+eqkD7HhDkFHRMWzc2gKRUVJbY/rZqJT OVGpwaBoBeTId8bnA5SZklxNlv+0Y+aaew80+SlWMm4YAEbMfTBlNMvCH I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFABvX8VKtJXG8/2dsb2JhbABZgwyBD75MgQcWdIIlAQEBBAx5AgICAQgRAwEBAQEYDwcbFxQJCAIEARKIBc5IFwSODxEBVwYShCAEiRGKb4QrkiGDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,785,1384300800"; d="scan'208";a="301954787" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 05 Feb 2014 06:19:16 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s156JG1K001673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 06:19:16 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.191]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 00:19:15 -0600 From: "Ram Mohan R (rmohanr)" To: "rtcweb@ietf.org" , Magnus Westerlund Thread-Topic: Comments on draft-ietf-rtcweb-stun-consent-freshness-00 Thread-Index: AQHO37eJ8ro8smXte0emoSniQAx1D5olYa0AgAEGPACAajfBYIAW1hEA Date: Wed, 5 Feb 2014 06:19:14 +0000 Message-ID: References: <5285E318.3090006@ericsson.com> <913383AAA69FF945B8F946018B75898A2428EC28@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2428EC28@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [72.163.212.124] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <800BA6F97370BB4A9943E82F9C6083FD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-stun-consent-freshness-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Feb 2014 06:19:20 -0000 Hi Magnus, Sorry for delay. Please see inline for answers >-----Original Message----- >From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >Sent: Friday, November 15, 2013 2:32 PM >To: Ram Mohan R (rmohanr); >draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org; rtcweb@ietf.org >Subject: Re: Comments on draft-ietf-rtcweb-stun-consent-freshness-00 > >Hi, > >Removing things where I am in agreement or like your response. > >On 2013-11-14 18:23, Ram Mohan R (rmohanr) wrote: >> Hi Magnus, >>=20 >> Thanks for your comments. Please see inline for responses. >>=20 >>=20 >> -----Original Message----- >> From: Magnus Westerlund >> Date: Tuesday, 12 November 2013 8:28 PM > >>> >>> 3. Section 1: >>> "This document describes a new STUN usage with a request and response >>> which verifies the remote peer consents to receive traffic, and >>> detects loss of liveness." >>> >>> I am missing a word after "request and response", transaction or >>> messages maybe? >>=20 >> NEW: >> This document describes a new STUN usage with a request and response >> messages which verifies the remote peer consents to receive traffic, >> and detects loss of liveness. > >Isn't it either "which verifies the remote peer's consent to" or "which >verifies that the remote peer consents to"? I will change to "which verifies the remote peer's consent to=B2 > > > >> >>> >>> 5. Section 4: >>> Consent freshness serves as a circuit breaker (so that if the path or >>> remote peer fails the WebRTC browser stops sending all traffic on >>> that remote peer), determining session liveness serves the purpose of >>> notifying the application of connectivity failure so that the >>> application can take appropriate action. >>> >>=20 >>> >>> What is the definition of a peer here? >>=20 >> Peer is the sink for the traffic originated from the sender for that >> flow >> (5 tuple). If a browser uses different 5 tuple for each stream(Audio, >> video, data) it sends then it should do consent for each flow. If it >> uses same 5-tuple (mux case) then there will be only one consent. > >Please be explicit about this. I think it is easy to interpret that this >would apply to all flows from one end-point to a given destination >address. Sure. We will add the above text and make it clearer in Section 4 > >>=20 >>=20 >>=20 >>> What scope does the stop sending >>> have? >>=20 >> The stream that is being sent on a flow(5 tuple) for which a consent >> has failed will be stopped. If all the streams are muxed on a same 5 >> tuple the entire traffic will be stopped. >>=20 > >I am fine with this, as long as the document is explicit about this being >the scope. Will make this explicit in the draft > > >>> >>> 6. Section 4: >>> 1. A consent timer, Tc, whose value is determined by the browser. >>> This value MUST be 15 seconds. >>> >>> I see a contradiction here, should it be determined by the browser or >>> be >>> 15 s? If it is 15, can you please motivate why it is this value, or >>> point to where it is motivated? >>=20 >> The default value of 15 was some thing that EKR and Justin gave us >> based on the implementation/testing and fine tuning they have done on >> their browsers. I agree we can have some text around it that explains >> how this number is arrived. We will add the same. > >Good, I think it is important we understand the considerations of why >this is a reasonable choice. Sure. Will check with Justin/EKR and add some text that justifies why 15 sec is default. > > >>> >>> 8. Section 4: >>> If a valid STUN Binding Response is not received after 500ms, the >>> STUN Binding Request is retransmitted (with the same Transaction ID >>> and all other fields). As long as a valid STUN Binding Response is >>> not received, this retransmission is repeated every 500ms until Tf >>> seconds have elapsed or a valid response is received. >>> >>> So no exponential back-off on the retransmission timer. I think that >>> is fine. However, I think it do require you to expand a bit on what >>> happens when one gets multiple response on the same Transaction ID. >>> For example additional responses do they or do they not reset the Tc >>>timer? >>=20 >> Additional responses MUST reset the Tc timer. >>=20 > >Okay, that appears fine. > >>=20 >>> >>> Then I wonder about the cases where the RTT is above 500 ms, should >>> one then scale this factor to be once per RTT? > >What about this question? The ICE agent can learn the RTT of a given path from RTCP reports (if present). If there is no RTCP reports then it can use STUN BindReq/Res to learn RTT. STUN allows you to learn the RTT of a path when you sending Binding request and get a Binding response for a candidate pair. Before consent timer is started the browser=B9s ICE agent would have done ICE checks and concluded on a candidate for each media stream. So an ICE agent can use the RTT learnt here. Thoughts on this ? > >>> >>> 9. Section 4: >>> "with the same Transaction ID" >>> >>> Why not use a new transaction ID for each sent packet? It would allow >>> tracking loss and determine RTT more reliable. All for the small cost >>> of keeping track of slightly more Transaction IDs? >>=20 >> Yes, new transaction ID will help to determine the packet loss and RTT. >>=20 > >Yes, so what is preferable here? Doing cloned retransmission, or >generating new TIDs for each outgoing request? Using same Transaction ID would lead the peer ICE agent think this request as a retransmission and it may not reset its Consent timer. So I think using new ID is better. > >>=20 >>=20 >>> >>> 10. Section 4. >>> Liveness timer: If no packets have been received on the local port in >>> Tr seconds, the WebRTC browser MUST inform the JavaScript that >>> connectivity has been lost. The JavaScript application will use this >>> notification however it desires (e.g., cease transmitting to the >>> remote peer, provide a notification to the user, etc.). Note the >>> definition of a received packet is liberal, and includes an SRTP >>> packet that fails authentication, a STUN Binding Request with an >>> invalid USERNAME or PASSWORD, or any other packet. >>> >>> I think this requires some considerations in regards to RTT. If the >>> RTT is 700 ms, high for a real-time app but not unheard of at all. >>> Then a Tr =3D 1 second would fire on a single loss. >>=20 >> Ok. will start a discussion for this item in a separate email. >>=20 As discussed above the ICE agent can learn the RTT of a given path from RTCP reports (if present) or compute the RTT from STUN BindReq/Response. It can then use the learnt value to influence the Tr value. Regards, Ram > >Good > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > From christer.holmberg@ericsson.com Wed Feb 5 03:23: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 0A4D71A00B2 for ; Wed, 5 Feb 2014 03:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 i77HRG28gype for ; Wed, 5 Feb 2014 03:23:39 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFA31A00DE for ; Wed, 5 Feb 2014 03:23:38 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-ac-52f21f39c7d3 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 8F.5B.04853.93F12F25; Wed, 5 Feb 2014 12:23:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 12:23:36 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: RTCWEB Data Channel: Usage of PPID for protocol multiplexing Thread-Index: Ac8iY/biToYKPFP2T8+rOyj46vmc1w== Date: Wed, 5 Feb 2014 11:23:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@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.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D15BD1AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+Jvja6l/Kcgg/Wn+C3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxt17F1gLfmpVzJ22l7WBcYJqFyMnh4SAicTZCavZIGwxiQv3 1gPZXBxCAicYJc5/7GWFcBYxSizvPMncxcjBwSZgIdH9TxukQURAXeLywwvsILawgKvEtTPH mCHiXhILt3exg5SLCOhJrJ1jCxJmEVCRmLX5KlgJr4CvRP+ywywgNiPQ3u+n1jCB2MwC4hK3 nsxngrhHQGLJnvPMELaoxMvH/1hBRkoIKEos75eDKM+XeLNwFRvESEGJkzOfsExgFJqFZNIs JGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYySxanFxbnpRgZ6uem5JXqpRZnJ xcX5eXrFqZsYgXFxcMtvox2MJ/fYH2KU5mBREue9zloTJCSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoGxzitMiqvn2N45b88sneJxRuHRMRcnxw81CVdyzt/ifrT4TN7fk+0ZAZ7LFL9Etf7U FmTK2rVoZfnTrGS3FHkH/9nipg9n8KvkbOR4X8Pbtcuk4rJ0amDs9dCSGxcsA43v7Z2m2SS2 ROGT3ub37Ymrt7t7Ce7Y5mW/39Hxwsy5517P/7GJgcNBiaU4I9FQi7moOBEAMwPN71kCAAA= Subject: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Feb 2014 11:23:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D15BD1AESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is related to the e-mail Paul sent yesterday (Data Channel question: c= orrelating streams with channels). Section 5 of draft-ietf-rtcweb-data-channel-06 says: "Each SCTP user message contains a so called Payload Protocol Identifier (PPID) that is passed to SCTP by its upper layer= and sent to its peer. This value can be used to multiplex multiple = protocols over a single SCTP association. The sender provides for ea= ch protocol a specific PPID and the receiver can demultiplex t= he messages based on the received PPID." Now, when I look at the IANA registration page for PPID values, most seem t= o be associated with specific protocols. However, if I e.g. use PPID values 51-54 (as rtcweb applications will do) t= hey don't say anything about the protocol. They refer to an encoding format= , and multiple protocols may have the same format. I would assume that the SCTP stream id would have to be used to multiplex p= rotocols. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D15BD1AESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

This is related to the e-mail Paul sent yesterday (D= ata Channel question: correlating streams with channels).

 

Section 5 of draft-ietf-rtcweb-data-channe= l-06 says:

 

“Each SCTP user m= essage contains a so called Payload Protocol

         &nb= sp;      Identifier (PPID) that is passed to SCTP = by its upper layer and sent

         &nb= sp;      to its peer.  This value can be used= to multiplex multiple protocols

         &nb= sp;      over a single SCTP association.  The= sender provides for each

         &nb= sp;      protocol a specific PPID and the receiver= can demultiplex the

         &nb= sp;      messages based on the received PPID.̶= 1;

 

Now, when I look at the IANA registration page for P= PID values, most seem to be associated with specific protocols.

 

However, if I e.g. use PPID values 51-54 (as rtcweb = applications will do) they don’t say anything about the protocol. The= y refer to an encoding format, and multiple protocols may have the same for= mat.

 

I would assume that the SCTP stream id would have to= be used to multiplex protocols.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D15BD1AESESSMB209erics_-- From pthatcher@google.com Wed Feb 5 10:40: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 4894C1A0140 for ; Wed, 5 Feb 2014 10:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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.535, 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 qInAPbw1dH3e for ; Wed, 5 Feb 2014 10:40:34 -0800 (PST) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 51F1F1A0138 for ; Wed, 5 Feb 2014 10:40:34 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id jt11so720549pbb.29 for ; Wed, 05 Feb 2014 10:40:33 -0800 (PST) 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=5sQPrPycpJfZYkjG4ug/ERdvpNb1+BFmQw2BxPkgi9E=; b=GKEH6Nl+WD8pHye8nHch2Vyoggp+6bq3QoxZ88l+I6xkZ7hiaH3CrRk7Dv7j35q0rD bHgAYYiLRw+vHuafOPzHakX7uUXkPK2bNTUQUYolCzSgNoGvqZJRTgzHe0KzLvgcRFQK 69w9NGmN6MRn7c6YOkrBFrzo9RlL++TjX6CRQPQfGwjNNmDWSxYVFZZruA6KUrs1zoCq stAZTOhoPHd5plxkdNzUsZO0RiUFbNmQmt7IW0Swsut5we/iBMMcAi9XT2C6JfFdxq7a R7EHLFXg/PyVFgjHhyDPUEqw5MtDmHP/opHJXI4iZjI2sny+mjktkWpHjcX7JBt6Mo+M 4N7g== 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=5sQPrPycpJfZYkjG4ug/ERdvpNb1+BFmQw2BxPkgi9E=; b=Aaax3Ofr8Z30t7hqq/OfIrXRT1yun0KWboPepqCZT+RXIIYUUZO2FeDXbAdT9IGFmu TYyx9XcEEWAJ9cLn8SqN9poOooufj8PsAEXHHSnMcmgenYCiJv53jx2neeL258teFs6C A1eqsMgVr/Gvn/tAhd1AZjsM9Uz00RUuRrimiF0X9IQd8wVTtu8gDp0jqBkvuSKBT0xi nYbXA1mgilIDozKHPgfMwO0LorbjsnBZaD5vtH7lvkesLN/qBj9lzUnYt5cqNytK+q6d XmU/dg+M0qvR1UuRGMOs4+RIaK0PJGBXfa+4rICaIURiqmtBWRYCLUds89769KLI53ib 8DuQ== X-Gm-Message-State: ALoCoQkLZN00Q3PkXvotcp3mSUB02YDREStLtciBew6qu6Io0ImBxoFEH1TI37jqCQm05nx0/qXpGRAwPfe7kl9oOnzSuYcRx87AIurjipWucCQ9Svyf50VVJQm0jwDff7OpVz8VVelpBa2nhygSZDTKFyL5U3xL/w/w9OKa5b0J9cruiihNUTCsml1RMC1VwZoSWQM+xJf+ X-Received: by 10.68.111.65 with SMTP id ig1mr4188677pbb.3.1391625633630; Wed, 05 Feb 2014 10:40:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.163.234 with HTTP; Wed, 5 Feb 2014 10:39:53 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Wed, 5 Feb 2014 10:39:53 -0800 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Feb 2014 18:40:36 -0000 The PPID isn't exposed to the application. It's just used to distinguish text/binary/control. If an application uses different data channels with different protocols, it should use the SID to distinguish between them, not the PPID. In fact, even if it wanted to use the PPID, it wouldn't be able to. On Wed, Feb 5, 2014 at 3:23 AM, Christer Holmberg wrote: > Hi, > > > > This is related to the e-mail Paul sent yesterday (Data Channel question: > correlating streams with channels). > > > > Section 5 of draft-ietf-rtcweb-data-channel-06 says: > > > > =E2=80=9CEach SCTP user message contains a so called Payload Protocol > > Identifier (PPID) that is passed to SCTP by its upper lay= er > and sent > > to its peer. This value can be used to multiplex multipl= e > protocols > > over a single SCTP association. The sender provides for > each > > protocol a specific PPID and the receiver can demultiplex > the > > messages based on the received PPID.=E2=80=9D > > > > Now, when I look at the IANA registration page for PPID values, most seem= to > be associated with specific protocols. > > > > However, if I e.g. use PPID values 51-54 (as rtcweb applications will do) > they don=E2=80=99t say anything about the protocol. They refer to an enco= ding > format, and multiple protocols may have the same format. > > > > I would assume that the SCTP stream id would have to be used to multiplex > protocols. > > > > Regards, > > > > Christer > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From Raju.Makaraju@alcatel-lucent.com Wed Feb 5 12: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 CABEF1A01D1 for ; Wed, 5 Feb 2014 12:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 eFZJhAYQzb8E for ; Wed, 5 Feb 2014 12:40:36 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C4AD91A01CC for ; Wed, 5 Feb 2014 12:40:36 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s15KeWqM027816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 14:40:33 -0600 (CST) 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 s15KeWgT005865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 15:40:32 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 5 Feb 2014 15:40:32 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Peter Thatcher , Christer Holmberg Thread-Topic: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing Thread-Index: Ac8iY/biToYKPFP2T8+rOyj46vmc1wAZ5qCAAAaa3/A= Date: Wed, 5 Feb 2014 20:40:31 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@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: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Feb 2014 20:40:39 -0000 PiBUaGUgUFBJRCBpc24ndCBleHBvc2VkIHRvIHRoZSBhcHBsaWNhdGlvbi4gIEl0J3MganVzdCB1 c2VkIHRvDQo+IGRpc3Rpbmd1aXNoIHRleHQvYmluYXJ5L2NvbnRyb2wuICAgIElmIGFuIGFwcGxp Y2F0aW9uIHVzZXMgZGlmZmVyZW50DQo+IGRhdGEgY2hhbm5lbHMgd2l0aCBkaWZmZXJlbnQgcHJv dG9jb2xzLCBpdCBzaG91bGQgdXNlIHRoZSBTSUQgdG8NCj4gZGlzdGluZ3Vpc2ggYmV0d2VlbiB0 aGVtLCBub3QgdGhlIFBQSUQuICBJbiBmYWN0LCBldmVuIGlmIGl0IHdhbnRlZCB0bw0KPiB1c2Ug dGhlIFBQSUQsIGl0IHdvdWxkbid0IGJlIGFibGUgdG8uDQpbUmFqdV0gUFBJRCBpcyBhbHNvIHVz ZWQgYnkgYnJvd3NlcnMgKGFuZCBvdGhlciB3ZWJydGMgaW1wbGVtZW50b3JzIGxpa2UgbmF0aXZl IGNsaWVudHMpIHRvIGZyYWdtZW50IHVzZXIgZ2l2ZW4gbGFyZ2UgZGF0YSBpbnRvIHNtYWxsZXIg ZnJhZ21lbnRzICh2aWEgIlhZWiBwYXJ0aWFsIiwgIlhZWiBsYXN0IiBQUElEcykgdG8gYXZvaWQg bW9ub3BvbGl6aW5nIHRoZSBTQ1RQIGxpbmsgZm9yIGEgc2luZ2xlIGRhdGEgY2hhbm5lbCdzIGRh dGEuDQpTZWUgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItZGF0 YS1jaGFubmVsLTA2I3NlY3Rpb24tNi42IGZvciBtb3JlIGRldGFpbHMuDQoNCi1SYWp1DQoNCg== From pthatcher@google.com Wed Feb 5 13:10: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 777981A020A for ; Wed, 5 Feb 2014 13:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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.535, 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 99Xp9ybgNxr5 for ; Wed, 5 Feb 2014 13:10:20 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B72191A01FC for ; Wed, 5 Feb 2014 13:10:20 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kp14so837267pab.20 for ; Wed, 05 Feb 2014 13:10:20 -0800 (PST) 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=Q0rK9CBTYt5VYFXbk1eN9LUnva+Qpxwc8UrRZOCdxOs=; b=lp0Br0KyMLZD06tmRVNBfF0SzFODGLdrBuATpb4Cgsk/oXMVYnvIoYzD45j03ydbwN wFSyotANIUiSdW1NH3r649gu8EPz4kUO5JXpnmxB1brPYHaQXghxBRmGKCfhIf9YbNib GWUXA4H8UC7y3KApjIVtCMM4SXrHi6Ltms8W+P/HV24JNFeq180TCr+7gPQu+xxTVEoG Uglt11wB7Q0beGbSr0ZyssLSvXxN3Cd76a9YNr+kAqdsvwIxxF5GGNqh098NC7fc7weB sjLNg3566zht8WtY4APVPkElRWr5BzlvpIi9dnpO2YaeQsx6zglVECak8hh6+bcv9goy +wFQ== 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=Q0rK9CBTYt5VYFXbk1eN9LUnva+Qpxwc8UrRZOCdxOs=; b=jJd3xxsEtNW7QWYzehQKwHuh2v1hsFJJwr+KslfdHfdOMqVWoBmK/rjzVm9ll8Fv0B XmVofmMEDkkqjZKKePH/p9/qbENbYHn1R0nMUO7z63HGlcCzUn6LRr6QI12WvaSTi1H2 Re0FLWoeHr436jdRmRnjXo70865dDf5UnAV+GfSlpb8kez9d3NRnoNSlPh2s1BxMrfS/ QijogIjB3YTO+qVHLdrMLj7YAWPlQBMRgbjo8SKa87LQw83SaWbjNDZuf5mCsbhZpG9w whn+rfbKovyrhZIh98Pb90/4TP8N4A1T0aL7KSDRW7SYM+W35Ekjidf8+i5sbVu3vLxJ uyXQ== X-Gm-Message-State: ALoCoQnCzIxpGLpXIlnnNMn8sMcWzeC1GgCoP6CpcpYP+qq6KUEPDrCUQcuZhzh1eORbKjm8joGi6g01luI292viUSlFf3jPih4fQZvywIN3j9pNq72AcmmJAeLF5inCsvUm8G0MIhC7wYm+WQ/+7qof35Pi5Cq3xevMjjF3OkG4XZeK8PMcWu3dTgwqMVYup9wNyf2TshR3 X-Received: by 10.69.20.139 with SMTP id hc11mr5380167pbd.63.1391634619605; Wed, 05 Feb 2014 13:10:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.163.234 with HTTP; Wed, 5 Feb 2014 13:09:39 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Wed, 5 Feb 2014 13:09:39 -0800 Message-ID: To: "Makaraju, Maridi Raju (Raju)" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Feb 2014 21:10:24 -0000 On Wed, Feb 5, 2014 at 12:40 PM, Makaraju, Maridi Raju (Raju) wrote: >> The PPID isn't exposed to the application. It's just used to >> distinguish text/binary/control. If an application uses different >> data channels with different protocols, it should use the SID to >> distinguish between them, not the PPID. In fact, even if it wanted to >> use the PPID, it wouldn't be able to. > [Raju] PPID is also used by browsers (and other webrtc implementors like native clients) to fragment user given large data into smaller fragments (via "XYZ partial", "XYZ last" PPIDs) to avoid monopolizing the SCTP link for a single data channel's data. > See http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06#section-6.6 for more details. I believe that Firefox is the browser that does that. At the last IETF, I think we agreed that it's a temporary fix at best while we wait until this problem is solved at the SCTP layer and not above it. I'm not aware of any native clients that use this technique, unless there are native clients that use Firefox's code. Perhaps there are; I just don't know of any. In any case, it's not part of the standard, and I think the plan is that it won't be needed long-term. > > -Raju > From Michael.Tuexen@lurchi.franken.de Wed Feb 5 13:11: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 A897D1A01FC for ; Wed, 5 Feb 2014 13:11:55 -0800 (PST) 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, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535, 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 RT173EYNwtyY for ; Wed, 5 Feb 2014 13:11:53 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id DA72F1A01CC for ; Wed, 5 Feb 2014 13:11:52 -0800 (PST) Received: from [192.168.1.200] (p508F1F22.dip0.t-ipconnect.de [80.143.31.34]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7C68D1C0B3006; Wed, 5 Feb 2014 22:11:49 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Wed, 5 Feb 2014 22:11:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> To: Peter Thatcher X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Feb 2014 21:11:55 -0000 On Feb 5, 2014, at 10:09 PM, Peter Thatcher = wrote: > On Wed, Feb 5, 2014 at 12:40 PM, Makaraju, Maridi Raju (Raju) > wrote: >>> The PPID isn't exposed to the application. It's just used to >>> distinguish text/binary/control. If an application uses different >>> data channels with different protocols, it should use the SID to >>> distinguish between them, not the PPID. In fact, even if it wanted = to >>> use the PPID, it wouldn't be able to. >> [Raju] PPID is also used by browsers (and other webrtc implementors = like native clients) to fragment user given large data into smaller = fragments (via "XYZ partial", "XYZ last" PPIDs) to avoid monopolizing = the SCTP link for a single data channel's data. >> See = http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06#section-6.6 = for more details. >=20 > I believe that Firefox is the browser that does that. At the last > IETF, I think we agreed that it's a temporary fix at best while we > wait until this problem is solved at the SCTP layer and not above it. >=20 > I'm not aware of any native clients that use this technique, unless > there are native clients that use Firefox's code. Perhaps there are; > I just don't know of any. >=20 > In any case, it's not part of the standard, and I think the plan is > that it won't be needed long-term. As discussed in the last IETF meeting, this PPID based fragmentation and = reassembly will be removed from the ID. Best regards Michael >=20 >>=20 >> -Raju >>=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From Raju.Makaraju@alcatel-lucent.com Wed Feb 5 13:32: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 428301A0223 for ; Wed, 5 Feb 2014 13:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 T8MUT-LROAbr for ; Wed, 5 Feb 2014 13:32:50 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3641A0211 for ; Wed, 5 Feb 2014 13:32:50 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s15LWlPv023074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 15:32:48 -0600 (CST) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s15LWk36005902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 16:32:47 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 5 Feb 2014 16:32:46 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Michael Tuexen , Peter Thatcher Thread-Topic: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing Thread-Index: AQHPIrbvBV3Y4lbqJU6LVDbjTFGdqpqnLPhQ Date: Wed, 5 Feb 2014 21:32:46 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@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: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Feb 2014 21:32:52 -0000 > > I believe that Firefox is the browser that does that. At the last > > IETF, I think we agreed that it's a temporary fix at best while we > > wait until this problem is solved at the SCTP layer and not above it. [Raju] Using NDATA I believe. > > > > I'm not aware of any native clients that use this technique, unless > > there are native clients that use Firefox's code. Perhaps there are; > > I just don't know of any. > > > > In any case, it's not part of the standard, and I think the plan is > > that it won't be needed long-term. > As discussed in the last IETF meeting, this PPID based fragmentation and > reassembly > will be removed from the ID. [Raju] Can I then assume the reason for such removal is the availability of= NDATA (http://tools.ietf.org/html/draft-stewart-tsvwg-sctp-ndata-03) soone= r than later, which will make such PPID based fragmentation/reassembly imme= diately obsolete? [Raju] -Raju From Michael.Tuexen@lurchi.franken.de Wed Feb 5 13: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 7936B1A011C for ; Wed, 5 Feb 2014 13:47:42 -0800 (PST) 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, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535, 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 0K3wtZcgjyRn for ; Wed, 5 Feb 2014 13:47:40 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id F1F511A0101 for ; Wed, 5 Feb 2014 13:47:39 -0800 (PST) Received: from [192.168.1.200] (p508F1F22.dip0.t-ipconnect.de [80.143.31.34]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D0D981C0B4043; Wed, 5 Feb 2014 22:47:37 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Wed, 5 Feb 2014 22:47:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> To: "Makaraju, Maridi Raju (Raju)" X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Feb 2014 21:47:42 -0000 On Feb 5, 2014, at 10:32 PM, "Makaraju, Maridi Raju (Raju)" = wrote: >>> I believe that Firefox is the browser that does that. At the last >>> IETF, I think we agreed that it's a temporary fix at best while we >>> wait until this problem is solved at the SCTP layer and not above = it. > [Raju] Using NDATA I believe. >=20 >>>=20 >>> I'm not aware of any native clients that use this technique, unless >>> there are native clients that use Firefox's code. Perhaps there = are; >>> I just don't know of any. >>>=20 >>> In any case, it's not part of the standard, and I think the plan is >>> that it won't be needed long-term. >> As discussed in the last IETF meeting, this PPID based fragmentation = and >> reassembly >> will be removed from the ID. > [Raju] Can I then assume the reason for such removal is the = availability of NDATA = (http://tools.ietf.org/html/draft-stewart-tsvwg-sctp-ndata-03) sooner = than later, which will make such PPID based fragmentation/reassembly = immediately obsolete? Right. The point was not to have two solutions, but use one. Best regards Michael >=20 > [Raju] -Raju >=20 From pkyzivat@alum.mit.edu Wed Feb 5 13:59: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 97A9B1A0129 for ; Wed, 5 Feb 2014 13:59:53 -0800 (PST) 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 orMNuz6qZ3uo for ; Wed, 5 Feb 2014 13:59:52 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 865701A012F for ; Wed, 5 Feb 2014 13:59:52 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta13.westchester.pa.mail.comcast.net with comcast id Nd1k1n0021YDfWL5Dlzrri; Wed, 05 Feb 2014 21:59:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id Nlzr1n00P3ZTu2S3glzr2z; Wed, 05 Feb 2014 21:59:51 +0000 Message-ID: <52F2B457.8040305@alum.mit.edu> Date: Wed, 05 Feb 2014 16:59:51 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391637591; bh=0ZGQ3q779J3FC4yWUCztWpQj7SLnbv9s2oT/BSXB3Kk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iN87rV5Sq6WF/RTj8xqZobqRzCrDGp1hAL4HfiFtBkjTx+cjEtwXObP7oNGXV/wej HcU0HCFco6bMLk6tZbm2YZtq5bB31l+hbTVK5f2lsGQbY+laQZE5DsXWEMIxG+9gMb VlvZBZY6b7KQHHPdWq75WsiG3VIrkBjeWnIyhOTuILMZ1antZHxHRxiD5VKUstpT/e WcEGYO1gyxDE5BXF6L90S7HY1IlvdFAsNO6PCOGUrnNMEDutC6lBbt7rXoONb/VwkO kFi3tTj20Ke9IMa5qh7YODCkvPY48pVl1JgCTmU161Spmrn84Utp7wrhaSIyihvTk0 aTxNOZ3Ohp10A== Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Feb 2014 21:59:53 -0000 Will NDATA support be required for rtcweb? Thanks, Paul On 2/5/14 4:47 PM, Michael Tuexen wrote: > On Feb 5, 2014, at 10:32 PM, "Makaraju, Maridi Raju (Raju)" wrote: > >>>> I believe that Firefox is the browser that does that. At the last >>>> IETF, I think we agreed that it's a temporary fix at best while we >>>> wait until this problem is solved at the SCTP layer and not above it. >> [Raju] Using NDATA I believe. >> >>>> >>>> I'm not aware of any native clients that use this technique, unless >>>> there are native clients that use Firefox's code. Perhaps there are; >>>> I just don't know of any. >>>> >>>> In any case, it's not part of the standard, and I think the plan is >>>> that it won't be needed long-term. >>> As discussed in the last IETF meeting, this PPID based fragmentation and >>> reassembly >>> will be removed from the ID. >> [Raju] Can I then assume the reason for such removal is the availability of NDATA (http://tools.ietf.org/html/draft-stewart-tsvwg-sctp-ndata-03) sooner than later, which will make such PPID based fragmentation/reassembly immediately obsolete? > Right. The point was not to have two solutions, but use one. > > Best regards > Michael >> >> [Raju] -Raju >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From Raju.Makaraju@alcatel-lucent.com Wed Feb 5 14:34: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 159C71A0266 for ; Wed, 5 Feb 2014 14:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 J571l-kefUbr for ; Wed, 5 Feb 2014 14:34:23 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7741A021F for ; Wed, 5 Feb 2014 14:34:23 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s15MYKH0017205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 16:34:21 -0600 (CST) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s15MYKx3014250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 17:34:20 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 5 Feb 2014 17:34:19 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Michael Tuexen Thread-Topic: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing Thread-Index: AQHPIrbvBV3Y4lbqJU6LVDbjTFGdqpqnLPhQgABZLwD//7hz0A== Date: Wed, 5 Feb 2014 22:34:20 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@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: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Feb 2014 22:34:25 -0000 > > [Raju] Can I then assume the reason for such removal is the availabilit= y > of NDATA (http://tools.ietf.org/html/draft-stewart-tsvwg-sctp-ndata-03) > sooner than later, which will make such PPID based fragmentation/reassemb= ly > immediately obsolete? > Right. The point was not to have two solutions, but use one. [Raju] That makes perfect sense and NDATA is a better solution too! That al= so pushes browser vendors to support NDATA sooner than later. -Raju From Raju.Makaraju@alcatel-lucent.com Wed Feb 5 14:36: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 23C281A022C for ; Wed, 5 Feb 2014 14:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 zGvb6R5G0RNX for ; Wed, 5 Feb 2014 14:35:58 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6081A021F for ; Wed, 5 Feb 2014 14:35:58 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s15MZunm019787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 16:35:56 -0600 (CST) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s15MZrHh000756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 17:35:56 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 5 Feb 2014 17:35:55 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing Thread-Index: AQHPIr2cinUlybUJZU6ymrGYmSg4S5qnPxmA Date: Wed, 5 Feb 2014 22:35:54 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> <52F2B457.8040305@alum.mit.edu> In-Reply-To: <52F2B457.8040305@alum.mit.edu> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Feb 2014 22:36:00 -0000 > Will NDATA support be required for rtcweb? [Raju] Yes. It is mentioned in http://tools.ietf.org/html/draft-ietf-rtcweb= -data-channel-06#page-3 which says the following: The SCTP base protocol specified in [RFC4960] does not support the interleaving of user messages. Therefore sending a large user message can monopolize the SCTP association. To overcome this limitation, [I-D.stewart-tsvwg-sctp-ndata] defines an extension to support message interleaving. Once such an extension is available,=20 it SHOULD be used. From pkyzivat@alum.mit.edu Wed Feb 5 14:45: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 CE1C71A026A for ; Wed, 5 Feb 2014 14:45:34 -0800 (PST) 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 t0UUkdZLVJ19 for ; Wed, 5 Feb 2014 14:45:33 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id A5C801A021F for ; Wed, 5 Feb 2014 14:45:33 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta10.westchester.pa.mail.comcast.net with comcast id Neg91n00716LCl05AmlY2i; Wed, 05 Feb 2014 22:45:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id NmlY1n00z3ZTu2S3SmlY8n; Wed, 05 Feb 2014 22:45:32 +0000 Message-ID: <52F2BF0C.5060507@alum.mit.edu> Date: Wed, 05 Feb 2014 17:45:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52F11057.8040708@alum.mit.edu> In-Reply-To: <52F11057.8040708@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391640332; bh=T0w/n7tIPFxZd+rL37hFeMJRxJJKa+oalzTvleiTfHQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PV+G1hn4ebaTv4B3sSg44JrNtLnqYZJyWoTWw4//0YndZIDqQD7aRhQZSJHuw3zgE rNjC3WGmhfydHFn3xnG+GP7RyjweZlPluC10+nnKWziRzOov6OMBlzi76SN8i/B9Eu pA9P1z6LymWmIh75HDN1Iv90YrLh+FUBG6JJ8Qr9AbTEeo2X1F9JALQZW1Lu2eyEXU fPm3eAN0aQlZW022vhBZypA59+AHd2mdPx9DT8l2F/jXR7Qrjl+rwu80di5uYMeWnv rTcW1UcV7VwECYicm4SaKf1/zGclzGkfiE4/SZuUDYf0a4u/qrVUsVXw3TquDHnYAI DtRzCLbaTsaNA== Subject: Re: [rtcweb] Data Channel question: correlating streams with channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Feb 2014 22:45:34 -0000 Sorry. I finally found the normative statement I was wanting: If a DATA_CHANNEL_OPEN message is received on an unused stream, the stream identifier corresponds to the role of the peer and all parameters in the DATA_CHANNEL_OPEN message are valid, then a corresponding DATA_CHANNEL_ACK message is sent on the stream with the same stream identifier as the one the DATA_CHANNEL_OPEN message was received on. This satisfies my concern. Thanks, Paul On 2/4/14 11:07 AM, Paul Kyzivat wrote: > Section 6.4 of draft-ietf-rtcweb-data-channel-06 says: > > The realization of a bidirectional Data Channel is a pair of one > incoming stream and one outgoing SCTP stream. > > Note that there's no requirement for the SCTP streams used to create > a bidirectional channel have the same number in each direction. How > stream values are selected is protocol and implementation dependent. > > The note seems to be something of a cop-out. But I'll accept for the > moment that this can be true when external negotiation is used to define > the channels. > > But I've looked through draft-ietf-rtcweb-data-protocol-01, and I don't > find any specification there of how the pairing is done. > > Section 4 of the protocol draft says: > > The data channel protocol uses a two way handshake to open a data > channel. The side wanting to open a data channel selects an unused > Stream and sends a DATA_CHANNEL_OPEN message. The peer responds with > a DATA_CHANNEL_ACK message. Then the data channel is open. > > The side doing the OPEN chooses what will be its outgoing stream id. > That then becomes the incoming stream id of the peer. I had always > assumed that the same stream id would be used for the ACK. But I find no > evidence to support that assumption. For it to be anything else I would > think the ACK would need to carry more information to correlate back to > the OPEN message. > > Thanks, > Paul > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From pkyzivat@alum.mit.edu Wed Feb 5 15:03: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 C97D91A016B for ; Wed, 5 Feb 2014 15:03:37 -0800 (PST) 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 J-JOWpGru_VD for ; Wed, 5 Feb 2014 15:03:36 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE581A026A for ; Wed, 5 Feb 2014 15:03:36 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta07.westchester.pa.mail.comcast.net with comcast id NmPg1n0020QuhwU57n3bTo; Wed, 05 Feb 2014 23:03:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id Nn3b1n00D3ZTu2S3Nn3byY; Wed, 05 Feb 2014 23:03:35 +0000 Message-ID: <52F2C347.7000304@alum.mit.edu> Date: Wed, 05 Feb 2014 18:03:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , "rtcweb@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> <52F2B457.8040305@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391641415; bh=XkBTiwyVslWdEMRxFNQ7z05cBWfMwIOvKjJOP0tol0I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HKjOrP9hRAkH2j59jNgGnLRgEcrYlD3YD2v69LSu1gNLQJjwC19/awD847oG6J7uH ZcScellw/WYQe8NBkKx5glDs2YZBA+8myY+KoWrUhiMaaQ96jNEHx1yzCVzgDXHa9P 0j5IotQNrQON9onNOJbITgsJFBl+Cegmjzhgfz3ztpiUO85M4bcHhlunEhE6eVWVVY 4e7HOU1EINHtcqcwSTNgS5xtqW4NrLFLgXOeAGQfFTiHDKOf1O4yVdneG29cfc8N2N cp1Gc5J+XW130TlRH/24uox8VCKAcHNhRYHIQPaMocIR54mU1kcnA+s9490xqIGEL4 fdCWpHjPKO3QQ== Subject: Re: [rtcweb] RTCWEB Data Channel: message 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, 05 Feb 2014 23:03:38 -0000 On 2/5/14 5:35 PM, Makaraju, Maridi Raju (Raju) wrote: >> Will NDATA support be required for rtcweb? > [Raju] Yes. It is mentioned in http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06#page-3 which says the following: > > The SCTP base protocol specified in [RFC4960] does not support the > interleaving of user messages. Therefore sending a large user > message can monopolize the SCTP association. To overcome this > limitation, [I-D.stewart-tsvwg-sctp-ndata] defines an extension to > support message interleaving. Once such an extension is available, > it SHOULD be used. > I guess that begs the question of what "Once such an extension is available" means, and what "it SHOULD be used" means. :-( "available" could mean: - once it is defined in a published RFC - once it is defined in a WG draft or RFC - once it is defined in an individual draft (e.g., draft-stewart-tsvwg-sctp-ndata-03) - once it it is implemented in the browser you are using "SHOULD be used" could apply to: - browser implementers - application implementers And then there is the question of what "SHOULD" means. Specifically, what are the conditions where it would be acceptable to *not* follow this? I *hope* this is intended to mean that browser implementers MUST *implement* it, and *use* it in their implementation of DataChannel once draft-stewart-tsvwg-sctp-ndata becomes an RFC. And SHOULD do so now based on draft-stewart-tsvwg-sctp-ndata-03. Thanks, Paul From Raju.Makaraju@alcatel-lucent.com Wed Feb 5 15:33: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 D95E81A0141 for ; Wed, 5 Feb 2014 15:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 G9asBCCzfFGN for ; Wed, 5 Feb 2014 15:33:16 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CBB241A021A for ; Wed, 5 Feb 2014 15:33:15 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s15NXDOg008184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 17:33:14 -0600 (CST) 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 s15NXDtW031927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 18:33:13 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 5 Feb 2014 18:33:12 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] RTCWEB Data Channel: message interleaving Thread-Index: AQHPIsaGtTtVxkBpl0uo4mWaQvx+DpqnSFaw Date: Wed, 5 Feb 2014 23:33:12 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> <52F2B457.8040305@alum.mit.edu> <52F2C347.7000304@alum.mit.edu> In-Reply-To: <52F2C347.7000304@alum.mit.edu> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [rtcweb] RTCWEB Data Channel: message 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, 05 Feb 2014 23:33:19 -0000 > "available" could mean: >=20 > - once it is defined in a published RFC > - once it is defined in a WG draft or RFC > - once it is defined in an individual draft > (e.g., draft-stewart-tsvwg-sctp-ndata-03) [Raju] I believe this is the case. > - once it it is implemented in the browser you are using [Raju] Browser implementations probably be more proactive in adapting this = draft similar to number of other drafts that are being adapted in individua= l draft state. I think this is one way browsers can differentiate themselves from others. So, in my opinion, the "SHOULD" below probably ok and does not have to be a= "MUST" as this NDATA is not a MUST have to deliver data channel requiremen= ts. If it has to be a "MUST" then I believe it has to be part of the requir= ement section 4 of http://tools.ietf.org/html/draft-ietf-rtcweb-data-channe= l-06#section-4 and list it as "MUST". >=20 > "SHOULD be used" could apply to: > - browser implementers > - application implementers >=20 > And then there is the question of what "SHOULD" means. Specifically, > what are the conditions where it would be acceptable to *not* follow this= ? >=20 > I *hope* this is intended to mean that browser implementers MUST > *implement* it, and *use* it in their implementation of DataChannel once > draft-stewart-tsvwg-sctp-ndata becomes an RFC. And SHOULD do so now > based on draft-stewart-tsvwg-sctp-ndata-03. [Raju] I am not sure if this NDATA is a deal breaker for webrtc 1.0?! Some = implementations may support while others not as NDATA is negotiated during = association setup; if one end does not support then it is disabled. If you don't have NDATA then one data channel stream may monopolize the SCT= P link and could affect scenarios like: - You sent 1GB file using data channel stream 0 (all at once without using = something like MSRP). - Then immediately, you send a small "Hi, some important stuff!" chat messa= ge using data channel stream 1. Without NDATA, the other end will receive the text msg ONLY AFTER receiving= the 1GB file!! With NDATA chat msg gets equal share of the SCTP link and g= ets delivered much sooner. You can apply this to even more sensitive gaming apps. -Raju From christer.holmberg@ericsson.com Wed Feb 5 23:56: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 9F5361A0090 for ; Wed, 5 Feb 2014 23:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 QQ6YJa3Z05rv for ; Wed, 5 Feb 2014 23:56:53 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 564CD1A0083 for ; Wed, 5 Feb 2014 23:56:53 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-ec-52f34043899f Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 27.57.23809.34043F25; Thu, 6 Feb 2014 08:56:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 08:56:51 +0100 From: Christer Holmberg To: Michael Tuexen , Peter Thatcher Thread-Topic: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing Thread-Index: Ac8jEP4UAFTLik6/TaCDQ1g2OxFaDA== Date: Thu, 6 Feb 2014 07:56:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15E955@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvja6zw+cgg0Wd5hYXm5YwWlxb/prV Yu2/dnYHZo8Fm0o9liz5yeSxoWUHUwBzFJdNSmpOZllqkb5dAlfGl+e3WAueMlacaG1kamDc yNjFyMkhIWAi0Xz7GhuELSZx4d56IJuLQ0jgEKPEzF//WSCcRYwSM/atAMpwcLAJWEh0/9MG aRARiJN48Psr2CBmAXWJO4vPsYPYwgIhEtP2nmGEqAmVWHptAjOErSfRvOYSC4jNIqAisXf+ bbDFvAK+Eut29oLVMAId8f3UGiaImeISt57MZ4I4TkBiyZ7zzBC2qMTLx/9YIWxFifanDVA3 6Egs2P2JDcLWlli28DUzxHxBiZMzn7BMYBSZhWTsLCQts5C0zELSsoCRZRUje25iZk56udEm RmAUHNzyW3UH451zIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAqO+Q 65dy4oaqjl/8F3OB0tAyZYlpW7WX9YRyZJiFSZ4/6GqRNCOR+ei1zPBpE0UtDM2bn8jcnv2t xLV7Rva9wsnrFQ4rpkivPFEsqySwY4fVK770P885LKM4v7wsWNMicH3GKYEvZi+e/2aWLvZc vNDmn+nfmZMTj9QEqb71iFR9FiTRrJCqxFKckWioxVxUnAgAHdKdE1ACAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 07:56:54 -0000 Hi, > As discussed in the last IETF meeting, this PPID based fragmentation and = reassembly will be removed from the ID. I assume the associated PPID values will also be un-registered with IANA? Regards, Christer From Michael.Tuexen@lurchi.franken.de Thu Feb 6 00:08: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 8273C1A0091 for ; Thu, 6 Feb 2014 00:08:42 -0800 (PST) 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, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535, 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 CtA5raihvyY8 for ; Thu, 6 Feb 2014 00:08:39 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBEE1A0090 for ; Thu, 6 Feb 2014 00:08:39 -0800 (PST) Received: from [192.168.1.200] (p508F1F22.dip0.t-ipconnect.de [80.143.31.34]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0591F1C0E979C; Thu, 6 Feb 2014 09:08:36 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Thu, 6 Feb 2014 09:08:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> <52F2B457.8040305@alum.mit.edu> <52F2C347.7000304@alum.mit.edu> To: "Makaraju, Maridi Raju (Raju)" X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: message 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, 06 Feb 2014 08:08:42 -0000 On Feb 6, 2014, at 12:33 AM, "Makaraju, Maridi Raju (Raju)" = wrote: >> "available" could mean: >>=20 >> - once it is defined in a published RFC >> - once it is defined in a WG draft or RFC >> - once it is defined in an individual draft >> (e.g., draft-stewart-tsvwg-sctp-ndata-03) > [Raju] I believe this is the case. draft-stewart-tsvwg-sctp-ndata has been adopted as a WG item in the = TSVWG. We need to update and resubmit it. >> - once it it is implemented in the browser you are using > [Raju] Browser implementations probably be more proactive in adapting = this draft similar to number of other drafts that are being adapted in = individual draft state. > I think this is one way browsers can differentiate themselves from = others. > So, in my opinion, the "SHOULD" below probably ok and does not have to = be a "MUST" as this NDATA is not a MUST have to deliver data channel = requirements. If it has to be a "MUST" then I believe it has to be part = of the requirement section 4 of = http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06#section-4 = and list it as "MUST". >=20 >>=20 >> "SHOULD be used" could apply to: >> - browser implementers >> - application implementers >>=20 >> And then there is the question of what "SHOULD" means. Specifically, >> what are the conditions where it would be acceptable to *not* follow = this? >>=20 >> I *hope* this is intended to mean that browser implementers MUST >> *implement* it, and *use* it in their implementation of DataChannel = once >> draft-stewart-tsvwg-sctp-ndata becomes an RFC. And SHOULD do so now >> based on draft-stewart-tsvwg-sctp-ndata-03. > [Raju] I am not sure if this NDATA is a deal breaker for webrtc 1.0?! = Some implementations may support while others not as NDATA is negotiated = during association setup; if one end does not support then it is = disabled. >=20 > If you don't have NDATA then one data channel stream may monopolize = the SCTP link and could affect scenarios like: > - You sent 1GB file using data channel stream 0 (all at once without = using something like MSRP). > - Then immediately, you send a small "Hi, some important stuff!" chat = message using data channel stream 1. > Without NDATA, the other end will receive the text msg ONLY AFTER = receiving the 1GB file!! With NDATA chat msg gets equal share of the = SCTP link and gets delivered much sooner. If NDATA is not supported, the message size is limited to avoid the = monopolization. This limit will be signalled through SDP. Best regards Michael > You can apply this to even more sensitive gaming apps. >=20 > -Raju >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From Michael.Tuexen@lurchi.franken.de Thu Feb 6 00:25: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 7339B1A006A for ; Thu, 6 Feb 2014 00:25:41 -0800 (PST) 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, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535, 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 rg0qUzPUumSY for ; Thu, 6 Feb 2014 00:25:39 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7A51A0092 for ; Thu, 6 Feb 2014 00:25:39 -0800 (PST) Received: from [192.168.1.200] (p508F1F22.dip0.t-ipconnect.de [80.143.31.34]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 937D71C0B4600; Thu, 6 Feb 2014 09:25:37 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> Date: Thu, 6 Feb 2014 09:25:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 08:25:41 -0000 On Feb 6, 2014, at 8:56 AM, Christer Holmberg = wrote: > Hi, >=20 >> As discussed in the last IETF meeting, this PPID based fragmentation = and reassembly will be removed from the ID. >=20 > I assume the associated PPID values will also be un-registered with = IANA? I guess they will stay... They are supported by Firefox and PPIDs are a = pretty cheap resource. They are from a pool of 32-bit entities. That is why we registered the values before the RFCs get published. Best regards Michael >=20 > Regards, >=20 > Christer >=20 >=20 From christer.holmberg@ericsson.com Thu Feb 6 00:36: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 7F3FF1A0090 for ; Thu, 6 Feb 2014 00:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 55x9ICz9jbI4 for ; Thu, 6 Feb 2014 00:36:04 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8651A006A for ; Thu, 6 Feb 2014 00:36:03 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-6e-52f34972016c Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 31.F0.04853.27943F25; Thu, 6 Feb 2014 09:36:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 09:36:01 +0100 From: Christer Holmberg To: Michael Tuexen Thread-Topic: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing Thread-Index: Ac8jEP4UAFTLik6/TaCDQ1g2OxFaDP//90SA///s4PA= Date: Thu, 6 Feb 2014 08:36:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> In-Reply-To: <74072016-DA11-41E8-9944-779428163EE4@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.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+JvjW6R5+cgg9VfxC0uNi1htLi2/DWr xdp/7ewOzB4LNpV6LFnyk8ljQ8sOpgDmKC6blNSczLLUIn27BK6MbY8PsRbMZK34032fvYGx naWLkZNDQsBEou3cNnYIW0ziwr31bF2MXBxCAicYJZpmHWWCcBYxSjQ+u8DcxcjBwSZgIdH9 TxukQUTAVOLg8nlgg5gF/CSa1+0Bs4UFQiSm7T3DCFETKrH02gRmCNtKomvLKlaQMSwCKhKz f+uBhHkFfCV6f6yHWtXBKHHudA9YL6eAq8TmmV/ZQGxGoOO+n1rDBLFLXOLWk/lMEEcLSCzZ c54ZwhaVePn4HyuErShxdfpyqHodiQW7P7FB2NoSyxa+ZoZYLChxcuYTlgmMYrOQjJ2FpGUW kpZZSFoWMLKsYpQsTi0uzk03MtDLTc8t0UstykwuLs7P0ytO3cQIjKyDW34b7WA8ucf+EKM0 B4uSOO911pogIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYw7k1TPLd282P3dplM3go6mPc1x l2DvWlGdmiV2a/OjXZaFDzbdev7qrETODxm2zG/XHuZYbk2q5g55xG++2Hzi5r3MAYflPBPP r6+vO/Hv3MFdd3YZKP6pXXn7fZkP47MjFw3+SuxoWP9pi/qpb7cLDzK+WfZCRruKb2Uuw5+D O2cePBvV90BouRJLcUaioRZzUXEiAHJwsGl6AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 08:36:05 -0000 Hi, >>> As discussed in the last IETF meeting, this PPID based fragmentation an= d reassembly will be removed from the ID. >>=20 >> I assume the associated PPID values will also be un-registered with IANA= ? > I guess they will stay... They are supported by Firefox and PPIDs are a p= retty cheap resource. They are from a pool of 32-bit entities. That is why = we registered the values before the RFCs get published. So, does that mean my WebRTC entity has to support them, in case the remote= peer is on Firefox? Also, if they are removed from the data channel draft, what reference will = be used in the IANA table? Regards, Christer From christer.holmberg@ericsson.com Thu Feb 6 00:38: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 CB2711A01E5 for ; Thu, 6 Feb 2014 00:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 X5I5ei6Q6C2K for ; Thu, 6 Feb 2014 00:38:48 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 309A61A0090 for ; Thu, 6 Feb 2014 00:38:47 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-04-52f34a162ff6 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FE.C6.10875.61A43F25; Thu, 6 Feb 2014 09:38:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 09:38:46 +0100 From: Christer Holmberg To: Michael Tuexen , "Makaraju, Maridi Raju (Raju)" Thread-Topic: [rtcweb] RTCWEB Data Channel: message interleaving Thread-Index: AQHPIsaEX8XM84JpVU6ADbU8RAEiNZqnPvQAgACQAACAABjvAA== Date: Thu, 6 Feb 2014 08:38:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15EDA7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> <52F2B457.8040305@alum.mit.edu> <52F2C347.7000304@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvja6Y1+cgg0u31C0uNi1htGjYeIXV Yu2/dnYHZo/WZ3tZPZYs+cnksaFlB1MAcxSXTUpqTmZZapG+XQJXxrW9DxkLDjBV3O5pY2lg /M7YxcjJISFgInHq3Cl2CFtM4sK99WxdjFwcQgKHGCU2zW1ngXAWMUrsffeRtYuRg4NNwEKi +582iCkiUCXR2qQO0sssoC5xZ/E5dpCwsIC9xJs3oiBhEQEHie+H7jJC2E4Srzvus4LYLAIq Eh9nrgdbyyvgK/Fz6W92iE1z2CS+/lzHDJLgFHCV+Pb5HVgzI9Bt30+tYYLYJS5x68l8Joib BSSW7DnPDGGLSrx8/I8VwlaUuDp9OVS9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERrFZSMbO QtIyC0nLLCQtCxhZVjGy5yZm5qSXG25iBEbNwS2/dXcwnjoncohRmoNFSZz3w1vnICGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2MasrSe0/ctvTcckg/ZF2r7IvmHf079SVtdm48m7NMa7G4 UqjsOc+rTL3bp5dO/CjGfeeue8z8nsDjIX8WzP+t+P5yo4Op6aOd006sk3z5j39uopbBkoMf /M3Dbc7wbjzFXrr5x6W3R4z5Lu5fdFR9Yd2+mau07m300NiRK7DFrdBnt6zLb7e7ekosxRmJ hlrMRcWJADlcCidoAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: message 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, 06 Feb 2014 08:38:50 -0000 Hi, > If NDATA is not supported, the message size is limited to avoid the monop= olization. This limit will be signalled through SDP. What do you mean by "signaled through SDP"? Will the browser inform the JS app, using SDP, if the local and/or remote p= eer doesn't support NDATA? Regards, Christer From Michael.Tuexen@lurchi.franken.de Thu Feb 6 00:45: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 C3B651A01FB for ; Thu, 6 Feb 2014 00:45:55 -0800 (PST) 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, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535, 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 2YMebvmWjmcT for ; Thu, 6 Feb 2014 00:45:54 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFE01A0090 for ; Thu, 6 Feb 2014 00:45:54 -0800 (PST) Received: from [192.168.1.200] (p508F1F22.dip0.t-ipconnect.de [80.143.31.34]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4DC931C0E97A5; Thu, 6 Feb 2014 09:45:52 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> Date: Thu, 6 Feb 2014 09:45:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4CE22DF8-DE34-400A-95AE-2E011828DE88@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 08:45:56 -0000 On Feb 6, 2014, at 9:36 AM, Christer Holmberg = wrote: > Hi, >=20 >>>> As discussed in the last IETF meeting, this PPID based = fragmentation and reassembly will be removed from the ID. >>>=20 >>> I assume the associated PPID values will also be un-registered with = IANA? >> I guess they will stay... They are supported by Firefox and PPIDs are = a pretty cheap resource. They are from a pool of 32-bit entities. That = is why we registered the values before the RFCs get published. >=20 > So, does that mean my WebRTC entity has to support them, in case the = remote peer is on Firefox? I don't think so. Not sure what the plan for Firefox is, but I expect = Firefox to change the code as soon as the final solution is specified. >=20 > Also, if they are removed from the data channel draft, what reference = will be used in the IANA table? I think it will stay. For PPIDs you even don't have to have an RFC. You = can even register PPIDs as a person. >=20 > Regards, >=20 > Christer >=20 >=20 From Michael.Tuexen@lurchi.franken.de Thu Feb 6 00:52: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 96B4D1A01FB for ; Thu, 6 Feb 2014 00:52:28 -0800 (PST) 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, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535, 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 K7rxaKeOrv3h for ; Thu, 6 Feb 2014 00:52:27 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 29C131A018E for ; Thu, 6 Feb 2014 00:52:27 -0800 (PST) Received: from [192.168.1.200] (p508F1F22.dip0.t-ipconnect.de [80.143.31.34]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9391A1C0E97AA; Thu, 6 Feb 2014 09:52:25 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15EDA7@ESESSMB209.ericsson.se> Date: Thu, 6 Feb 2014 09:52:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6A0518D4-D15D-4970-A56C-87FEDA60F978@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> <52F2B457.8040305@alum.mit.edu> <52F2C347.7000304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15EDA7@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: message 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, 06 Feb 2014 08:52:28 -0000 On Feb 6, 2014, at 9:38 AM, Christer Holmberg = wrote: > Hi, >=20 >> If NDATA is not supported, the message size is limited to avoid the = monopolization. This limit will be signalled through SDP. >=20 > What do you mean by "signaled through SDP"? >=20 > Will the browser inform the JS app, using SDP, if the local and/or = remote peer doesn't support NDATA? What will be signalled in SDP is the maximum message size the end-point = can handle. This is needed anyway... If you don't support NDATA, you can signal a smaller value of, = let's say 16KB or so. NDATA is negotiated via the SCTP setup and there is no need for another = signalling channel. After the association is up, both sides know if NDATA is supported and, = if I remember correctly, there is a JS way of making message size limits available to the = application. So you can limit the message size if NDATA is not supported by both peers. So that = is the plan: * If NDATA is supported by both peers, message size are only limited by = reassembly memory and any limit is signalled via SDP. The corresponding support = will be in the next revision of the SDP ID. * If NDATA is not supported by both peers, a message size limit applies = to avoid monopolisation. Best regards Michael >=20 > Regards, >=20 > Christer >=20 >=20 From internet-drafts@ietf.org Thu Feb 6 02:42: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 B47791A0374; Thu, 6 Feb 2014 02:42:17 -0800 (PST) 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 DdeZSaul8OS2; Thu, 6 Feb 2014 02:42:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D237C1A02B7; Thu, 6 Feb 2014 02:42:15 -0800 (PST) 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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140206104215.19120.4391.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2014 02:42:15 -0800 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-13.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: Thu, 06 Feb 2014 10:42:18 -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 Use-cases and Requirements Authors : Christer Holmberg Stefan Hakansson Goran AP Eriksson Filename : draft-ietf-rtcweb-use-cases-and-requirements-13.txt Pages : 26 Date : 2014-02-06 Abstract: This document describes web based real-time communication use-cases. Requirements on the browser functionality are derived from the use- cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-use-cases-and-requirements-13 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 stefan.lk.hakansson@ericsson.com Thu Feb 6 02:52: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 A26B61A02F6 for ; Thu, 6 Feb 2014 02:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_84=0.6, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.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 gFOoN8DFJPDz for ; Thu, 6 Feb 2014 02:52:47 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB271A00C2 for ; Thu, 6 Feb 2014 02:52:46 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-b7-52f3697c02e2 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2E.C1.23809.C7963F25; Thu, 6 Feb 2014 11:52:44 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 11:52:44 +0100 From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?= To: "rtcweb@ietf.org" Thread-Topic: New version of use-case draft uploaded Thread-Index: Ac8jKZAtHwyyT87MQ3ivvr7TXBW1mA== Date: Thu, 6 Feb 2014 10:52:43 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CF4A182@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.16] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+JvjW5N5ucgg8mPTC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsQn+5kKHs9krNg2u4+9gbG3vouRk0NCwERiZeN2RghbTOLC vfVsXYxcHEIChxglru5oZoZwFjFKLDyzDqiKg4NNIFii6a8bSIOIgLrE5YcX2EFsYQF9iQ+b vrJBxE0keidvZ4Ww9STurdzMDGKzCKhI7FjfDFbDK+ArsefgBbDFjECLv59awwRiMwuIS9x6 Mp8J4iABiSV7zjND2KISLx//Y4WwFSV2nm1nhqg3kHh/bj6UrS2xbOFrZoj5ghInZz5hmcAo PAvJ2FlIWmYhaZmFpGUBI8sqRvbcxMyc9HKjTYzAQD645bfqDsY750QOMUpzsCiJ83546xwk JJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTE1Vji7xI53ynTrfUon+A827GoK/1hp6iGv+Z5h jXrJi8Ub+EJurjDWPnV8VWYs192ABk6Xtfsl+pzury+JWm+X4y2Wbdox7VdxenUww4pDxgf+ qovG7Z+qIbh1Ao/mWaWpl6sVmZXMPhU1F054FhP/a+m5aTPPfzhdf/NLdtP9CR8XX5i2NkKJ pTgj0VCLuag4EQDPMJhEMgIAAA== Subject: [rtcweb] New version of use-case draft uploaded X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 10:52:49 -0000 Hi,=0A= =0A= I've uploaded a new version -13 [1]. I have made changes based on input=0A= from Mary, Magnus and Chenxing+Andy, for details read further down.=0A= =0A= I hope I have caught most things; what remains to my knowledge is:=0A= * Include the requirement text the first time a requirement is derived=0A= * Group (and re-number) the claims=0A= =0A= I am hesitating to do the last thing 'cause of the risk of getting all=0A= internal references into a mess, but one day soon I will feel brave=0A= enough :-)=0A= =0A= Stefan=0A= =0A= [1]=0A= http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirement= s/=0A= =0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= On 2014-01-15 21:57, Mary Barnes wrote:=0A= > I had thought I had previously done a detailed review of this doc, but=0A= I can't find it to know whether changes suggested have been=0A= incorporated. So, I have re-reviewed the document and I think it's=0A= almost ready to progress. I think it needs some editorial clarifications=0A= and nits to be fixed as summarized below. Note, I did not review the=0A= appendix.=0A= > Regards,=0A= > Mary.=0A= > In general, I still find the style of this document very difficult to=0A= grok since the requirements are not grouped in categories and one has to=0A= keep switching back and forth in the document to match requirements to=0A= use cases.=0A= > Questions/Comments for clarification:=0A= > ----------------------------------------------------=0A= > 1) Section 1, 1st paragraph, last sentence. It's not clear to me that=0A= "e.g., a telephone" is meaningful. I don't think you're intending to=0A= interworking with a legacy PSTN connected black phone. So, it might be=0A= more accurate to say " e.g., a mobile phone or a SIP UA".=0A= =0A= Changed.=0A= =0A= > 2) Section 3.3.1.1. Next to last paragraph. I'm not sure what you mean=0A= by different "makes". I think you mean different types of devices (e.g.,=0A= mobile, SIP UA, etc. ). That all said, I don't think that's not so=0A= relevant. I think simply stating different OSs and different browsers is=0A= sufficient.=0A= =0A= Changed.=0A= =0A= > 3) Section 3.3.6.1. It's not at all clear to me why this requirement=0A= is considered specific to WebRTC. I would think the access network=0A= changes should be transparent to WebRTC. Certainly, the device needs to=0A= know what's happening, but I think whether this works is entirely based=0A= on the internals of the device and the specific access network=0A= technology, and not WebRTC application.=0A= =0A= It is not WebRTC specific per se, but is important for the use-case.=0A= What parts that solve it is of less importance IMO.=0A= =0A= > 4) Section 3.3.10.1. Why is F24 not considered an additional=0A= requirement here? Also, do you not need to have a statement as to what=0A= other use case is the basis for this one such that the core requirements=0A= are reference?=0A= =0A= I added F24 (it belongs here). I don't think we need a statement=0A= regarding the basis, it is covered in section 3.2=0A= =0A= > 5) Section 3.3.11.1, 2nd paragraph, 1st sentence. I don't understand=0A= what this is trying to say. What is meant by "enhance intelligibility"?=0A= And, what is meant by "pans the audio from different participants=0A= differently when rendering the audio".=0A= > [As an aside, I will note that some of the CLUE use cases likely=0A= encompass what you are trying to communicate here in this requirements=0A= (including subsequent paragraphs and the last "Note:"), so you may want=0A= to look at those and use similar terminology and concepts, that CLUE=0A= spent a lot of time developing. ]=0A= =0A= I updated (using similar terminology to Clue).=0A= =0A= > 6) Section 3.4. I would expect F27 to be referenced by at least one of=0A= these use cases.=0A= =0A= I added it to 3.4.1=0A= =0A= > 7) Section 4.2.=0A= > - General: I am a bit confused as there are requirements in this=0A= section that aren't referenced in section 3, including F19, F23, and F27=0A= . Perhaps, that's because there are some missing references in section 3=0A= (see item 7)? If not, then why are they there. At a minimum you should=0A= add a sentence to section 4.1 indicating that not all the requirements=0A= are derived from the use cases (contrary to what is currently stated).=0A= =0A= F19 has been removed. I added ref to F23 (and F24!) from ues-case=0A= "multi-party game with voice communication". Ref to F27 added to 3.4.1.=0A= =0A= > - What's the difference between F24 and F34?=0A= =0A= I don't know, and I removed F34=0A= =0A= > - F30. I had to read this several times to understand it due to=0A= structure. I would suggest changing as follows:=0A= > OLD:=0A= > F30 The browser must be able to use the screen (or=0A= > a specific area of the screen) or what a certain=0A= > application displays on the screen to generate=0A= > streams.=0A= > NEW:=0A= > F30 The browser must be able to generate streams using the entire user=0A= display, a specific area of the user's display or the information being=0A= displayed by a specific application.=0A= =0A= Updated.=0A= =0A= > On this one, I also think it would be good to clarify what type of=0A= stream - are you talking about using protocol to share content or or is=0A= this just a video stream? Or would you have two separate requirement to=0A= cover both of these?=0A= =0A= I would like to avoid going into detail; the idea is that it is some=0A= kind of "stream" that allows sharing what is rendered on your screen,=0A= the requirement does not need to go into what kind it is.=0A= =0A= > - F32. I can't quite grok this one. Maybe you are trying to say=0A= something like the following?=0A= > OLD:=0A= > F32 There browser must support that STUN and TURN=0A= > servers to use are supplied by other entities=0A= > than via the web application (i.e. the network=0A= > provider).=0A= > NEW:=0A= > F32 The browser must support the use of STUN and TURN=0A= > servers that are supplied by entities=0A= > other than the web application (i.e. the network=0A= > provider).=0A= =0A= Updated.=0A= =0A= > 8) Section 7. I have mixed feelings about leaving this list with URLs=0A= in the document. I think it's good to highlight the use cases that=0A= weren't incorporated and why they weren't. I think it would add a lot=0A= more value to provide a concise summary of the reasons they weren't=0A= added than just including links, in particular, since we usually don't=0A= like to publish RFCs with links.=0A= =0A= I think the entire list should go before publication. The list has been=0A= kept there as a reminder of what we included and what we did not=0A= included. I have removed it in this version.=0A= =0A= > Nits:=0A= > ------=0A= > 1) Section 1, 1st paragraph, last sentence, "at least one of the=0A= end-user client" -> "at least one of the end-user clients"=0A= > 2) Section 3.2, 1st paragraph, 1st sentence:=0A= > - "retrives" -> "retrieves"=0A= > - add a section reference for "Simple Video Communication Service"=0A= > 3) Section 3.2. , next to last sentence. "retrieved from" -> "derived=0A= from"=0A= > 4) Section 3.3.5.1, 3rd paragraph,=0A= > - 1st sentence. "session" - "session"=0A= > - 2nd sentence. "straddle the boundary between the internal network=0A= and external." -> "straddles the boundary between the internal and=0A= external networks.=0A= > 5) Section 3.3.5.1, 4th paragraph. "they still want to have the=0A= traffic to stay" -> "they still want the traffic to say"=0A= > 6) Section 3.3.61. 1st paragraph. I'm not sure why this ends with ":"=0A= > 7) Section 3.3.6.1, 2nd paragraph. "device used by one of the users=0A= have several" -> "device used by one of the users has several"=0A= > 8) Section 3.3.11.1, 1st para, 1st sentence. "In this use case is the=0A= Simple..." -> "In this use case, the Simple...."=0A= > 9) Section 3.3.11.1 3rd from last paragraph. "use experience" -> "user=0A= experience"=0A= > 10) Section 3.4.3.1, 2nd paragraph. "participant send" -> "participant=0A= sends"=0A= > 11) Section 4.2:=0A= > - F35. "of that streams" -> "that streams"=0A= =0A= Most Nit's fixed=0A= =0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= =0A= =0A= On 2014-01-29 10:29, Magnus Westerlund wrote:=0A= > Hi Partha and WG,=0A= >=0A= > I don't see any support for the changes you proposes in this discussion.= =0A= > What I see some support for is to add a statement making clear that=0A= > there might be additional NAT/Firewall traversal mechanisms than=0A= > STUN/TURN. Simon proposed:=0A= >=0A= > "Note that TURN support being mandatory does not preclude a WebRTC=0A= > endpoint from supporting additional traversal mechanisms."=0A= =0A= I added this to section 3.3.4.1=0A= =0A= >=0A= >=0A= > However, looking at the document as it is currently written, I am=0A= > uncertain where this would be added. The first mention of TURN is in=0A= > Section 3.3.4.1, and that section is focused on the global service=0A= > provider perspective and the need for location based provisioning of=0A= > NAT/Firewall traversal server resources.=0A= >=0A= > I think it can be added to Section 3.3.5.1 without being misplaced, but= =0A= > it would be given a slightly narrower scope.=0A= >=0A= > I any of you want to be more explicit where this should be included,=0A= > please be. If you are not forthcoming I will request the authors to add= =0A= > this in what they consider sensible position.=0A= >=0A= > Cheers=0A= >=0A= > Magnus=0A= >=0A= >=0A= > On 2014-01-25 17:46, Parthasarathi R wrote:=0A= >> Hi Simon,=0A= >>=0A= >>=0A= >>=0A= >> Thanks for your understanding about my firewall/NAT related problem=0A= >> statement in this draft.=0A= >>=0A= >>=0A= >>=0A= >> I have proposed the firewall/NAT related text by which the specific=0A= >> mechanism is not highlighted in the requirement document as there is no= =0A= >> WG consensus for any of the mechanism including TURN. It is possible to= =0A= >> argue hypothetically in PNTAW alias that PCP is the only mechanism=0A= >> required in WebRTC endpoint. Also, I=92m more interested in WebRTC=0A= >> gateway/server (Sec 4.3. of=0A= >> draft-ietf-rtcweb-use-cases-and-requirements-12) requirements wherein it= =0A= >> is not required to support TURN and the related mail thread is=0A= >> http://www.ietf.org/mail-archive/web/pntaw/current/msg00181.html.=0A= >>=0A= >>=0A= >>=0A= >> IMO, my proposed text without mentioning any firewall/NAT mechanism in= =0A= >> the requirement document helps to move forward without depend on the=0A= >> solution discussion in PNTAW alias.=0A= >>=0A= >>=0A= >>=0A= >> Thanks=0A= >>=0A= >> Partha=0A= >>=0A= >>=0A= >>=0A= >> *From:*Cb B [mailto:cb.list6@gmail.com]=0A= >> *Sent:* Saturday, January 25, 2014 6:22 AM=0A= >> *To:* Simon Perreault=0A= >> *Cc:* rtcweb@ietf.org; Parthasarathi R=0A= >> *Subject:* Re: [rtcweb] Query/Comment on=0A= >> draft-ietf-rtcweb-use-cases-and-requirements-12=0A= >>=0A= >>=0A= >>=0A= >>=0A= >> On Jan 24, 2014 10:17 AM, "Simon Perreault" > > wrote:=0A= >>>=0A= >>> Le 2014-01-24 12:14, Parthasarathi R a =E9crit :=0A= >>>=0A= >>>> Please note that when non-IETFers read this requirement document,=0A= >> they come=0A= >>>> to the conclusion that IETF RTCWeb WG recommends TURN and not other=0A= >>>> mechanisms. I'm saying that requirement document should not be used=0A= >> as the=0A= >>>> mechanism to eliminate the other alternatives when there is a=0A= discussion=0A= >>>> going-on in PNTAW alias. So, I'm asking for the change.=0A= >>>=0A= >>>=0A= >>> I would totally agree with that sentiment, although I don't see your=0A= >> proposed text change reflecting it accurately. How about simply:=0A= >>>=0A= >>> "Note that TURN support being mandatory does not preclude a WebRTC=0A= >> endpoint from supporting additional traversal mechanisms."=0A= >>>=0A= >>>=0A= >>=0A= >> +1 for the above text.=0A= >>=0A= >> CB=0A= >>=0A= >>> Simon=0A= >>> --=0A= >>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca=0A= >>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca=0A= >>> STUN/TURN server --> http://numb.viagenie.ca=0A= >>> _______________________________________________=0A= >>> rtcweb mailing list=0A= >>> rtcweb@ietf.org =0A= >>> https://www.ietf.org/mailman/listinfo/rtcweb=0A= >>=0A= >>=0A= >>=0A= >> _______________________________________________=0A= >> rtcweb mailing list=0A= >> rtcweb@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/rtcweb=0A= >>=0A= >=0A= >=0A= =0A= =0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= =0A= On 2014-01-16 15:18, Hutton, Andrew wrote:=0A= > Some comments in the text below.=0A= >=0A= > As a general comment I suggest changing all the "FW" abbreviations to=0A= "Firewall" are have at least a first use definition.=0A= =0A= Done=0A= =0A= >=0A= >=0A= > Andy=0A= >=0A= >=0A= >> -----Original Message-----=0A= >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=0A= >> Sent: 15 January 2014 10:20=0A= >> To: Chenxin (Xin); Hutton, Andrew; Christer Holmberg; Parthasarathi R;= =0A= >> rtcweb@ietf.org=0A= >> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-= =0A= >> requirements-12=0A= >>=0A= >> WG,=0A= >>=0A= >> It has been quite some time since the WG last call ended and a new=0A= >> revision was submitted. As Document Shepherd I want to push this=0A= >> document to publication request.=0A= >>=0A= >> Chenxin proposed below three different sets of changes to the document.= =0A= >> Does the WG support making these changes? Please indicate within the=0A= >> next week if you support or want to reject these changes.=0A= >>=0A= >> Thanks=0A= >>=0A= >> Magnus=0A= >>=0A= >>=0A= >> On 2013-10-17 12:23, Chenxin (Xin) wrote:=0A= >>> Hi Andy,=0A= >>>=0A= >>>=0A= >>>=0A= >>> I think you means F29 not F27:). When I read it , I realize that=0A= >> there=0A= >>> is cross and ambiguous between 3.3.2 and 3.3.3=0A= >>>=0A= >>>=0A= >>>=0A= >>> More details:=0A= >>>=0A= >>>=0A= >>>=0A= >>> The topic of 3.3.2 is "Simple Video Communication Service, *NAT/FW*=0A= >>> that blocks UDP". But in the description and requirement, only *NAT*=0A= >> is=0A= >>> considered.=0A= >>>=0A= >>> The topic of 3.3.3 is "Simple Video Communication Service, FW that=0A= >>> only allows http", But only *http proxy* deployed scenarios is=0A= >> considered.=0A= >>>=0A= >>>=0A= >>>=0A= >>> There are other usecases " FW block UDP, incoming TCP, Http=0A= >> allowing=0A= >>> FW without http proxy deplolyed under the permission of FW policy" ,=0A= >>> which is lost in the description. If we need consider these usecases=0A= >> , I=0A= >>> suggest to make some change to the description.=0A= >>>=0A= >>>=0A= >>>=0A= >>> Proposal 1 :=0A= >>>=0A= >>>=0A= >>>=0A= >>> add FW related words to section 3.3.2=0A= >>>=0A= >>> -------------------------------------------------=0A= >>>=0A= >>> 3.3.2. Simple Video Communication Service, NAT/FW that blocks UDP=0A= >>>=0A= >>>=0A= >>>=0A= >>> 3.3.2.1. Description=0A= >>>=0A= >>>=0A= >>>=0A= >>> This use-case is almost identical to the Simple Video=0A= >> Communication=0A= >>>=0A= >>> Service use-case (Section 3.3.1). The difference is that one of=0A= >> the=0A= >>>=0A= >>> users is behind a NAT*/FW* that blocks UDP traffic.=0A= >>>=0A= >>> .=0A= >=0A= > [AndyH] - I support this change.=0A= =0A= Changed=0A= =0A= >=0A= >=0A= >>>=0A= >>>=0A= >>>=0A= >>> 3.3.2.2. Additional Requirements=0A= >>>=0A= >>>=0A= >>>=0A= >>> F29 The browser must be able to send streams and=0A= >>>=0A= >>> data to a peer in the presence of NATs *and FWs* that=0A= >>>=0A= >>> block UDP traffic ,* when FW policy allows WebRTC=0A= >> traffic*.=0A= >=0A= > [AndyH] - I support this change.=0A= =0A= Changed=0A= =0A= >=0A= >=0A= >>>=0A= >>> -------------------------------------------------------=0A= >>>=0A= >>> Proposal 2: If the" Http allowing FW without http proxy deployed"=0A= >>> case is impliedly included in F29. I suggest to change the topics of=0A= >>> 3.3.3 to "Simple Video Communication Service, FW that only allows=0A= >>> traffic via a http proxy". So the 3.3.3 is a specific case.=0A= >>>=0A= >=0A= > [AndyH] Yes the heading of 3.3.3 should have been changed during the=0A= last edit to "Simple Video Communication Service, FW that only allows=0A= traffic via a HTTP Proxy". I support this change.=0A= =0A= Changed.=0A= =0A= >=0A= >=0A= >>>=0A= >>>=0A= >>> Proposal 3: If " Http allowing FW without http proxy deployed"=0A= >> case=0A= >>> need to be explicitly mentioned. I suggest to add some descriptions=0A= >> to 3.3.3=0A= >>>=0A= >>> -----------------------------------------------------------------=0A= >>>=0A= >>> 3.3.3. Simple Video Communication Service, FW that only allows http=0A= >>>=0A= >>>=0A= >>>=0A= >>> 3.3.3.1. Description=0A= >>>=0A= >>>=0A= >>>=0A= >>> This use-case is almost identical to the Simple Video=0A= >> Communication=0A= >>>=0A= >>> Service use-case (Section 3.3.1). The difference is that one of=0A= >> the=0A= >>>=0A= >>> users is behind a http allowing FW or a FW that only allows=0A= >> traffic=0A= >>> via a HTTP Proxy.=0A= >>>=0A= >>>=0A= >=0A= > [AndyH] I don't believe the intention here was to state a requirement=0A= that WebRTC media should be able to flow through a FW only allowing=0A= HTTP. Therefore I think the original description is ok it is just the=0A= heading that needs to change.=0A= >=0A= >=0A= >>>=0A= >>> 3.3.3.2. Additional Requirements=0A= >>>=0A= >>>=0A= >>>=0A= >>> F37 The browser must be able to send streams and=0A= >>>=0A= >>> data to a peer in the presence of http allowing FWs or FWs=0A= >>> that only=0A= >>>=0A= >>> allows traffic via a HTTP Proxy, when FW policy=0A= >>>=0A= >>> allows WebRTC traffic.=0A= >>>=0A= >=0A= > [AndyH] The existing text is in the 012 draft is ok and I don't think=0A= this change is needed as again I don't believe the intention here was to=0A= state a requirement that WebRTC media should be able to flow through a=0A= FW only allowing HTTP.=0A= >=0A= >=0A= >>> -------------------------------------------------------------------=0A= >>>=0A= >>>=0A= >=0A= >>>=0A= >>>=0A= >>>=0A= >>> Best Regards,=0A= >>>=0A= >>> Xin=0A= >>>=0A= >>>=0A= >>>=0A= >>=0A= >>=0A= >> --=0A= >>=0A= >> Magnus Westerlund=0A= >>=0A= >> ----------------------------------------------------------------------= =0A= >> Services, Media and Network features, Ericsson Research EAB/TXM=0A= >> ----------------------------------------------------------------------= =0A= >> Ericsson AB | Phone +46 10 7148287=0A= >> F=E4r=F6gatan 6 | Mobile +46 73 0949079=0A= >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= >> ----------------------------------------------------------------------= =0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From christer.holmberg@ericsson.com Thu Feb 6 03:15: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 5E5AE1A0387 for ; Thu, 6 Feb 2014 03:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 Pglg-7db6dw9 for ; Thu, 6 Feb 2014 03:15:11 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E7DFB1A0385 for ; Thu, 6 Feb 2014 03:15:10 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-2f-52f36ebd19b3 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3F.5E.10875.DBE63F25; Thu, 6 Feb 2014 12:15:09 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 12:15:08 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: Data channel: JavaScript usage of data channel without the Data Channel Protocol? Thread-Index: Ac8jLH45tofIO7FIT8mB4CIU+axUag== Date: Thu, 6 Feb 2014 11:15:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15F1AC@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.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D15F1ACESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvje7evM9BBhOmyFis/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujB33VrAXbJSqeLHsPXMDY5t4FyMnh4SAicTaqytYIWwxiQv3 1rN1MXJxCAkcYpSYfnoWO4SziFHi87INjF2MHBxsAhYS3f+0QRpEBNQlLj+8wA5iCwvESOw4 fIUNIp4o8ebSUWYIW09iyswDjCA2i4CKxJQvb8HivAK+Es8WnAWLMwIt/n5qDROIzSwgLnHr yXwmiIMEJJbsOc8MYYtKvHz8D+pQJYkfGy6xQNTnSxy72A41U1Di5MwnLBMYhWYhGTULSdks JGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FSN7bmJmTnq54SZGYNgf3PJbdwfjqXMi hxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBoPT88jElR/JVBxGuH1xaV Qn13P7rat8vp3VredlOb584q5wBF/Y0NJeIyaqWuW/9zHvYRDjD9wzF7yka1K3OcAnSU3nt7 /+0OY29aVcq1OvZPye+Znw78qfcWf6UXXvdIUSH9Lz/jiR9vgnJ7++Mb3705kP8hTKLl9uv0 I/nt5gklz4M3XlFiKc5INNRiLipOBABc89edSQIAAA== Subject: [rtcweb] Data channel: JavaScript usage of data channel without the Data Channel Protocol? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 11:15:13 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D15F1ACESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As was indicated earlier, the usage of the Data Channel Protocol (DCP) is o= ptional with the Data Channel. However, if I understand the API correctly, only the DCP "open"/"ack" messa= ges will trigger a JavaScript "open" event. If so, how will my JS App be able to use the data channel if I do NOT use t= he Data Channel Protocol? Can I use it without the "open" event, and/or is = there something else that will trigger it? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D15F1ACESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As was indicated earlier, the usage of the Data Chan= nel Protocol (DCP) is optional with the Data Channel.

 

However, if I understand the API correctly, only the= DCP "open"/"ack" messages will trigger a JavaScript &q= uot;open" event.

 

If so, how will my JS App be able to use the data ch= annel if I do NOT use the Data Channel Protocol? Can I use it without the &= #8220;open” event, and/or is there something else that will trigger i= t?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D15F1ACESESSMB209erics_-- From Raju.Makaraju@alcatel-lucent.com Thu Feb 6 03:46: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 0197B1A00E3 for ; Thu, 6 Feb 2014 03:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_HI=-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 UbRNIz61R6lb for ; Thu, 6 Feb 2014 03:46:20 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B72161A00E0 for ; Thu, 6 Feb 2014 03:46:20 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s16BkGWG003849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2014 05:46:16 -0600 (CST) 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 s16Bk58H030357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 06:46:13 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Thu, 6 Feb 2014 06:45:46 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Michael Tuexen Thread-Topic: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing Thread-Index: AQHPIxZ9eymmg1h0ZkO/jyQ6XJmtrJqoFChA Date: Thu, 6 Feb 2014 11:45:46 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15ED94@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 11:46:23 -0000 > >>> As discussed in the last IETF meeting, this PPID based fragmentation = and > reassembly will be removed from the ID. > >> > >> I assume the associated PPID values will also be un-registered with IA= NA? > > I guess they will stay... They are supported by Firefox and PPIDs are a > pretty cheap resource. They are from a pool of 32-bit entities. That is w= hy > we registered the values before the RFCs get published. >=20 > So, does that mean my WebRTC entity has to support them, in case the remo= te > peer is on Firefox? >=20 > Also, if they are removed from the data channel draft, what reference wil= l > be used in the IANA table? [Raju] Per my understanding some of the PPIDs are still needed. The send() API for data channel comes in 4 flavors: 1. void send (DOMString data); 2. void send (Blob data); 3. void send (ArrayBuffer data); 4. void send (ArrayBufferView data); 1 maps to text data 2,3,4 maps to binary data When one end sends this data one would expect that the other end gets an on= message() callback with same (if other end is also javascript) or similar(i= f other end is a native client) data structure. I believe this is achieved = by using PPIDs. We need at least 2 PPIDs: text and binary. So, existing "DOM String last" (= =3D51) and "Binary Data Last"(=3D53) can be used. To facilitate interworking with native clients I don't think there is a nee= d to represent all sub-data types of send() in PPIDs as native client on th= e other end using C/C++ won't know what "ArrayBufferView" is?! Also, I think "DOMString" PPID is too specific to Javascript, instead it sh= ould probably have a generic name like "UTF-16 String". The send API can st= ill use DOMString as this is Javascript API. -Raju From christer.holmberg@ericsson.com Thu Feb 6 03:50: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 4CB001A00ED for ; Thu, 6 Feb 2014 03:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_72=0.6, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_MED=-2.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 zj1cqcMWKYZK for ; Thu, 6 Feb 2014 03:50:45 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 836A31A00E6 for ; Thu, 6 Feb 2014 03:50:44 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-39-52f377122810 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E1.B9.23809.21773F25; Thu, 6 Feb 2014 12:50:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 12:50:42 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Michael Tuexen" Thread-Topic: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing Thread-Index: Ac8jEP4UAFTLik6/TaCDQ1g2OxFaDP//90SA///s4PCAAEsOAP//7iIA Date: Thu, 6 Feb 2014 11:50:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15F2B3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@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+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvja5Q+ecgg4dX9S0uNi1htGjYeIXV Yu2/dnYHZo/WZ3tZPZYs+cnksaFlB1MAcxSXTUpqTmZZapG+XQJXxt29H9gKPghWrFuxi7mB cQ5fFyMnh4SAicSd3deYIWwxiQv31rOB2EIChxglPsyI7GLkArIXMUrsnvMAKMHBwSZgIdH9 TxukRkSgRuLIunksIDazgLrEncXn2EFsYYEQiWl7zzBC1IRKLL02gRnCdpO4d2Yx2HwWARWJ /XtXgcV5BXwlehadZ4TYO59J4uA0URCbUyBW4va9DWDzGYFu+35qDRPELnGJW0/mM0HcLCCx ZM95qPtFJV4+/scKYStKtD9tYISo15FYsPsTG4StLbFs4WuovYISJ2c+YZnAKDYLydhZSFpm IWmZhaRlASPLKkb23MTMnPRyo02MwKg5uOW36g7GO+dEDjFKc7AoifN+eOscJCSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoExt5qxVO/9tqJQyX3W7v57Erylt4vnbpkdIOt8aqVxgrSt/xyT 6qg7DAzZv5OXlhh8Dlq64e9kEw/7w3LFSlsXzRXX3tC3UMTWJuO6yh85DbHpZ+riyzYu/au1 bZ3Fv3hpvesZCT3XPUU2polaBges212+KKo/WU9ncbOn7nJ73pm/DklUtyuxFGckGmoxFxUn AgCqp+W3aAIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 11:50:46 -0000 Hi, I agree that PPID values are still needed, and my question was not about re= moving all of them - only the ones used with application-level fragmentatio= n. Regards, Christer -----Original Message----- From: Makaraju, Maridi Raju (Raju) [mailto:Raju.Makaraju@alcatel-lucent.com= ]=20 Sent: 6. helmikuuta 2014 13:46 To: Christer Holmberg; Michael Tuexen Cc: rtcweb@ietf.org Subject: RE: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multi= plexing > >>> As discussed in the last IETF meeting, this PPID based=20 > >>> fragmentation and > reassembly will be removed from the ID. > >> > >> I assume the associated PPID values will also be un-registered with IA= NA? > > I guess they will stay... They are supported by Firefox and PPIDs=20 > > are a > pretty cheap resource. They are from a pool of 32-bit entities. That=20 > is why we registered the values before the RFCs get published. >=20 > So, does that mean my WebRTC entity has to support them, in case the=20 > remote peer is on Firefox? >=20 > Also, if they are removed from the data channel draft, what reference=20 > will be used in the IANA table? [Raju] Per my understanding some of the PPIDs are still needed. The send() API for data channel comes in 4 flavors: 1. void send (DOMString data); 2. void send (Blob data); 3. void send (ArrayBuffer data); 4. void send (ArrayBufferView data); 1 maps to text data 2,3,4 maps to binary data When one end sends this data one would expect that the other end gets an on= message() callback with same (if other end is also javascript) or similar(i= f other end is a native client) data structure. I believe this is achieved = by using PPIDs. We need at least 2 PPIDs: text and binary. So, existing "DOM String last" (= =3D51) and "Binary Data Last"(=3D53) can be used. To facilitate interworking with native clients I don't think there is a nee= d to represent all sub-data types of send() in PPIDs as native client on th= e other end using C/C++ won't know what "ArrayBufferView" is?! Also, I think "DOMString" PPID is too specific to Javascript, instead it sh= ould probably have a generic name like "UTF-16 String". The send API can st= ill use DOMString as this is Javascript API. -Raju From Raju.Makaraju@alcatel-lucent.com Thu Feb 6 03:58: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 6CEBB1A0385 for ; Thu, 6 Feb 2014 03:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 LqAa7d7Y3QJ6 for ; Thu, 6 Feb 2014 03:58:49 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 20B251A00E6 for ; Thu, 6 Feb 2014 03:58:49 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s16BwfjX015756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2014 05:58:42 -0600 (CST) 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 s16BwTeW001375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 06:58:41 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Thu, 6 Feb 2014 06:58:21 -0500 From: "Makaraju, Maridi Raju (Raju)" To: "Chenxin (Xin)" , Salvatore Loreto , Christer Holmberg Thread-Topic: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? Thread-Index: Ac8cATohOVAlbIwKQYO2t8QqB7DbKv//80KA///u5jCAABV0AP//7Huw//GCr+A= Date: Thu, 6 Feb 2014 11:58:20 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D142F0D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D144004@ESESSMB209.ericsson.se> <4B7CB104-BD52-4392-A0B5-4F5C187AA001@ericsson.com> <9E34D50A21D1D1489134B4D770CE0397680AB034@SZXEMA504-MBX.china.huawei.com> In-Reply-To: <9E34D50A21D1D1489134B4D770CE0397680AB034@SZXEMA504-MBX.china.huawei.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 11:58:50 -0000 >>>> Q1: Assuming that both endpoints want to use the data channel, do both >endpoints need to send DATA_CHANNEL_OPEN >>>> (on separate SCTP streams)? Or, can one of the endpoints, if it has re= ceived >DCO, start using the data channel (using a SCTP stream of its choice)? [Raju] As explained by others already, DC is bidirectional, however both di= rections have to use the same SCTP stream that was assigned for the data ch= annel (which is done as part of DC OPEN an DC ACK). In fact the PeerConnect= ion send() API does not allow stream # to be specified by the app, stream #= is internally tied to DC. -Raju From christer.holmberg@ericsson.com Thu Feb 6 04:03: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 176411A0394 for ; Thu, 6 Feb 2014 04:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 2MyqK4-S5DuK for ; Thu, 6 Feb 2014 04:03:28 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 04F461A0393 for ; Thu, 6 Feb 2014 04:03:27 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-24-52f37a0e9898 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 5E.10.04853.E0A73F25; Thu, 6 Feb 2014 13:03:26 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 13:03:25 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Chenxin (Xin)" , Salvatore Loreto Thread-Topic: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? Thread-Index: Ac8cATohOVAlbIwKQYO2t8QqB7DbKv//80KA///u5jCAABV0AP//7Huw//GCr+D/4wMwcA== Date: Thu, 6 Feb 2014 12:03:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15F323@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D142F0D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D144004@ESESSMB209.ericsson.se> <4B7CB104-BD52-4392-A0B5-4F5C187AA001@ericsson.com> <9E34D50A21D1D1489134B4D770CE0397680AB034@SZXEMA504-MBX.china.huawei.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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+JvjS5f1ecgg5n3JCxuXulltGjYeIXV Yu2/dnYHZo/WZ3tZPVqOvGX1WLLkJ1MAcxSXTUpqTmZZapG+XQJXxu9VXxgLlnFUPL7zmrWB cT9bFyMnh4SAicTv9hvsELaYxIV764HiXBxCAicYJXZ9a2GFcBYxSux5sBkow8HBJmAh0f1P GyQuIrCKUeLNt/mMIN3MAuoSdxafA5skLJAusa5lGytIvYhAhsT9rSIgYRGBMIkdV3+ygNgs AioSJ+5vZgWxeQV8JW59aWeH2DWHWeL+jelMIAlOgViJjqkdYEWMQNd9P7WGCWKXuMStJ/OZ IK4WkFiy5zwzhC0q8fLxP1YIW1Gi/WkD1G06Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYxWYh GTsLScssJC2zkLQsYGRZxShZnFpcnJtuZKCXm55bopdalJlcXJyfp1ecuokRGF0Ht/w22sF4 co/9IUZpDhYlcd7rrDVBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgnFqUr+/dqzr45u9Vu xebtMS/tOSzjwzXbb8/r1mOKnfp6fXlG1Z5Gv65J0faaP5N55DjT2EQfCPftf8YZ+ufxl/qo uf+/R9s8nLm691DLp9evRGJKT0Y2bdqfarCxtb54Jt++nRXGwTr1Z4R2r1ok+K9WU/SL4s/w D0L17LX1WdwfWiOEWpRYijMSDbWYi4oTATuFtpd8AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 12:03:29 -0000 Hi, >>>>> Q1: Assuming that both endpoints want to use the data channel, do bot= h >>>>>endpoints need to send DATA_CHANNEL_OPEN >>>>> (on separate SCTP streams)? Or, can one of the endpoints, if it has r= eceived >>>>>>DCO, start using the data channel (using a SCTP stream of its choice)= ? > > [Raju] As explained by others already, DC is bidirectional, however both = directions have to use the same SCTP stream that was assigned for the data = channel (which is done as part of DC OPEN an DC ACK). When I send DC OPEN, do I know on which stream the DC ACK will arrive? If n= ot, if there are DC OPEN/ACKs for multiple data channels, how is a DC ACK m= apped to the associated DC OPEN? There is no "transaction id", or similar, = in the messages. > In fact the PeerConnection send() API does not allow stream # to be speci= fied by the app, stream # is internally tied to DC. My understanding is that it is possible to "manually" assign a stream id wh= en creating the data channel. But, I may be wrong. Regards, Christer From Raju.Makaraju@alcatel-lucent.com Thu Feb 6 04:08: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 719DB1A03A5 for ; Thu, 6 Feb 2014 04:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 RcHVrYhOFEbE for ; Thu, 6 Feb 2014 04:08:45 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id AF6771A03A3 for ; Thu, 6 Feb 2014 04:08:45 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s16C8gmK010321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2014 06:08:42 -0600 (CST) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s16C8feO011050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 07:08:42 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 6 Feb 2014 07:08:41 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Michael Tuexen , Christer Holmberg Thread-Topic: [rtcweb] RTCWEB Data Channel: message interleaving Thread-Index: AQHPIsaGtTtVxkBpl0uo4mWaQvx+DpqnSFawgADrMwCAAAhtgIAAA9AA///gvGA= Date: Thu, 6 Feb 2014 12:08:41 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> <52F2B457.8040305@alum.mit.edu> <52F2C347.7000304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15EDA7@ESESSMB209.ericsson.se> <6A0518D4-D15D-4970-A56C-87FEDA60F978@lurchi.franken.de> In-Reply-To: <6A0518D4-D15D-4970-A56C-87FEDA60F978@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: message 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, 06 Feb 2014 12:08:47 -0000 >So you can > limit the message size if NDATA is not supported by both peers. So that i= s > the plan: > * If NDATA is supported by both peers, message size are only limited by > reassembly > memory and any limit is signalled via SDP. The corresponding support wi= ll > be in the > next revision of the SDP ID. [Raju] The key is "next revision of the SDP ID". It is understood that NDAT= A support indication is only avilable after both the peers talk. But then, = the initial message sizes were already conveyed (to make them talk). Now, i= f the new message size per "no NDATA support"/"NDATA support" is lower/high= er then another ound of end-to-end signaling is needed to update the peers.= Not optimal, but I do not see any other better way other than "starting co= nservatively with lower values initially assuming no NDATA support; later w= hen NDATA support becomes widespread default values can be higher". Best Regards Raju From Raju.Makaraju@alcatel-lucent.com Thu Feb 6 04:29: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 97EE11A03A3 for ; Thu, 6 Feb 2014 04:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 JjXDQ57xjtrW for ; Thu, 6 Feb 2014 04:29:39 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 76DDF1A0385 for ; Thu, 6 Feb 2014 04:29:39 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s16CTT0m014882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2014 06:29:30 -0600 (CST) 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 s16CTTf7014118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 07:29:29 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 6 Feb 2014 07:29:28 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , "Chenxin (Xin)" , Salvatore Loreto Thread-Topic: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? Thread-Index: Ac8cATohOVAlbIwKQYO2t8QqB7DbKv//80KA///u5jCAABV0AP//7Huw//GCr+D/4wMwcP/GAokw Date: Thu, 6 Feb 2014 12:29:28 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D142F0D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D144004@ESESSMB209.ericsson.se> <4B7CB104-BD52-4392-A0B5-4F5C187AA001@ericsson.com> <9E34D50A21D1D1489134B4D770CE0397680AB034@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1D15F323@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15F323@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 12:29:41 -0000 > > [Raju] As explained by others already, DC is bidirectional, however bot= h > directions have to use the same SCTP stream that was assigned for the dat= a > channel (which is done as part of DC OPEN an DC ACK). >=20 > When I send DC OPEN, do I know on which stream the DC ACK will arrive? If > not, if there are DC OPEN/ACKs for multiple data channels, how is a DC AC= K > mapped to the associated DC OPEN? There is no "transaction id", or simila= r, > in the messages. [Raju]=20 http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-01#section-6 say= s stream id in ACK is same as the one in DC OPEN: If a DATA_CHANNEL_OPEN message is received on an unused stream, the stream identifier corresponds to the role of the peer and all parameters in the DATA_CHANNEL_OPEN message are valid, then a corresponding DATA_CHANNEL_ACK message is sent on the stream with the same stream identifier as the one the DATA_CHANNEL_OPEN message was received on. > > In fact the PeerConnection send() API does not allow stream # to be > specified by the app, stream # is internally tied to DC. >=20 > My understanding is that it is possible to "manually" assign a stream id > when creating the data channel. But, I may be wrong. [Raju] Yes, it is possible. For createDataChannel() API (http://dev.w3.org/2011/webrtc/editor/webrtc.ht= ml#dom-peerconnection-createdatachannel) set 'negotiated' to 'true' and 'id= ' to the stread id you want. Then it is the responsibility of the applicati= on to convey this info to the other end and the internal DC protcol (DC OPE= N/ACK etc.) won't be used to manage the data channel/streams. However, I am not sure if "negotiated=3Dfalse" and specifying "id" is a val= id combination. For id the above spec says the following, so may be it is a= llowed, but then user have to manage stream ids to avoid collisions: id of type unsigned short Overrides the default selection of id for this channel. It is also interesting to note that the spec allows within the same SCTP li= nk, some DCs can be negotiated using inband internal protocol while other D= Cs can be negotiated using external out-of-band protocol! However, I think = applications should try to avoid mixing these methods to avoid conflicts in= using stream ids. -Raju From christer.holmberg@ericsson.com Thu Feb 6 04:39: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 DFA9E1A03A3 for ; Thu, 6 Feb 2014 04:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 8N8pTZ7451ME for ; Thu, 6 Feb 2014 04:39:12 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 872941A00F6 for ; Thu, 6 Feb 2014 04:39:11 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-e4-52f3826d1e6a Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F3.1A.10875.D6283F25; Thu, 6 Feb 2014 13:39:10 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 13:39:09 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Chenxin (Xin)" , Salvatore Loreto Thread-Topic: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? Thread-Index: Ac8cATohOVAlbIwKQYO2t8QqB7DbKv//80KA///u5jCAABV0AP//7Huw//GCr+D/4wMwcP/GAokw/4wAYIA= Date: Thu, 6 Feb 2014 12:39:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15FC31@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D142F0D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D144004@ESESSMB209.ericsson.se> <4B7CB104-BD52-4392-A0B5-4F5C187AA001@ericsson.com> <9E34D50A21D1D1489134B4D770CE0397680AB034@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1D15F323@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+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvjW5e0+cgg5XnmSxuXulltGjYeIXV Yu2/dnYHZo/WZ3tZPVqOvGX1WLLkJ1MAcxSXTUpqTmZZapG+XQJXxtuz81kLlnJVnDv6gbmB sZ+ji5GTQ0LAROLMi5nsELaYxIV769m6GLk4hAQOMUrcOzaBBSQhJLCIUWLePMkuRg4ONgEL ie5/2iA1IgKrGCXefJvPCFLDLKAucWfxObBBwgLpEutatrGC1IsIZEjc3yoCEhYRSJJYe7KT CcRmEVCR+NDcATaeV8BXovfWEkaIVZtZJG72SoLYnAKxEi92t4DVMALd9v3UGiaIVeISt57M Z4K4WUBiyZ7zzBC2qMTLx/9YIWxFifanDVCn6Ugs2P2JDcLWlli28DUzxF5BiZMzn7BMYBSb hWTsLCQts5C0zELSsoCRZRUje25iZk56ueEmRmDUHNzyW3cH46lzIocYpTlYlMR5P7x1DhIS SE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWHrReIe18XnFoqqT0qsU3nGs+NfA/l11tvovS0+J 9p8Nr9i+Wp0u+tt969b9O9XTUo5zF4VsTL3i0Wnv2RDwZXPys+NxB3subKj1OyZm178kx+Hi w/3pUQVmlmqbbu8S/P32+eL0jM99uVOUPK8otHy6UKkdvMT26adtN4TX8srml8R3fGV3U2Ip zkg01GIuKk4EAEVXbDhoAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 12:39:14 -0000 Hi, >>> [Raju] As explained by others already, DC is bidirectional, however=20 >>> both directions have to use the same SCTP stream that was assigned for = the=20 >>> data channel (which is done as part of DC OPEN an DC ACK). >>>=20 >> When I send DC OPEN, do I know on which stream the DC ACK will arrive?=20 >> If not, if there are DC OPEN/ACKs for multiple data channels, how is a=20 >> DC ACK mapped to the associated DC OPEN? There is no "transaction id",=20 >> or similar, in the messages. > > [Raju] > http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-01#section-6 s= ays stream id in ACK is same as the one in DC OPEN: > If a DATA_CHANNEL_OPEN message is received on an unused stream, the > stream identifier corresponds to the role of the peer and all > parameters in the DATA_CHANNEL_OPEN message are valid, then a > corresponding DATA_CHANNEL_ACK message is sent on the stream with the > same stream identifier as the one the DATA_CHANNEL_OPEN message was > received on. And if the stream id is already used?=20 The "core" data channel draft does not mandate the usage of the same stream= id values in both directions.=20 Are you saying that, when using the DCP, one must use the same stream id va= lue in both directions? Regards, Christer From Raju.Makaraju@alcatel-lucent.com Thu Feb 6 04:52: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 CA72C1A037C for ; Thu, 6 Feb 2014 04:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 5PnDsQUOOlH3 for ; Thu, 6 Feb 2014 04:52:21 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BAFDB1A00F6 for ; Thu, 6 Feb 2014 04:52:21 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s16CqD7J027253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2014 06:52:13 -0600 (CST) 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 s16CqCb6025607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 07:52:13 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Thu, 6 Feb 2014 07:52:12 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , "Chenxin (Xin)" , Salvatore Loreto Thread-Topic: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? Thread-Index: Ac8cATohOVAlbIwKQYO2t8QqB7DbKv//80KA///u5jCAABV0AP//7Huw//GCr+D/4wMwcP/GAokw/4wAYID/F/v1AA== Date: Thu, 6 Feb 2014 12:52:11 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D142F0D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D144004@ESESSMB209.ericsson.se> <4B7CB104-BD52-4392-A0B5-4F5C187AA001@ericsson.com> <9E34D50A21D1D1489134B4D770CE0397680AB034@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1D15F323@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D15FC31@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15FC31@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 12:52:24 -0000 > > [Raju] > > http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-01#section-6 > says stream id in ACK is same as the one in DC OPEN: > > If a DATA_CHANNEL_OPEN message is received on an unused stream, the > > stream identifier corresponds to the role of the peer and all > > parameters in the DATA_CHANNEL_OPEN message are valid, then a > > corresponding DATA_CHANNEL_ACK message is sent on the stream with the > > same stream identifier as the one the DATA_CHANNEL_OPEN message was > > received on. >=20 > And if the stream id is already used? [Raju] DC protocol says: If a DATA_CHANNEL_OPEN message is received on an already used SCTP stream or there are any problems with parameters within the DATA_CHANNEL_OPEN message or the DATA_CHANNEL_OPEN message itself is not well-formed, the receiver MUST reset the corresponding outgoing SCTP stream using [RFC6525] and MUST NOT send a DATA_CHANNEL_ACK message in response to the received message. >=20 > The "core" data channel draft does not mandate the usage of the same stre= am > id values in both directions. >=20 > Are you saying that, when using the DCP, one must use the same stream id > value in both directions? [Raju] Correct. When external DC negotiation is used, I expect most implementations to use = same stream ids, but not a MUST, in both directions. This not only simplifi= es the procedures but also aligns with internal DCP allocation of streams. -Raju From christer.holmberg@ericsson.com Thu Feb 6 04:57: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 8CEC11A03B7 for ; Thu, 6 Feb 2014 04:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 2idRSJv5go5C for ; Thu, 6 Feb 2014 04:57:30 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id C4AA71A00F5 for ; Thu, 6 Feb 2014 04:57:29 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-19-52f386b7f9f2 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id FA.47.04853.7B683F25; Thu, 6 Feb 2014 13:57:28 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 13:57:27 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Chenxin (Xin)" , Salvatore Loreto Thread-Topic: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? Thread-Index: Ac8cATohOVAlbIwKQYO2t8QqB7DbKv//80KA///u5jCAABV0AP//7Huw//GCr+D/4wMwcP/GAokw/4wAYID/F/v1AP4v9dVQ Date: Thu, 6 Feb 2014 12:57:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15FD97@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D142F0D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D144004@ESESSMB209.ericsson.se> <4B7CB104-BD52-4392-A0B5-4F5C187AA001@ericsson.com> <9E34D50A21D1D1489134B4D770CE0397680AB034@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1D15F323@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D15FC31@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+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvje6Ots9BBl9ecVrcvNLLaNGw8Qqr xdp/7ewOzB6tz/ayerQcecvqsWTJT6YA5igum5TUnMyy1CJ9uwSujFOfn7IXbOGtaD/yhbWB 8QZXFyMnh4SAiUTXtWWMELaYxIV769m6GLk4hAROMEqsvb+HFcJZxCjxb9lUIIeDg03AQqL7 nzZIXERgFaPEm2/zwbqZBdQl7iw+xw5iCwukS6xr2QZWLyKQIXF/qwhIWEQgT6Jxwz4mEJtF QEVi357TYDavgK/ErKkbWCB2nWKVaGnfDJbgFIiVaNv2GWwmI9B130+tYYLYJS5x68l8Joir BSSW7DnPDGGLSrx8/I8VwlaUaH/aAHWbjsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERrFZSMbO QtIyC0nLLCQtCxhZVjFKFqcWF+emGxno5abnluilFmUmFxfn5+kVp25iBEbXwS2/jXYwntxj f4hRmoNFSZz3OmtNkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGjoqWH2/m/laNXcn/frZg oTHD/hsnv/AVTd5mf2TKjcyJx0OkXa1vXvkQqtCgauvUGSVezyi+b+nvK/55YsH/Tm1iEXh3 IfJCd55jvf6FDNauKw+fhvI8n5m2eub075aKE+s4bn/pdupmYGp+qSm4dmpC/p6d541OdxtV fzv9JW/j1iVSB58EKrEUZyQaajEXFScCAG0QO+F8AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 12:57:31 -0000 Hi, >>> [Raju] >>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-01#sectio >>> n-6 says stream id in ACK is same as the one in DC OPEN: >>> If a DATA_CHANNEL_OPEN message is received on an unused stream, the >>> stream identifier corresponds to the role of the peer and all >>> parameters in the DATA_CHANNEL_OPEN message are valid, then a >>> corresponding DATA_CHANNEL_ACK message is sent on the stream with the >>> same stream identifier as the one the DATA_CHANNEL_OPEN message was >>> received on. >>=20 >> And if the stream id is already used? > [Raju] DC protocol says: > > If a DATA_CHANNEL_OPEN message is received on an already used SCTP > stream or there are any problems with parameters within the > DATA_CHANNEL_OPEN message or the DATA_CHANNEL_OPEN message itself is > not well-formed, the receiver MUST reset the corresponding outgoing > SCTP stream using [RFC6525] and MUST NOT send a DATA_CHANNEL_ACK > message in response to the received message. >=20 >> The "core" data channel draft does not mandate the usage of the same=20 >> stream id values in both directions. >>=20 >> Are you saying that, when using the DCP, one must use the same stream=20 >> id value in both directions? > > [Raju] Correct. > When external DC negotiation is used, I expect most implementations to us= e same stream ids, but not a MUST, in both directions. This not only simpli= fies the procedures but also aligns with internal DCP allocation of streams= . Is there a reason why we couldn't mandate usage of the same id in the core = spec? Then the correlation would not be dependent on the negotiation mechan= ism(s). Regards, Christer From pkyzivat@alum.mit.edu Thu Feb 6 08: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 76B5A1A01BD for ; Thu, 6 Feb 2014 08:23:03 -0800 (PST) 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 7dg0tTy3N5RT for ; Thu, 6 Feb 2014 08:23:02 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4A11A0143 for ; Thu, 6 Feb 2014 08:23:02 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta02.westchester.pa.mail.comcast.net with comcast id P3DS1n0031GhbT8514P1DA; Thu, 06 Feb 2014 16:23:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id P4P11n0083ZTu2S3T4P1mg; Thu, 06 Feb 2014 16:23:01 +0000 Message-ID: <52F3B6E5.9040001@alum.mit.edu> Date: Thu, 06 Feb 2014 11:23:01 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> <52F2B457.8040305@alum.mit.edu> <52F2C347.7000304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15EDA7@ESESSMB209.ericsson.se> <6A0518D4-D15D-4970-A56C-87FEDA60F978@lurchi.franken.de> In-Reply-To: <6A0518D4-D15D-4970-A56C-87FEDA60F978@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391703781; bh=WOpNa9mdk2s6YlLQBP6eTYwJfRpJig351zxZypnJ6M4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QFXNs0Wq9AP1x0esuFuEQVrHK8NI6jBiG8WgECyda63Cc14foojy5JDeMaJfcpUSs psj+opTjGECXnUieL9EEbx4stslQomxirqQdJzg2uqBaaWb4AVg+y1ULE3PBIyWm7V 0a6DA/sp9XIULKJfVPva4qW1YLumr5DhTI72ze7K5o917/odV4c35goPa30gpOKlWS VaDsp8Qm9LBUkOvxquuAgmSwfjNa1kUFvBhlH/KD85dKzMYqihCj5QpvQtyCf4Z9ki DsPhdXLbTBFtxK87TYSlY1nORCkYITtboJo1i6w1E9YDD3W2jVB1zPlkV/i2ZXuS1F zrTjmZKa2hRFg== Subject: Re: [rtcweb] RTCWEB Data Channel: message 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, 06 Feb 2014 16:23:03 -0000 On 2/6/14 3:52 AM, Michael Tuexen wrote: > On Feb 6, 2014, at 9:38 AM, Christer Holmberg wrote: > >> Hi, >> >>> If NDATA is not supported, the message size is limited to avoid the monopolization. This limit will be signalled through SDP. >> >> What do you mean by "signaled through SDP"? >> >> Will the browser inform the JS app, using SDP, if the local and/or remote peer doesn't support NDATA? > What will be signalled in SDP is the maximum message size the end-point can handle. This is needed > anyway... If you don't support NDATA, you can signal a smaller value of, let's say 16KB or so. > > NDATA is negotiated via the SCTP setup and there is no need for another signalling channel. > > After the association is up, both sides know if NDATA is supported and, if I remember correctly, > there is a JS way of making message size limits available to the application. So you can > limit the message size if NDATA is not supported by both peers. So that is the plan: > * If NDATA is supported by both peers, message size are only limited by reassembly > memory and any limit is signalled via SDP. The corresponding support will be in the > next revision of the SDP ID. > * If NDATA is not supported by both peers, a message size limit applies to avoid monopolisation. I assume that in the RFC this will just be a MUST NOT. Will that apply to the SCTP implementation? Or to the SCTP user? (In a practical sense, will this be implemented in the SCTP stack, in the DataChannel "stack", in the browser, or in javascript?) Thanks, Paul From pkyzivat@alum.mit.edu Thu Feb 6 08:26: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 13B7C1A03E2 for ; Thu, 6 Feb 2014 08:26:16 -0800 (PST) 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 MtRBinFJew0E for ; Thu, 6 Feb 2014 08:26:15 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 20C071A017B for ; Thu, 6 Feb 2014 08:26:15 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta12.westchester.pa.mail.comcast.net with comcast id P0l51n0040Fqzac5C4SEYW; Thu, 06 Feb 2014 16:26:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id P4SD1n00g3ZTu2S3U4SDqW; Thu, 06 Feb 2014 16:26:14 +0000 Message-ID: <52F3B7A5.6070105@alum.mit.edu> Date: Thu, 06 Feb 2014 11:26:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <4CE22DF8-DE34-400A-95AE-2E011828DE88@lurchi.franken.de> In-Reply-To: <4CE22DF8-DE34-400A-95AE-2E011828DE88@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391703974; bh=l00a2yfZfPCjjNZQ0WndVj+cTIf7CTElUacXvDKcVbk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dr1yMwyjJkw+5s/usO9j3BdEGmYrhR2yKg1RkXEQiipM/My9zZDRfF/jNzR6XJ+ji J0AFLgQL0mbl6WKXImgSFwZ3uHdgnxuWzBch2ci8NFzC3fNeywKkEbp2Ek2jv270bN CI9Tg2uqcigJpG46lG4Dls1UOw+jRHWWIU99WkDhEaGp1l21XKj/UDiOtyp15rkk6j QjYyE8Wihp9IvcPyt0o+fDHmD5sHmcyTyX0LH7a+/p38vEqWnMGthfMVVvcnWsWf6p AHPGMlZHk1Fyzo33yGeTNCNouk0z+IWaIBnmzhjKvtNngG/q7+Vtzk6sHQMIowfOza X4cvGNp5FHVhw== Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 16:26:16 -0000 On 2/6/14 3:45 AM, Michael Tuexen wrote: > On Feb 6, 2014, at 9:36 AM, Christer Holmberg wrote: > >> Hi, >> >>>>> As discussed in the last IETF meeting, this PPID based fragmentation and reassembly will be removed from the ID. >>>> >>>> I assume the associated PPID values will also be un-registered with IANA? >>> I guess they will stay... They are supported by Firefox and PPIDs are a pretty cheap resource. They are from a pool of 32-bit entities. That is why we registered the values before the RFCs get published. >> >> So, does that mean my WebRTC entity has to support them, in case the remote peer is on Firefox? > I don't think so. Not sure what the plan for Firefox is, but I expect Firefox to change the > code as soon as the final solution is specified. >> >> Also, if they are removed from the data channel draft, what reference will be used in the IANA table? > I think it will stay. For PPIDs you even don't have to have an RFC. You can even register PPIDs > as a person. I hope that if values are retained simply for backward compatibility they are explicitly marked as deprecated. Thanks, Paul From Michael.Tuexen@lurchi.franken.de Thu Feb 6 11:17: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 0F35A1A03E4 for ; Thu, 6 Feb 2014 11:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.814 X-Spam-Level: X-Spam-Status: No, score=0.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, MANGLED_AVOID=2.3, RP_MATCHES_RCVD=-0.535, 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 ra6pkLCw7NMp for ; Thu, 6 Feb 2014 11:17:43 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id ACEA91A03F5 for ; Thu, 6 Feb 2014 11:17:42 -0800 (PST) Received: from [192.168.1.200] (p508F14B3.dip0.t-ipconnect.de [80.143.20.179]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 771C51C0E97AF; Thu, 6 Feb 2014 20:17:39 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Thu, 6 Feb 2014 20:17:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> To: "Makaraju, Maridi Raju (Raju)" X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 19:17:45 -0000 On Feb 6, 2014, at 12:45 PM, "Makaraju, Maridi Raju (Raju)" = wrote: >>>>> As discussed in the last IETF meeting, this PPID based = fragmentation and >> reassembly will be removed from the ID. >>>>=20 >>>> I assume the associated PPID values will also be un-registered with = IANA? >>> I guess they will stay... They are supported by Firefox and PPIDs = are a >> pretty cheap resource. They are from a pool of 32-bit entities. That = is why >> we registered the values before the RFCs get published. >>=20 >> So, does that mean my WebRTC entity has to support them, in case the = remote >> peer is on Firefox? >>=20 >> Also, if they are removed from the data channel draft, what reference = will >> be used in the IANA table? >=20 > [Raju] Per my understanding some of the PPIDs are still needed. > The send() API for data channel comes in 4 flavors: > 1. void send (DOMString data); > 2. void send (Blob data); > 3. void send (ArrayBuffer data); > 4. void send (ArrayBufferView data); >=20 > 1 maps to text data > 2,3,4 maps to binary data What is still be needed: WebRTC Control: Used for the DATA_CHANNEL_OPEN and DATA_CHANNEL_ACK = message DOMString Last: Used for 1. Binary Data Last: Used for 2, 3, 4. The PPIDs 'Binary Data Partial' and 'DOMString Partial' won't be used = anymore. These were specific to the PPID based fragmentation and reassembly. >=20 > When one end sends this data one would expect that the other end gets = an onmessage() callback with same (if other end is also javascript) or = similar(if other end is a native client) data structure. I believe this = is achieved by using PPIDs. > We need at least 2 PPIDs: text and binary. So, existing "DOM String = last" (=3D51) and "Binary Data Last"(=3D53) can be used. > To facilitate interworking with native clients I don't think there is = a need to represent all sub-data types of send() in PPIDs as native = client on the other end using C/C++ won't know what "ArrayBufferView" = is?! At least there are no PPIDs for them right now. > Also, I think "DOMString" PPID is too specific to Javascript, instead = it should probably have a generic name like "UTF-16 String". The send = API can still use DOMString as this is Javascript API. Any comments from others? Best regards Michael >=20 > -Raju >=20 From Michael.Tuexen@lurchi.franken.de Thu Feb 6 11:30: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 DD4761A0172 for ; Thu, 6 Feb 2014 11:30:47 -0800 (PST) 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, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535, 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 ex-xmUpvoKMk for ; Thu, 6 Feb 2014 11:30:46 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF111A0473 for ; Thu, 6 Feb 2014 11:30:44 -0800 (PST) Received: from [192.168.1.200] (p508F14B3.dip0.t-ipconnect.de [80.143.20.179]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 085571C0E9729; Thu, 6 Feb 2014 20:30:41 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <52F3B7A5.6070105@alum.mit.edu> Date: Thu, 6 Feb 2014 20:30:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3B7B334C-868A-4128-B7BF-07C66B649443@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <4CE22DF8-DE34-400A-95AE-2E011828DE88@lurchi.franken.de> <52F3B7A5.6070105@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1510) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 19:30:48 -0000 On Feb 6, 2014, at 5:26 PM, Paul Kyzivat wrote: > On 2/6/14 3:45 AM, Michael Tuexen wrote: >> On Feb 6, 2014, at 9:36 AM, Christer Holmberg = wrote: >>=20 >>> Hi, >>>=20 >>>>>> As discussed in the last IETF meeting, this PPID based = fragmentation and reassembly will be removed from the ID. >>>>>=20 >>>>> I assume the associated PPID values will also be un-registered = with IANA? >>>> I guess they will stay... They are supported by Firefox and PPIDs = are a pretty cheap resource. They are from a pool of 32-bit entities. = That is why we registered the values before the RFCs get published. >>>=20 >>> So, does that mean my WebRTC entity has to support them, in case the = remote peer is on Firefox? >> I don't think so. Not sure what the plan for Firefox is, but I expect = Firefox to change the >> code as soon as the final solution is specified. >>>=20 >>> Also, if they are removed from the data channel draft, what = reference will be used in the IANA table? >> I think it will stay. For PPIDs you even don't have to have an RFC. = You can even register PPIDs >> as a person. >=20 > I hope that if values are retained simply for backward compatibility = they are explicitly marked as deprecated. My plan was just not to defined what they are used for... Best regards Michael >=20 > Thanks, > Paul >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From christer.holmberg@ericsson.com Thu Feb 6 11:35: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 0FEC11A0432 for ; Thu, 6 Feb 2014 11:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 hYouI36makxA for ; Thu, 6 Feb 2014 11:35:26 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DC1CF1A0477 for ; Thu, 6 Feb 2014 11:35:25 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-83-52f3e3fbcc04 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 05.52.10875.BF3E3F25; Thu, 6 Feb 2014 20:35:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 20:35:23 +0100 From: Christer Holmberg To: Michael Tuexen , "Makaraju, Maridi Raju (Raju)" Thread-Topic: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing Thread-Index: Ac8jEP4UAFTLik6/TaCDQ1g2OxFaDP//90SA///s4PCAAEsOAIAAfkIAgAAUjQo= Date: Thu, 6 Feb 2014 19:35:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D160906@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@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.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje6fx5+DDH7sY7G42LSE0aJh4xVW i7X/2tkdmD1an+1l9Viy5CeTx4aWHUwBzFFcNimpOZllqUX6dglcGYvb+5gKVjJX/H7Yzt7A eIapi5GTQ0LARGLX///sELaYxIV769m6GLk4hAQOMUpcf/eDEcJZxCjxZdss1i5GDg42AQuJ 7n/aIKaIQJVEa5M6SC+zgLrEncXnwOYIC4RITNt7hhHEFhEIlVh6bQIzhO0ncWBnB9heFgEV iaZXF8HqeQV8Jc52/WWGWHWDSaJp238WkASngKvE3pmLwBoYgY77fmoNE8QycYlbT+ZDPSAg sWTPeWYIW1Ti5eN/YGdKCChJTNuaBlGuI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUWwWkqmz kLTMQtIyC0nLAkaWVYzsuYmZOenlhpsYgVFzcMtv3R2Mp86JHGKU5mBREuf98NY5SEggPbEk NTs1tSC1KL6oNCe1+BAjEwenVAOj97WVC6dNkFmV+S9I2FZ84WRn7Xtrnr2WlFj88b/EsXWP 2jUXhjdOTD39PvJUqI7qdy6LF1Wmsuq7P5ZHej3Yc2mf8GQXsb+bRTY4buX3WHz+m+LipUnW 0/52eG00/snOH6n36sKv8s67kip//hztDZ+6+tQhTZYV9R1tr4/WP7u/La9TNWOygRJLcUai oRZzUXEiACPujUhoAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 19:35:28 -0000 Hi, >> Also, I think "DOMString" PPID is too specific to Javascript, instead it= should probably have a generic name like "UTF-16 String". The send API can= still use DOMString as this is Javascript API. > Any comments from others? I agree that it would be good to use something more generic (e.g. UTF-16 St= ring), as not all entities using this PPID value will be JavaScript based. Regards, Christer From christer.holmberg@ericsson.com Thu Feb 6 11:37: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 B05931A047A for ; Thu, 6 Feb 2014 11:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 FdmLiCjzXA4z for ; Thu, 6 Feb 2014 11:37:42 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BC8A41A0479 for ; Thu, 6 Feb 2014 11:37:40 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-5e-52f3e482674e Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 16.19.23809.284E3F25; Thu, 6 Feb 2014 20:37:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 20:37:38 +0100 From: Christer Holmberg To: Michael Tuexen , Paul Kyzivat Thread-Topic: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing Thread-Index: AQHPI1gvNJfae3lhY0u4MlWMQPDTNpqojGQAgAASM8o= Date: Thu, 6 Feb 2014 19:37:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D160930@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <4CE22DF8-DE34-400A-95AE-2E011828DE88@lurchi.franken.de> <52F3B7A5.6070105@alum.mit.edu>, <3B7B334C-868A-4128-B7BF-07C66B649443@lurchi.franken.de> In-Reply-To: <3B7B334C-868A-4128-B7BF-07C66B649443@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.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+JvjW7Tk89BBuuP2FhcbFrCaLFiwwFW i7X/2tkdmD3+vv/A5LFkyU8mjw0tO5gCmKO4bFJSczLLUov07RK4MpZeucZU8ISpYtfd36wN jDOYuhg5OSQETCRO7u5khLDFJC7cW88GYgsJHGKUeLxet4uRC8hexCix7/J95i5GDg42AQuJ 7n/aIDUiArESlz9vAKtnFlCXuLP4HDuILSwQIvFkaxcbRE2oxM3pP4DmswPZVhLvBUGiLAIq EitXnQO7gFfAV2JL1xw2iE2PmCReT9jFDJLgFHCV+HXuL5jNCHTa91NrmCBWiUvcejIf6nwB iSV7zjND2KISLx//YwW5UkJASWLa1jSIch2JBbs/QV2pLbFs4WtmiL2CEidnPmGZwCg2C8nU WUhaZiFpmYWkZQEjyypG9tzEzJz0cqNNjMCIObjlt+oOxjvnRA4xSnOwKInzfnjrHCQkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qB0fH8yk8stjcMJva/Ttn6TkRtz6GSkrWhsV21S1VV2KO6 5gvtdEh0MHpf4FXvfCxhjrK+VKFzmuth3UP7wiVSF05vcJ4bd+auxDuOXXne2f3nNTnm/lIS sYs2nDrxCfNaI4nrM9pSuXgPyQgt/BTy1OnT7PCs5dO1BbPy8m4x+C639v7L8URAiaU4I9FQ i7moOBEAlVGOAmYCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 19:37:43 -0000 Hi, >> I hope that if values are retained simply for backward compatibility the= y are explicitly marked as deprecated. > My plan was just not to defined what they are used for... I would like to have some explanation text. Having registered values withou= t any kind of explanation is not a good approach, in my opinion. Regards, Christer From Raju.Makaraju@alcatel-lucent.com Thu Feb 6 12:00: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 DA5701A0518 for ; Thu, 6 Feb 2014 12:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 vp68y6_YDQEo for ; Thu, 6 Feb 2014 12:00:38 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 694A71A04F8 for ; Thu, 6 Feb 2014 12:00:31 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s16K0NWx013158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2014 14:00:23 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s16K0MxO030882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 15:00:22 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 6 Feb 2014 15:00:22 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , "Chenxin (Xin)" , Salvatore Loreto Thread-Topic: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? Thread-Index: Ac8cATohOVAlbIwKQYO2t8QqB7DbKv//80KA///u5jCAABV0AP//7Huw//GCr+D/4wMwcP/GAokw/4wAYID/F/v1AP4v9dVQ/F95A/A= Date: Thu, 6 Feb 2014 20:00:21 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D142F0D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D144004@ESESSMB209.ericsson.se> <4B7CB104-BD52-4392-A0B5-4F5C187AA001@ericsson.com> <9E34D50A21D1D1489134B4D770CE0397680AB034@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1D15F323@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D15FC31@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D15FD97@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15FD97@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 20:00:40 -0000 > Is there a reason why we couldn't mandate usage of the same id in the cor= e > spec? Then the correlation would not be dependent on the negotiation > mechanism(s). [Raju] WebRTC does not provide any rules for external negotiation of data c= hannels, so it should leave all the procedures, including stream id managem= ent, outside the scope. Having "symmetric stream id" restriction puts unnec= essary hurdle on external negotiation procedures, which adds no value overa= ll. Like an example app may not care which data channel/stream-id is used f= or send or receive, it just wants to know data is received and sent (the da= ta itself may have some identification info). =20 Btw, the SDP based external negotiation draft http://tools.ietf.org/id/draf= t-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt is already proposing to = use symmetric stream ids. Other external negotiation protocols may put such= restriction as they fit. -Raju From Raju.Makaraju@alcatel-lucent.com Thu Feb 6 12:15: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 59CAE1A0463 for ; Thu, 6 Feb 2014 12:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 4EiFt7gxTx6V for ; Thu, 6 Feb 2014 12:15:20 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 079E11A0469 for ; Thu, 6 Feb 2014 12:15:19 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s16KFHAv010082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2014 14:15:17 -0600 (CST) 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 s16KFGs2002832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 15:15:16 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 6 Feb 2014 15:15:16 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] RTCWEB Data Channel: message interleaving Thread-Index: AQHPIsaGtTtVxkBpl0uo4mWaQvx+DpqnSFawgADrMwCAAAhtgIAAOHlwgAA08KA= Date: Thu, 6 Feb 2014 20:15:16 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> <52F2B457.8040305@alum.mit.edu> <52F2C347.7000304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15EDA7@ESESSMB209.ericsson.se> <6A0518D4-D15D-4970-A56C-87FEDA60F978@lurchi.franken.de> <52F3B6E5.9040001@alum.mit.edu> In-Reply-To: <52F3B6E5.9040001@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [rtcweb] RTCWEB Data Channel: message 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, 06 Feb 2014 20:15:21 -0000 > > * If NDATA is not supported by both peers, a message size limit applies= to > avoid monopolisation. >=20 > I assume that in the RFC this will just be a MUST NOT. Will that apply > to the SCTP implementation? Or to the SCTP user? >=20 > (In a practical sense, will this be implemented in the SCTP stack, in > the DataChannel "stack", in the browser, or in javascript?) [Raju] It has to be done exclusively by the application (Javascript for bro= wser or some other language for native apps). This is because per recent comments the browser/data-channel level fragment= ation/reassembly, based on PPID, will be removed from data channel core spe= c. -Raju From christer.holmberg@ericsson.com Thu Feb 6 12:26: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 6045D1A04D3 for ; Thu, 6 Feb 2014 12:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 GneQtlBMsARm for ; Thu, 6 Feb 2014 12:26:31 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD141A04D9 for ; Thu, 6 Feb 2014 12:26:28 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-ae-52f3eff33bde Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id DF.DE.04853.3FFE3F25; Thu, 6 Feb 2014 21:26:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 21:26:26 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Chenxin (Xin)" , Salvatore Loreto Thread-Topic: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? Thread-Index: Ac8cATohOVAlbIwKQYO2t8QqB7DbKv//80KA///u5jCAABV0AP//7Huw//GCr+D/4wMwcP/GAokw/4wAYID/F/v1AP4v9dVQ/F95A/D4vuqjKg== Date: Thu, 6 Feb 2014 20:26:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D160A63@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D142F0D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D144004@ESESSMB209.ericsson.se> <4B7CB104-BD52-4392-A0B5-4F5C187AA001@ericsson.com> <9E34D50A21D1D1489134B4D770CE0397680AB034@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1D15F323@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D15FC31@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D15FD97@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.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvje7n95+DDCaslbS4eaWX0aJh4xVW i7X/2tkdmD1an+1l9Wg58pbVY8mSn0wBzFFcNimpOZllqUX6dglcGXsO/WQseMdZMfXMFqYG xjaOLkZODgkBE4m2h1vZIWwxiQv31rN1MXJxCAmcYJS4OesqO4SziFGiadcMli5GDg42AQuJ 7n/aIHERgVWMEm++zWcE6WYWUJe4s/gc2CRhgXSJdS3bWEHqRQQyJO5vFQEJiwjUSTxvngFW ziKgIjH1STNYOa+Ar8TB/n3MELvus0ks6HrMBJLgFIiVmHVrIhuIzQh03fdTa5ggdolL3Hoy nwniagGJJXvOM0PYohIvH/8D2yshoCQxbWsaRLmOxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRG sVlIps5C0jILScssJC0LGFlWMUoWpxYX56YbGejlpueW6KUWZSYXF+fn6RWnbmIExtbBLb+N djCe3GN/iFGag0VJnPc6a02QkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsag2DteOWkB35/s 8dDrV/zlaSH8ZUfh1amXq4XWiO+49Dg2/773vhNfeLwn3PWqOuTmGvtY88unpSwz/4tze64P edt25yyH5BvttlrpvkNyu1zZn13wMzwi+XK9yC3fb9dtxXYtk7e7br/+uVl0Aq/4zpI+lcXR 1RltDB/8xX9/uKZmZHctuF+JpTgj0VCLuag4EQBJ6DYpewIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 20:26:32 -0000 Hi, >> Is there a reason why we couldn't mandate usage of the same id in the co= re >> spec? Then the correlation would not be dependent on the negotiation >> mechanism(s). > > [Raju] WebRTC does not provide any rules for external negotiation of data= channels, so it should leave all the procedures, including stream id=20 > management, outside the scope. Having "symmetric stream id" restriction p= uts unnecessary hurdle on external negotiation procedures, which=20 > adds no value overall. Like an example app may not care which data channe= l/stream-id is used for send or receive, it just wants to know data=20 > is received and sent (the data itself may have some identification info). > > Btw, the SDP based external negotiation draft http://tools.ietf.org/id/dr= aft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt is already proposing t= o use symmetric stream ids. Other external negotiation protocols may put su= ch restriction as they fit. So, as far as the data channel mechanism itself is concerned, we do define = that it consists of two uni-directional SCTP streams, but we don't define h= ow those streams are associated with the data channel. For that some extern= al mechanism is needed. Regards, Christer From Michael.Tuexen@lurchi.franken.de Thu Feb 6 12:30: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 D317D1A04D4 for ; Thu, 6 Feb 2014 12:30:57 -0800 (PST) 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, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535, 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 kenm2JxelAIa for ; Thu, 6 Feb 2014 12:30:55 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id A09521A046E for ; Thu, 6 Feb 2014 12:30:54 -0800 (PST) Received: from [192.168.1.200] (p508F14B3.dip0.t-ipconnect.de [80.143.20.179]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EB9E61C0C0BCA; Thu, 6 Feb 2014 21:30:52 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D160930@ESESSMB209.ericsson.se> Date: Thu, 6 Feb 2014 21:30:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <4CE22DF8-DE34-400A-95AE-2E011828DE88@lurchi.franken.de> <52F3B7A5.6070105@alum.mit.edu>, <3B7B334C-868A-4128-B7BF-07C66B649443@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D160930@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 20:30:58 -0000 On Feb 6, 2014, at 8:37 PM, Christer Holmberg = wrote: >=20 > Hi, >=20 >>> I hope that if values are retained simply for backward compatibility = they are explicitly marked as deprecated. >> My plan was just not to defined what they are used for... >=20 > I would like to have some explanation text. Having registered values = without any kind of explanation is not a good approach, in my opinion. The reason why I registered them is that they are used by Firefox and = there was the possibility that the PPID based fragmentation and reassembly got standardised. I wanted to avoid the case that Firefox uses some values and other protocols register these values. That would have been pretty bad. Since they are a very cheap resource, I just went ahead and "saved" the values. Best regards Michael >=20 > Regards, >=20 > Christer >=20 From christer.holmberg@ericsson.com Thu Feb 6 12:35: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 B6AC11A04D8 for ; Thu, 6 Feb 2014 12:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 anoJv1ZesSiK for ; Thu, 6 Feb 2014 12:35:16 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5516F1A0471 for ; Thu, 6 Feb 2014 12:35:16 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-8c-52f3f2021585 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id DC.3F.04853.202F3F25; Thu, 6 Feb 2014 21:35:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 21:35:14 +0100 From: Christer Holmberg To: Michael Tuexen Thread-Topic: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing Thread-Index: AQHPI3pVHEqAXHDepUOzOubNl7HN+Zqoro7q Date: Thu, 6 Feb 2014 20:35:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D160A98@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <4CE22DF8-DE34-400A-95AE-2E011828DE88@lurchi.franken.de> <52F3B7A5.6070105@alum.mit.edu>, <3B7B334C-868A-4128-B7BF-07C66B649443@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D160930@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.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+JvjS7Tp89BBssatS0uNi1htFix4QCr xdp/7ewOzB5/339g8liy5CeTx4aWHUwBzFFcNimpOZllqUX6dglcGTuP3GMvmMxesfboXNYG xousXYycHBICJhJrZ21jhrDFJC7cW8/WxcjFISRwglGiYd4yKGcRo0TfnCYgh4ODTcBCovuf NkiDiICpxMHl81hAbGYBX4kJ37aD2cICIRLT9p5hhKgJlVh6bQIzhG0k0T59EthiFgEViR3b pjCB2LxAvSff72eF2HWfWeJN0zuwZk4BV4mevttgQxmBrvt+ag0TxDJxiVtP5jNBXC0gsWTP eagPRCVePv7HCnKnhICSxLStaRDlOhILdn9ig7C1JZYtfM0MsVdQ4uTMJywTGMVmIZk6C0nL LCQts5C0LGBkWcUoWZxaXJybbmSgl5ueW6KXWpSZXFycn6dXnLqJERhbB7f8NtrBeHKP/SFG aQ4WJXHe66w1QUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY7fYJn6hcvHTSGeMjF+fXmih+ WWO3q+7SD+tFnjUReleXZ+yybuzumGR+dlbE3Ovr5gp6+dgYR5wOfvbp/SRvh22NRhPCdNcI XXsU9GSDueBWnU/LP4ZNKM/3KGNf2umzvOOP9K/nfWs4bTZYCbxcO0X+gF/KOrv4kqcdYZ6+ x9VOuxwP4BTeqMRSnJFoqMVcVJwIAKnf6DB7AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 20:35:17 -0000 Hi, >>>> I hope that if values are retained simply for backward compatibility t= hey are explicitly marked as deprecated. >>> My plan was just not to defined what they are used for... >> >> I would like to have some explanation text. Having registered values wit= hout any kind of explanation is not a good approach, in my opinion. > The reason why I registered them is that they are used by Firefox and the= re was > the possibility that the PPID based fragmentation and reassembly got > standardised. I wanted to avoid the case that Firefox uses some values > and other protocols register these values. That would have been pretty > bad. Since they are a very cheap resource, I just went ahead and "saved" > the values. That is a all good. But, when people wonder 5 years from now, I don't want = them to have to look for this e-mail in oder to get an explanation :) Regards, Christer From juberti@gmail.com Thu Feb 6 11:56: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 2FE4E1A03FF for ; Thu, 6 Feb 2014 11:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 zZVtu418qy-G for ; Thu, 6 Feb 2014 11:56:14 -0800 (PST) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 99C711A03ED for ; Thu, 6 Feb 2014 11:56:14 -0800 (PST) Received: by mail-ee0-f53.google.com with SMTP id t10so1105961eei.26 for ; Thu, 06 Feb 2014 11:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=EAEVVUto/UxfvYNzsM6SyvYN/bK0xbCvGgUS6X+rB0M=; b=zyCjKkeOk0ye3HSBY/qO4xUZQp4TODE9h0FFTClNsLj0ktpZqd5YRcbma7I37muJxw 275EWLVWfzAEaXqUZTSmeDRJSJ+j9TzmzN1IYvR9ugWqTsm6V78vCJYh+OXlKVldOQKY 3tDJLeBkGsNP5sRiSfyYqyRonDgvtZOGF0wrD+2fQuKKlnOKOU3TIRucX0RJHvIpUmiP 1m27yw2Xw6qqT/NIuTN9K11o2raH93uYyYe60xNnrR821OwYZS3AYfbbcgL1004enI3Z NmUoYwfWpUtfWw6Oe8ZK+QLaZ3OM29Cq18GBDKWQ329Saz/ANqtAVej16fTczYpn2zrn H2Bg== X-Received: by 10.14.3.72 with SMTP id 48mr11457271eeg.34.1391716573028; Thu, 06 Feb 2014 11:56:13 -0800 (PST) MIME-Version: 1.0 Sender: juberti@gmail.com Received: by 10.14.0.199 with HTTP; Thu, 6 Feb 2014 11:55:52 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Thu, 6 Feb 2014 11:55:52 -0800 X-Google-Sender-Auth: VqyhS0nHOZG9Rw5Fxlz3NQl7zlU Message-ID: To: Rachel Dvori , rtcweb@ietf.org Content-Type: multipart/alternative; boundary=047d7b670311f6a51804f1c243cd X-Mailman-Approved-At: Thu, 06 Feb 2014 12:37:01 -0800 Subject: Re: [rtcweb] ice-lite in 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: Thu, 06 Feb 2014 19:56:16 -0000 --047d7b670311f6a51804f1c243cd Content-Type: text/plain; charset=ISO-8859-1 +rtcweb WebRTC endpoints must implement full ICE. Legacy (non-WebRTC) endpoints can use ICE Lite, but as mentioned in RFC5245, S 2.7, full ICE is preferred. On Tue, Jan 21, 2014 at 10:50 AM, Rachel Dvori wrote: > draft-ietf-rtcweb-jsep@tools.ietf.org > > > > > > Dear Person, > > > > I have seen the below in the draft of: > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-05 > > > > Attributes other than the ones specified above MAY be included, > > except for the following attributes which are specifically > > incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage], > > and *MUST NOT* be included: > > > > o "a=crypto" > > o "a=key-mgmt" > > o "*a=ice-lite*" > > > > > > But in draft of : > http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-11 > > There is no phrase that prevents a WebRTC user to be ice-lite > > > > > > Can you pls clarify: > > - Where is it mentioned that ice-lite cannot be one of the > participants of WebRTC > > - What is the reason that no side can be ice-lite (as if one > side is full-ice, there is still STUN and connectivity checks etc. > > > > Thanks > > RD > > > > p.s. - what is the correct email address for this type of questions ? > (Thanks and sorry) > > > --047d7b670311f6a51804f1c243cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+rtcweb

WebRTC endpoints must imp= lement full ICE. Legacy (non-WebRTC) endpoints can use ICE Lite, but as men= tioned in RFC5245, S 2.7, full ICE is preferred.


On Tue, Jan 21, 2014 at 10:50 AM, Rachel= Dvori <rachel.dvori@gmail.com> wrote:

draft-ietf-= rtcweb-jsep@tools.ietf.org

=A0

=A0

Dear Person,

=A0

I have seen the below in the= draft of:=A0 =A0http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-= 05

=A0

Attributes other than the on= es specified above MAY be included,

except for the following att= ributes which are specifically

incompatible with the requir= ements of [I-D.ietf-rtcweb-rtp-usage],

and MUST NOT be inclu= ded:

=A0

o=A0 "a=3Dcrypto"

o=A0 "a=3Dkey-mgmt"

o=A0 "a=3Dice-lite"

=A0

=A0

But in draft of : =A0http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-11=A0

There is no phrase that prev= ents a WebRTC user to be ice-lite

=A0

=A0

Can you pls clarify:

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Where is it mentioned that ice-lite cannot be one of the participants of WebRTC

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 What is the reason that no side can be ice-lite=A0 (as if one side is full-ice, there is still STUN and connectivity checks etc.

=A0

Thanks

RD

=A0

p.s. - what is the correct email address for th= is type of questions ? =A0(Thanks and sorry)



--047d7b670311f6a51804f1c243cd-- From Michael.Tuexen@lurchi.franken.de Thu Feb 6 12:47: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 197D71A0487 for ; Thu, 6 Feb 2014 12:47:15 -0800 (PST) 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, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535, 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 OrIxsSKCpgT4 for ; Thu, 6 Feb 2014 12:47:13 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE981A01E6 for ; Thu, 6 Feb 2014 12:47:13 -0800 (PST) Received: from [192.168.1.200] (p508F14B3.dip0.t-ipconnect.de [80.143.20.179]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 817E61C0E970C; Thu, 6 Feb 2014 21:47:11 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D160A98@ESESSMB209.ericsson.se> Date: Thu, 6 Feb 2014 21:47:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <75145993-7226-4C5D-845C-A96D51D3D68B@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <4CE22DF8-DE34-400A-95AE-2E011828DE88@lurchi.franken.de> <52F3B7A5.6070105@alum.mit.edu>, <3B7B334C-868A-4128-B7BF-07C66B649443@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D160930@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D160A98@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 20:47:15 -0000 On Feb 6, 2014, at 9:35 PM, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>> I hope that if values are retained simply for backward = compatibility they are explicitly marked as deprecated. >>>> My plan was just not to defined what they are used for... >>>=20 >>> I would like to have some explanation text. Having registered values = without any kind of explanation is not a good approach, in my opinion. >> The reason why I registered them is that they are used by Firefox and = there was >> the possibility that the PPID based fragmentation and reassembly got >> standardised. I wanted to avoid the case that Firefox uses some = values >> and other protocols register these values. That would have been = pretty >> bad. Since they are a very cheap resource, I just went ahead and = "saved" >> the values. >=20 > That is a all good. But, when people wonder 5 years from now, I don't = want them to have to look for this e-mail in oder to get an explanation = :) Understood. But do you think they walk through the IANA registry? I = would expect them to read RFCs and follow the procedures described there. Best regards Michael >=20 > Regards, >=20 > Christer >=20 >=20 From harald@alvestrand.no Thu Feb 6 15:18: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 E125B1A0426 for ; Thu, 6 Feb 2014 15:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 4lIi_vT2UmLq for ; Thu, 6 Feb 2014 15:18:12 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8D91A04C8 for ; Thu, 6 Feb 2014 15:18:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id CBD6E7C4A9D for ; Fri, 7 Feb 2014 00:18:10 +0100 (CET) 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 1rZ4tAPmLDEb for ; Fri, 7 Feb 2014 00:18:10 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4A8DB7C4A53 for ; Fri, 7 Feb 2014 00:18:10 +0100 (CET) Message-ID: <52F4182F.60404@alvestrand.no> Date: Fri, 07 Feb 2014 00:18:07 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 23:18:15 -0000 On 02/06/2014 08:17 PM, Michael Tuexen wrote: >> Also, I think "DOMString" PPID is too specific to Javascript, instead it should probably have a generic name like "UTF-16 String". The send API can still use DOMString as this is Javascript API. > Any comments from others? Note: The WebSockets protocol defines the transferred strings as UTF-8. http://tools.ietf.org/html/rfc6455#section-5.6 As far as I can tell, we've always intended to follow that example. The fact that Javascript implementations currently choose to represent text strings as UTF-16 at their API is sad, but not an argument for sending that particular text representation over the wire, or reflecting the name in the API. -- Surveillance is pervasive. Go Dark. From harald@alvestrand.no Thu Feb 6 15:20: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 F41811A0511 for ; Thu, 6 Feb 2014 15:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] 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 Lb8CtkrMr3vD for ; Thu, 6 Feb 2014 15:20:01 -0800 (PST) Received: from mork.alvestrand.no (unknown [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id EFCEA1A0426 for ; Thu, 6 Feb 2014 15:20:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 3F8BC7C4A9D for ; Fri, 7 Feb 2014 00:19:59 +0100 (CET) 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 xwa8R315Gc27 for ; Fri, 7 Feb 2014 00:19:59 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id A04BD7C4A53 for ; Fri, 7 Feb 2014 00:19:58 +0100 (CET) Message-ID: <52F4189B.3020309@alvestrand.no> Date: Fri, 07 Feb 2014 00:19:55 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <4CE22DF8-DE34-400A-95AE-2E011828DE88@lurchi.franken.de> <52F3B7A5.6070105@alum.mit.edu>, <3B7B334C-868A-4128-B7BF-07C66B649443@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D160930@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D160A98@ESESSMB209.ericsson.se> <75145993-7226-4C5D-845C-A96D51D3D68B@lurchi.franken.de> In-Reply-To: <75145993-7226-4C5D-845C-A96D51D3D68B@lurchi.franken.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 06 Feb 2014 23:20:02 -0000 On 02/06/2014 09:47 PM, Michael Tuexen wrote: > On Feb 6, 2014, at 9:35 PM, Christer Holmberg wrote: > >> Hi, >> >>>>>> I hope that if values are retained simply for backward compatibility they are explicitly marked as deprecated. >>>>> My plan was just not to defined what they are used for... >>>> I would like to have some explanation text. Having registered values without any kind of explanation is not a good approach, in my opinion. >>> The reason why I registered them is that they are used by Firefox and there was >>> the possibility that the PPID based fragmentation and reassembly got >>> standardised. I wanted to avoid the case that Firefox uses some values >>> and other protocols register these values. That would have been pretty >>> bad. Since they are a very cheap resource, I just went ahead and "saved" >>> the values. >> That is a all good. But, when people wonder 5 years from now, I don't want them to have to look for this e-mail in oder to get an explanation :) > Understood. But do you think they walk through the IANA registry? I would expect them > to read RFCs and follow the procedures described there. Updating the registry to read "Obsolete; was used by " should satisfy all comers. People do read registries. From weichen2@cisco.com Thu Feb 6 17:56: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 4B9C31A0598 for ; Thu, 6 Feb 2014 17:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.535, 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 tb0gVK1xa25t for ; Thu, 6 Feb 2014 17:56:44 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C42E81A0587 for ; Thu, 6 Feb 2014 17:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2222; q=dns/txt; s=iport; t=1391738204; x=1392947804; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=v37/s7TOl/lSDuPDtKz/vzodav+10nwc/DUFt1/UKpY=; b=QCqdjLJnLjDmPtvrhCTNlHSlcHeH23z0MFOwtnP25vnobKbIJcyBaXJo Y7gvcE7VGmxeckQ/hfR+TNWyQPTH+OZKXHz3VED/w5B8krrR/nKDMQLUR Q45Kwu+kisfWZZiDH3u3H9mCZetveoM5+JbigRO3aMLlhx2Guj7YEURGy Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAAA99FKtJV2c/2dsb2JhbABZgww4V4MBu3cYdxZ0giUBAQEEIxFVAgEGAhEEAQEDAgYdAwICAh8RFAEICAIEARIIh2kDEQ2QFZt9mA8NiGoXgSmLO4E0EQEfOIJvNYEUAQOWP4MeiyyFQ4MtgXE5 X-IronPort-AV: E=Sophos;i="4.95,797,1384300800"; d="scan'208";a="302439569" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 07 Feb 2014 01:56:43 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s171uhSG032042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 01:56:43 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.201]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 19:56:42 -0600 From: "Wilson Chen (weichen2)" To: Justin Uberti , Rachel Dvori , "rtcweb@ietf.org" Thread-Topic: [rtcweb] ice-lite in WebRTC ??? Thread-Index: AQHPI3s2hX15LOCWGkythRPnivQAYZqpBjBg Date: Fri, 7 Feb 2014 01:56:43 +0000 Message-ID: <3A5DAAA1FDD9764EAA3B2A633A91A0495F8B49D5@xmb-aln-x15.cisco.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.140.48.196] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [rtcweb] ice-lite in 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: Fri, 07 Feb 2014 01:56:46 -0000 SW4gY2FzZSBvZiBuZWdvdGlhdGluZyB3aXRoIHNlcnZlciAobWF5IGJlIGEgZ2F0ZXdheSksIElN SE8sIHRoZSBzZXJ2ZXIgd291bGQgbGlrZSBub3QgdG8gZG8gY29ubmVjdGl2aXR5IGNoZWNrLCBp dCBpcyBzaW1wbGVyIGFuZCBmYXN0ZXIgdG8gd29yayBpbiBpY2UtbGl0ZSBhbmQgcGFzc2l2ZSBt b2RlLg0KDQpUaGFua3MsDQpXaWxzb24gQ2hlbg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IDIw MTTlubQy5pyIN+aXpSAzOjU2DQpUbzogUmFjaGVsIER2b3JpOyBydGN3ZWJAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbcnRjd2ViXSBpY2UtbGl0ZSBpbiBXZWJSVEMgPz8/DQoNCitydGN3ZWINCg0K V2ViUlRDIGVuZHBvaW50cyBtdXN0IGltcGxlbWVudCBmdWxsIElDRS4gTGVnYWN5IChub24tV2Vi UlRDKSBlbmRwb2ludHMgY2FuIHVzZSBJQ0UgTGl0ZSwgYnV0IGFzIG1lbnRpb25lZCBpbiBSRkM1 MjQ1LCBTIDIuNywgZnVsbCBJQ0UgaXMgcHJlZmVycmVkLg0KDQpPbiBUdWUsIEphbiAyMSwgMjAx NCBhdCAxMDo1MCBBTSwgUmFjaGVsIER2b3JpIDxyYWNoZWwuZHZvcmlAZ21haWwuY29tPiB3cm90 ZToNCmRyYWZ0LWlldGYtcnRjd2ViLWpzZXBAdG9vbHMuaWV0Zi5vcmcNCsKgDQrCoA0KRGVhciBQ ZXJzb24sDQrCoA0KSSBoYXZlIHNlZW4gdGhlIGJlbG93IGluIHRoZSBkcmFmdCBvZjrCoCDCoGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLWpzZXAtMDUNCsKgDQpB dHRyaWJ1dGVzIG90aGVyIHRoYW4gdGhlIG9uZXMgc3BlY2lmaWVkIGFib3ZlIE1BWSBiZSBpbmNs dWRlZCwNCmV4Y2VwdCBmb3IgdGhlIGZvbGxvd2luZyBhdHRyaWJ1dGVzIHdoaWNoIGFyZSBzcGVj aWZpY2FsbHkNCmluY29tcGF0aWJsZSB3aXRoIHRoZSByZXF1aXJlbWVudHMgb2YgW0ktRC5pZXRm LXJ0Y3dlYi1ydHAtdXNhZ2VdLA0KYW5kIE1VU1QgTk9UIGJlIGluY2x1ZGVkOg0KwqANCm/CoCAi YT1jcnlwdG8iDQpvwqAgImE9a2V5LW1nbXQiDQpvwqAgImE9aWNlLWxpdGUiDQrCoA0KwqANCkJ1 dCBpbiBkcmFmdCBvZiA6IMKgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1y dGN3ZWItcnRwLXVzYWdlLTExwqAgDQpUaGVyZSBpcyBubyBwaHJhc2UgdGhhdCBwcmV2ZW50cyBh IFdlYlJUQyB1c2VyIHRvIGJlIGljZS1saXRlDQrCoA0KwqANCkNhbiB5b3UgcGxzIGNsYXJpZnk6 DQotwqDCoMKgwqDCoMKgwqDCoMKgIFdoZXJlIGlzIGl0IG1lbnRpb25lZCB0aGF0IGljZS1saXRl IGNhbm5vdCBiZSBvbmUgb2YgdGhlIHBhcnRpY2lwYW50cyBvZiBXZWJSVEMNCi3CoMKgwqDCoMKg wqDCoMKgwqAgV2hhdCBpcyB0aGUgcmVhc29uIHRoYXQgbm8gc2lkZSBjYW4gYmUgaWNlLWxpdGXC oCAoYXMgaWYgb25lIHNpZGUgaXMgZnVsbC1pY2UsIHRoZXJlIGlzIHN0aWxsIFNUVU4gYW5kIGNv bm5lY3Rpdml0eSBjaGVja3MgZXRjLg0KwqANClRoYW5rcw0KUkQNCsKgDQpwLnMuIC0gd2hhdCBp cyB0aGUgY29ycmVjdCBlbWFpbCBhZGRyZXNzIGZvciB0aGlzIHR5cGUgb2YgcXVlc3Rpb25zID8g wqAoVGhhbmtzIGFuZCBzb3JyeSkNCg0KDQo= From harald@alvestrand.no Thu Feb 6 17:59: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 C13B11A058F for ; Thu, 6 Feb 2014 17:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] 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 u13RvnnVo6-R for ; Thu, 6 Feb 2014 17:59:19 -0800 (PST) Received: from mork.alvestrand.no (unknown [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4D51A0587 for ; Thu, 6 Feb 2014 17:59:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B524A7C4ACF for ; Fri, 7 Feb 2014 02:59:17 +0100 (CET) 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 bVe75VzAELrf for ; Fri, 7 Feb 2014 02:59:17 +0100 (CET) Received: from [10.1.1.234] (64-71-23-98.static.wiline.com [64.71.23.98]) by mork.alvestrand.no (Postfix) with ESMTPSA id 39D017C4ACB for ; Fri, 7 Feb 2014 02:59:17 +0100 (CET) Message-ID: <52F43DF3.1020401@alvestrand.no> Date: Fri, 07 Feb 2014 02:59:15 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <3A5DAAA1FDD9764EAA3B2A633A91A0495F8B49D5@xmb-aln-x15.cisco.com> In-Reply-To: <3A5DAAA1FDD9764EAA3B2A633A91A0495F8B49D5@xmb-aln-x15.cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] ice-lite in 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: Fri, 07 Feb 2014 01:59:22 -0000 On 02/07/2014 02:56 AM, Wilson Chen (weichen2) wrote: > In case of negotiating with server (may be a gateway), IMHO, the server would like not to do connectivity check, it is simpler and faster to work in ice-lite and passive mode. The server doesn't have to claim WebRTC conformance, it just has to claim to interoperate with WebRTC endpoints. > > Thanks, > Wilson Chen > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti > Sent: 2014年2月7日 3:56 > To: Rachel Dvori; rtcweb@ietf.org > Subject: Re: [rtcweb] ice-lite in WebRTC ??? > > +rtcweb > > WebRTC endpoints must implement full ICE. Legacy (non-WebRTC) endpoints can use ICE Lite, but as mentioned in RFC5245, S 2.7, full ICE is preferred. > > On Tue, Jan 21, 2014 at 10:50 AM, Rachel Dvori wrote: > draft-ietf-rtcweb-jsep@tools.ietf.org > > > Dear Person, > > I have seen the below in the draft of: http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-05 > > Attributes other than the ones specified above MAY be included, > except for the following attributes which are specifically > incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage], > and MUST NOT be included: > > o "a=crypto" > o "a=key-mgmt" > o "a=ice-lite" > > > But in draft of : http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-11 > There is no phrase that prevents a WebRTC user to be ice-lite > > > Can you pls clarify: > - Where is it mentioned that ice-lite cannot be one of the participants of WebRTC > - What is the reason that no side can be ice-lite (as if one side is full-ice, there is still STUN and connectivity checks etc. > > Thanks > RD > > p.s. - what is the correct email address for this type of questions ? (Thanks and sorry) > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From juberti@google.com Thu Feb 6 22:40: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 64F4D1A05B3 for ; Thu, 6 Feb 2014 22:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 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, RP_MATCHES_RCVD=-0.535, 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 J_GWv0RsOv8C for ; Thu, 6 Feb 2014 22:40:57 -0800 (PST) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 02EC91A05B0 for ; Thu, 6 Feb 2014 22:40:56 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id p14so2325486vbm.11 for ; Thu, 06 Feb 2014 22:40:55 -0800 (PST) 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=YUbH8pIRepQhZtEKGtFoUq53ooyF4iLtfO7AMmktZZY=; b=P4UhAK16guX8r/zCehvNZFHECVOeUwDgnJkRNoMmdsyI/9Nagdh1+Z663Fo8kNe7WJ 5LrmIu8G9RK0+aLpJqxRg+Ey76mB5tISu6TudamFLWGHO998OkUwzanQ1bJlx/AhDeXi JUjh02dxyVYmpZVHV3Qj9PJ4OKjgBGgM0wOFSbLfOAiKNaT+4lhul9GYw2TnS1IAS9H9 QTkx0krXOzISuB3NhMDJuV4vbDsPGJO2UQwBNGn9r5Tps/AaMnzm0DoROT/Ms4jLviYw ysXMSn1cBJhPSwldrBe1fmyNwa0LW2d90Uj6+F2zDb8P/UHJRTXfxqH3dPryaedk3987 dWCQ== 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=YUbH8pIRepQhZtEKGtFoUq53ooyF4iLtfO7AMmktZZY=; b=AWDc2m74rn8URAAVo402cifjyXF7+Gw7Nk26Xj5QMJHFDuTT4oE5FlVu+yPuSm0nsI D8qCwNcd7ZZmG4bpZYAJ7k+C/pymiLldPD5k/psrFNPXDH43t4nrk4GEhWGcovnwS8aF 7nd4fRCFGqzN3zHEIf3raR0pKaydAqMtrjQmFkCb37Eyv1VjuM+CtrLNpyAIRgT43Kky JwPISsxionZOCMrfaJIaYv9uUXwa60cQGc2a3jpzPErd1OSBsCrPny4rBOX1ktEkFpIX 8QpqBmkA4fZb8aBGIbobYZgJYSvRRTMjpao/ga88wQLeXI5/iFNwqQasalzKww7noTY8 vgxw== X-Gm-Message-State: ALoCoQkyZXuSKWD0OjWn/InvsmjXCS5auhbJa/fhXqZsFcrQ0ZqiVK0TaoT0KbFkJpXRCS5HAMGv7FrgL5JOtKnaq5S+4YtXIkaX6jPoUA5URcN7omGeDcQcZNuIGnjTYxHILKTeMDcbMafsJf3WYYyd/sxU9mL0foUKFLDaQpxV8+EQEfxgMdEBP8oOjNmDNPf8ExhnR8Ke X-Received: by 10.52.232.168 with SMTP id tp8mr144693vdc.38.1391755255425; Thu, 06 Feb 2014 22:40:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Thu, 6 Feb 2014 22:40:35 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> <52F2B457.8040305@alum.mit.edu> <52F2C347.7000304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15EDA7@ESESSMB209.ericsson.se> <6A0518D4-D15D-4970-A56C-87FEDA60F978@lurchi.franken.de> <52F3B6E5.9040001@alum.mit.edu> From: Justin Uberti Date: Thu, 6 Feb 2014 22:40:35 -0800 Message-ID: To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=089e01183a009d495704f1cb45e0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Data Channel: message 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, 07 Feb 2014 06:40:59 -0000 --089e01183a009d495704f1cb45e0 Content-Type: text/plain; charset=UTF-8 The browser will enforce the message limit to ensure predictable behavior. On Thu, Feb 6, 2014 at 12:15 PM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > > > * If NDATA is not supported by both peers, a message size limit > applies to > > avoid monopolisation. > > > > I assume that in the RFC this will just be a MUST NOT. Will that apply > > to the SCTP implementation? Or to the SCTP user? > > > > (In a practical sense, will this be implemented in the SCTP stack, in > > the DataChannel "stack", in the browser, or in javascript?) > > [Raju] It has to be done exclusively by the application (Javascript for > browser or some other language for native apps). > This is because per recent comments the browser/data-channel level > fragmentation/reassembly, based on PPID, will be removed from data channel > core spec. > > -Raju > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e01183a009d495704f1cb45e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The browser will enforce the message limit to ensure predi= ctable behavior.


On Thu, Feb 6, 2014 at 12:15 PM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:
> > * If NDATA is no= t supported by both peers, a message size limit applies to
> avoid monopolisation.
>
> I assume that in the RFC this will just be a MUST NOT. Will that apply=
> to the SCTP implementation? Or to the SCTP user?
>
> (In a practical sense, will this be implemented in the SCTP stack, in<= br> > the DataChannel "stack", in the browser, or in javascript?)<= br>
[Raju] It has to be done exclusively by the application (Javascript f= or browser or some other language for native apps).
This is because per recent comments the browser/data-channel level fragment= ation/reassembly, based on PPID, will be removed from data channel core spe= c.

-Raju
_____________________= __________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--089e01183a009d495704f1cb45e0-- From christer.holmberg@ericsson.com Thu Feb 6 23:27: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 593F21A05B7 for ; Thu, 6 Feb 2014 23:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 y6TUBH8Fi_Ij for ; Thu, 6 Feb 2014 23:27:51 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4701A05AC for ; Thu, 6 Feb 2014 23:27:50 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-48-52f48af4ef82 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1C.3B.10875.4FA84F25; Fri, 7 Feb 2014 08:27:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0387.000; Fri, 7 Feb 2014 08:27:48 +0100 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing Thread-Index: AQHPI5H4g+NNW9fTlk27SCBTz5+sApqpZO9Q Date: Fri, 7 Feb 2014 07:27:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16131F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <4CE22DF8-DE34-400A-95AE-2E011828DE88@lurchi.franken.de> <52F3B7A5.6070105@alum.mit.edu>, <3B7B334C-868A-4128-B7BF-07C66B649443@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D160930@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D160A98@ESESSMB209.ericsson.se> <75145993-7226-4C5D-845C-A96D51D3D68B@lurchi.franken.de> <52F4189B.3020309@alvestrand.no> In-Reply-To: <52F4189B.3020309@alvestrand.no> 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+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje6Xri9BBocnG1kc6+tis1j7r53d gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4PaONteAEZ8Xz67vYGxgvs3cxcnJICJhI XHt2hRXCFpO4cG89WxcjF4eQwCFGiZ6VLYwQziJGia1n3gFVcXCwCVhIdP/TBmkQEQiW6H3+ nhHEFhYIkXiytYsNIh4qcXP6D0aQchEBI4nVrbUgYRYBFYn2uffBdvEK+Eoc+/2bGWJ8O6vE sWPNYL2cAroSTd/ugs1kBDro+6k1TCA2s4C4xK0n85kgDhWQWLLnPDOELSrx8vE/qAcUJdqf NjBC1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVI3tuYmZO ernhJkZgLBzc8lt3B+OpcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wKinGbtyAVscf+A7x6BjXF/0dcRWuMz+Xnr3jPflCdazGKM3xptV8RbzbfN65CO8s4Hno2ri 3GD9KZfYo2LD6984OdxsXrXcy9zrjcZZoYMpoppnylnOZvBqXzJ3a7t7IFmtJbRtz0N23oy+ 53MCOgPb9xaGvb7whJWtbQqv8JQ5HOtf+iR+UGIpzkg01GIuKk4EAE3FGWZTAgAA Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 07 Feb 2014 07:27:52 -0000 >>>>>>> I hope that if values are retained simply for backward compatibilit= y they are explicitly marked as deprecated. >>>>>> My plan was just not to defined what they are used for... >>>>> I would like to have some explanation text. Having registered values = without any kind of explanation is not a good approach, in my opinion. >>>> The reason why I registered them is that they are used by Firefox=20 >>>> and there was the possibility that the PPID based fragmentation and=20 >>>> reassembly got standardised. I wanted to avoid the case that Firefox=20 >>>> uses some values and other protocols register these values. That=20 >>>> would have been pretty bad. Since they are a very cheap resource, I ju= st went ahead and "saved" >>>> the values. >>> That is a all good. But, when people wonder 5 years from now, I don't=20 >>> want them to have to look for this e-mail in oder to get an=20 >>> explanation :) >> Understood. But do you think they walk through the IANA registry? I=20 >> would expect them to read RFCs and follow the procedures described there= . > > Updating the registry to read "Obsolete; was used by " > should satisfy all comers. + 1 Regards, Christer From partha@parthasarathi.co.in Fri Feb 7 08:26: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 F338E1A0594 for ; Fri, 7 Feb 2014 08:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.633 X-Spam-Level: X-Spam-Status: No, score=0.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MANGLED_NOTICE=2.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 TAoOZ9mWqPya for ; Fri, 7 Feb 2014 08:26:31 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.234]) by ietfa.amsl.com (Postfix) with ESMTP id 25F3F1A01AF for ; Fri, 7 Feb 2014 08:26:30 -0800 (PST) Received: from userPC (unknown [122.172.233.98]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 9AFBE6393CA; Fri, 7 Feb 2014 16:26:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1391790390; bh=+ydpS3PqMF1ovlsqycF4CJbcWCqs0Lqh0HR9itbuKqI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=XW4r0IJupS+mupGyUEPFySqb7DAtNHa645GsIecWsmHdQnIJVk0b+rdw2rFHyfTMF Ovc8SbHfPJ7oCarDZpG8lT1TFFLZbDf7T+Q+Ir1bVEGVbxfVxeDKSsBzU5eoKZiV/W GrsJmUBOHxM0ET/RVJVNibsk8V0ZAmOTj3sxI1AE= From: "Parthasarathi R" To: "'Harald Alvestrand'" , References: <3A5DAAA1FDD9764EAA3B2A633A91A0495F8B49D5@xmb-aln-x15.cisco.com> <52F43DF3.1020401@alvestrand.no> In-Reply-To: <52F43DF3.1020401@alvestrand.no> Date: Fri, 7 Feb 2014 21:56:20 +0530 Message-ID: <007401cf2421$58729a20$0957ce60$@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: Ac8jqDsYBgme9EtATBae9l+sMeXBlQAd3aMw Content-Language: en-us X-CTCH-RefID: str=0001.0A020208.52F50936.0130, 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 70.87.28.142 Subject: Re: [rtcweb] ice-lite in 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: Fri, 07 Feb 2014 16:26:33 -0000 > The server doesn't have to claim WebRTC conformance, it just = has to > claim to interoperate with WebRTC endpoints. The above assumption leads to lot of confusion in WebRTC Server = implementation which starts from RTCWeb requirement itself. IMO, it is = better to provide the minimum IETF standard guidelines for WebRTC = servers like ice-lite/ICE, BUNDLE required or not, ICE-TCP/TURN.=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald > Alvestrand > Sent: Friday, February 07, 2014 7:29 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] ice-lite in WebRTC ??? >=20 > On 02/07/2014 02:56 AM, Wilson Chen (weichen2) wrote: > > In case of negotiating with server (may be a gateway), IMHO, the > server would like not to do connectivity check, it is simpler and > faster to work in ice-lite and passive mode. >=20 > The server doesn't have to claim WebRTC conformance, it just has to > claim to interoperate with WebRTC endpoints. >=20 > > > > Thanks, > > Wilson Chen > > > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin > Uberti > > Sent: 2014=E5=B9=B42=E6=9C=887=E6=97=A5 3:56 > > To: Rachel Dvori; rtcweb@ietf.org > > Subject: Re: [rtcweb] ice-lite in WebRTC ??? > > > > +rtcweb > > > > WebRTC endpoints must implement full ICE. Legacy (non-WebRTC) > endpoints can use ICE Lite, but as mentioned in RFC5245, S 2.7, full > ICE is preferred. > > > > On Tue, Jan 21, 2014 at 10:50 AM, Rachel Dvori > wrote: > > draft-ietf-rtcweb-jsep@tools.ietf.org > > > > > > Dear Person, > > > > I have seen the below in the draft of: > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-05 > > > > Attributes other than the ones specified above MAY be included, > > except for the following attributes which are specifically > > incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage], > > and MUST NOT be included: > > > > o "a=3Dcrypto" > > o "a=3Dkey-mgmt" > > o "a=3Dice-lite" > > > > > > But in draft of : http://tools.ietf.org/html/draft-ietf-rtcweb-rtp- > usage-11 > > There is no phrase that prevents a WebRTC user to be ice-lite > > > > > > Can you pls clarify: > > - Where is it mentioned that ice-lite cannot be one of the > participants of WebRTC > > - What is the reason that no side can be ice-lite (as if > one side is full-ice, there is still STUN and connectivity checks etc. > > > > Thanks > > RD > > > > p.s. - what is the correct email address for this type of questions = ? > (Thanks and sorry) > > > > > > _______________________________________________ > > 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 From partha@parthasarathi.co.in Fri Feb 7 08:39: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 87E5D1A01B9 for ; Fri, 7 Feb 2014 08:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.996 X-Spam-Level: *** X-Spam-Status: No, score=3.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_84=0.6, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793, 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 zcWAMAbcvDtW for ; Fri, 7 Feb 2014 08:39:39 -0800 (PST) Received: from smtp.mailhostbox.com (unknown [162.222.225.11]) by ietfa.amsl.com (Postfix) with ESMTP id 30D781A0177 for ; Fri, 7 Feb 2014 08:39:37 -0800 (PST) Received: from userPC (unknown [122.172.233.98]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 46CB31908880; Fri, 7 Feb 2014 16:39:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1391791177; bh=2JxcUZNzTAL0RdAo3F/UTTqnFO1xTWbwXBiHBC33/LA=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=UYM5eecGXumzjLgLfIPTxMBjk4tXOlpwZWRy258dd2xSzR0qePGm/E/kV/bbdYHnD cGsqff/6tXmiXWfhg6Vd054MIT5uuCGq8bpjJ/2OyD+T36dtXwh1l17eURZuAeoAnf UF+Yfi4Alb4VnaUdZasR/QbM9zG6/Ku1DJdlrClY= From: "Parthasarathi R" To: =?iso-8859-1?Q?'Stefan_H=E5kansson_LK'?= , References: <1447FA0C20ED5147A1AA0EF02890A64B1CF4A182@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1CF4A182@ESESSMB209.ericsson.se> Date: Fri, 7 Feb 2014 22:09:27 +0530 Message-ID: <007601cf2423$2d571210$88053630$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8jKZAtHwyyT87MQ3ivvr7TXBW1mAA+H4FQ Content-Language: en-us X-CTCH-RefID: str=0001.0A020201.52F50C49.013D, 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 70.87.28.138 Subject: Re: [rtcweb] New version of use-case draft uploaded X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 07 Feb 2014 16:39:42 -0000 Hi Stefan, Simon proposed the following text after the lengthy mailing discussion: > "Note that TURN support being mandatory does not preclude a WebRTC=20 > endpoint from supporting additional traversal mechanisms." Whereas Sec 3.3.4.1 updated as=20 "Note that ICE support being mandatory does not preclude a WebRTC endpoint from supporting additional traversal mechanisms." Apart from this, Tiru (http://www.ietf.org/mail-archive/web/rtcweb/current/msg11246.html) and myself = (http://www.ietf.org/mail-archive/web/rtcweb/current/msg11241.html) mentioned in the different mail thread that Sec 3.3.4.1 is not only the right place to put the above text. Could you please correct the F31, F32 requirement text in the next revision of the draft. Thanks Partha > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan > H=E5kansson LK > Sent: Thursday, February 06, 2014 4:23 PM > To: rtcweb@ietf.org > Subject: [rtcweb] New version of use-case draft uploaded >=20 > Hi, >=20 > I've uploaded a new version -13 [1]. I have made changes based on = input > from Mary, Magnus and Chenxing+Andy, for details read further down. >=20 > I hope I have caught most things; what remains to my knowledge is: > * Include the requirement text the first time a requirement is derived > * Group (and re-number) the claims >=20 > I am hesitating to do the last thing 'cause of the risk of getting all > internal references into a mess, but one day soon I will feel brave > enough :-) >=20 > Stefan >=20 > [1] > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and- > requirements/ >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > On 2014-01-15 21:57, Mary Barnes wrote: > > I had thought I had previously done a detailed review of this doc, > but > I can't find it to know whether changes suggested have been > incorporated. So, I have re-reviewed the document and I think it's > almost ready to progress. I think it needs some editorial > clarifications > and nits to be fixed as summarized below. Note, I did not review the > appendix. > > Regards, > > Mary. > > In general, I still find the style of this document very difficult = to > grok since the requirements are not grouped in categories and one has > to > keep switching back and forth in the document to match requirements to > use cases. > > Questions/Comments for clarification: > > ---------------------------------------------------- > > 1) Section 1, 1st paragraph, last sentence. It's not clear to me = that > "e.g., a telephone" is meaningful. I don't think you're intending to > interworking with a legacy PSTN connected black phone. So, it might be > more accurate to say " e.g., a mobile phone or a SIP UA". >=20 > Changed. >=20 > > 2) Section 3.3.1.1. Next to last paragraph. I'm not sure what you > mean > by different "makes". I think you mean different types of devices > (e.g., > mobile, SIP UA, etc. ). That all said, I don't think that's not so > relevant. I think simply stating different OSs and different browsers > is > sufficient. >=20 > Changed. >=20 > > 3) Section 3.3.6.1. It's not at all clear to me why this requirement > is considered specific to WebRTC. I would think the access network > changes should be transparent to WebRTC. Certainly, the device needs = to > know what's happening, but I think whether this works is entirely = based > on the internals of the device and the specific access network > technology, and not WebRTC application. >=20 > It is not WebRTC specific per se, but is important for the use-case. > What parts that solve it is of less importance IMO. >=20 > > 4) Section 3.3.10.1. Why is F24 not considered an additional > requirement here? Also, do you not need to have a statement as to what > other use case is the basis for this one such that the core > requirements > are reference? >=20 > I added F24 (it belongs here). I don't think we need a statement > regarding the basis, it is covered in section 3.2 >=20 > > 5) Section 3.3.11.1, 2nd paragraph, 1st sentence. I don't understand > what this is trying to say. What is meant by "enhance = intelligibility"? > And, what is meant by "pans the audio from different participants > differently when rendering the audio". > > [As an aside, I will note that some of the CLUE use cases likely > encompass what you are trying to communicate here in this requirements > (including subsequent paragraphs and the last "Note:"), so you may = want > to look at those and use similar terminology and concepts, that CLUE > spent a lot of time developing. ] >=20 > I updated (using similar terminology to Clue). >=20 > > 6) Section 3.4. I would expect F27 to be referenced by at least one > of > these use cases. >=20 > I added it to 3.4.1 >=20 > > 7) Section 4.2. > > - General: I am a bit confused as there are requirements in this > section that aren't referenced in section 3, including F19, F23, and > F27 > . Perhaps, that's because there are some missing references in section > 3 > (see item 7)? If not, then why are they there. At a minimum you should > add a sentence to section 4.1 indicating that not all the requirements > are derived from the use cases (contrary to what is currently stated). >=20 > F19 has been removed. I added ref to F23 (and F24!) from ues-case > "multi-party game with voice communication". Ref to F27 added to = 3.4.1. >=20 > > - What's the difference between F24 and F34? >=20 > I don't know, and I removed F34 >=20 > > - F30. I had to read this several times to understand it due to > structure. I would suggest changing as follows: > > OLD: > > F30 The browser must be able to use the screen (or > > a specific area of the screen) or what a certain > > application displays on the screen to generate > > streams. > > NEW: > > F30 The browser must be able to generate streams using the entire > user > display, a specific area of the user's display or the information = being > displayed by a specific application. >=20 > Updated. >=20 > > On this one, I also think it would be good to clarify what type of > stream - are you talking about using protocol to share content or or = is > this just a video stream? Or would you have two separate requirement = to > cover both of these? >=20 > I would like to avoid going into detail; the idea is that it is some > kind of "stream" that allows sharing what is rendered on your screen, > the requirement does not need to go into what kind it is. >=20 > > - F32. I can't quite grok this one. Maybe you are trying to say > something like the following? > > OLD: > > F32 There browser must support that STUN and TURN > > servers to use are supplied by other entities > > than via the web application (i.e. the network > > provider). > > NEW: > > F32 The browser must support the use of STUN and TURN > > servers that are supplied by entities > > other than the web application (i.e. the network > > provider). >=20 > Updated. >=20 > > 8) Section 7. I have mixed feelings about leaving this list with = URLs > in the document. I think it's good to highlight the use cases that > weren't incorporated and why they weren't. I think it would add a lot > more value to provide a concise summary of the reasons they weren't > added than just including links, in particular, since we usually don't > like to publish RFCs with links. >=20 > I think the entire list should go before publication. The list has = been > kept there as a reminder of what we included and what we did not > included. I have removed it in this version. >=20 > > Nits: > > ------ > > 1) Section 1, 1st paragraph, last sentence, "at least one of the > end-user client" -> "at least one of the end-user clients" > > 2) Section 3.2, 1st paragraph, 1st sentence: > > - "retrives" -> "retrieves" > > - add a section reference for "Simple Video Communication Service" > > 3) Section 3.2. , next to last sentence. "retrieved from" -> = "derived > from" > > 4) Section 3.3.5.1, 3rd paragraph, > > - 1st sentence. "session" - "session" > > - 2nd sentence. "straddle the boundary between the internal network > and external." -> "straddles the boundary between the internal and > external networks. > > 5) Section 3.3.5.1, 4th paragraph. "they still want to have the > traffic to stay" -> "they still want the traffic to say" > > 6) Section 3.3.61. 1st paragraph. I'm not sure why this ends with = ":" > > 7) Section 3.3.6.1, 2nd paragraph. "device used by one of the users > have several" -> "device used by one of the users has several" > > 8) Section 3.3.11.1, 1st para, 1st sentence. "In this use case is = the > Simple..." -> "In this use case, the Simple...." > > 9) Section 3.3.11.1 3rd from last paragraph. "use experience" -> > "user > experience" > > 10) Section 3.4.3.1, 2nd paragraph. "participant send" -> > "participant > sends" > > 11) Section 4.2: > > - F35. "of that streams" -> "that streams" >=20 > Most Nit's fixed >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > On 2014-01-29 10:29, Magnus Westerlund wrote: > > Hi Partha and WG, > > > > I don't see any support for the changes you proposes in this > discussion. > > What I see some support for is to add a statement making clear that > > there might be additional NAT/Firewall traversal mechanisms than > > STUN/TURN. Simon proposed: > > > > "Note that TURN support being mandatory does not preclude a WebRTC > > endpoint from supporting additional traversal mechanisms." >=20 > I added this to section 3.3.4.1 >=20 > > > > > > However, looking at the document as it is currently written, I am > > uncertain where this would be added. The first mention of TURN is in > > Section 3.3.4.1, and that section is focused on the global service > > provider perspective and the need for location based provisioning of > > NAT/Firewall traversal server resources. > > > > I think it can be added to Section 3.3.5.1 without being misplaced, > but > > it would be given a slightly narrower scope. > > > > I any of you want to be more explicit where this should be included, > > please be. If you are not forthcoming I will request the authors to > add > > this in what they consider sensible position. > > > > Cheers > > > > Magnus > > > > > > On 2014-01-25 17:46, Parthasarathi R wrote: > >> Hi Simon, > >> > >> > >> > >> Thanks for your understanding about my firewall/NAT related problem > >> statement in this draft. > >> > >> > >> > >> I have proposed the firewall/NAT related text by which the specific > >> mechanism is not highlighted in the requirement document as there = is > no > >> WG consensus for any of the mechanism including TURN. It is = possible > to > >> argue hypothetically in PNTAW alias that PCP is the only mechanism > >> required in WebRTC endpoint. Also, I=92m more interested in WebRTC > >> gateway/server (Sec 4.3. of > >> draft-ietf-rtcweb-use-cases-and-requirements-12) requirements > wherein it > >> is not required to support TURN and the related mail thread is > >> http://www.ietf.org/mail-archive/web/pntaw/current/msg00181.html. > >> > >> > >> > >> IMO, my proposed text without mentioning any firewall/NAT mechanism > in > >> the requirement document helps to move forward without depend on = the > >> solution discussion in PNTAW alias. > >> > >> > >> > >> Thanks > >> > >> Partha > >> > >> > >> > >> *From:*Cb B [mailto:cb.list6@gmail.com] > >> *Sent:* Saturday, January 25, 2014 6:22 AM > >> *To:* Simon Perreault > >> *Cc:* rtcweb@ietf.org; Parthasarathi R > >> *Subject:* Re: [rtcweb] Query/Comment on > >> draft-ietf-rtcweb-use-cases-and-requirements-12 > >> > >> > >> > >> > >> On Jan 24, 2014 10:17 AM, "Simon Perreault" > >> > wrote: > >>> > >>> Le 2014-01-24 12:14, Parthasarathi R a =E9crit : > >>> > >>>> Please note that when non-IETFers read this requirement document, > >> they come > >>>> to the conclusion that IETF RTCWeb WG recommends TURN and not > other > >>>> mechanisms. I'm saying that requirement document should not be > used > >> as the > >>>> mechanism to eliminate the other alternatives when there is a > discussion > >>>> going-on in PNTAW alias. So, I'm asking for the change. > >>> > >>> > >>> I would totally agree with that sentiment, although I don't see > your > >> proposed text change reflecting it accurately. How about simply: > >>> > >>> "Note that TURN support being mandatory does not preclude a WebRTC > >> endpoint from supporting additional traversal mechanisms." > >>> > >>> > >> > >> +1 for the above text. > >> > >> CB > >> > >>> Simon > >>> -- > >>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca > >>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > >>> STUN/TURN server --> http://numb.viagenie.ca > >>> _______________________________________________ > >>> rtcweb mailing 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 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > On 2014-01-16 15:18, Hutton, Andrew wrote: > > Some comments in the text below. > > > > As a general comment I suggest changing all the "FW" abbreviations = to > "Firewall" are have at least a first use definition. >=20 > Done >=20 > > > > > > Andy > > > > > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: 15 January 2014 10:20 > >> To: Chenxin (Xin); Hutton, Andrew; Christer Holmberg; Parthasarathi > R; > >> rtcweb@ietf.org > >> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases- > and- > >> requirements-12 > >> > >> WG, > >> > >> It has been quite some time since the WG last call ended and a new > >> revision was submitted. As Document Shepherd I want to push this > >> document to publication request. > >> > >> Chenxin proposed below three different sets of changes to the > document. > >> Does the WG support making these changes? Please indicate within = the > >> next week if you support or want to reject these changes. > >> > >> Thanks > >> > >> Magnus > >> > >> > >> On 2013-10-17 12:23, Chenxin (Xin) wrote: > >>> Hi Andy, > >>> > >>> > >>> > >>> I think you means F29 not F27:). When I read it , I realize that > >> there > >>> is cross and ambiguous between 3.3.2 and 3.3.3 > >>> > >>> > >>> > >>> More details: > >>> > >>> > >>> > >>> The topic of 3.3.2 is "Simple Video Communication Service, = *NAT/FW* > >>> that blocks UDP". But in the description and requirement, only > *NAT* > >> is > >>> considered. > >>> > >>> The topic of 3.3.3 is "Simple Video Communication Service, FW that > >>> only allows http", But only *http proxy* deployed scenarios is > >> considered. > >>> > >>> > >>> > >>> There are other usecases " FW block UDP, incoming TCP, Http > >> allowing > >>> FW without http proxy deplolyed under the permission of FW policy" > , > >>> which is lost in the description. If we need consider these > usecases > >> , I > >>> suggest to make some change to the description. > >>> > >>> > >>> > >>> Proposal 1 : > >>> > >>> > >>> > >>> add FW related words to section 3.3.2 > >>> > >>> ------------------------------------------------- > >>> > >>> 3.3.2. Simple Video Communication Service, NAT/FW that blocks UDP > >>> > >>> > >>> > >>> 3.3.2.1. Description > >>> > >>> > >>> > >>> This use-case is almost identical to the Simple Video > >> Communication > >>> > >>> Service use-case (Section 3.3.1). The difference is that one of > >> the > >>> > >>> users is behind a NAT*/FW* that blocks UDP traffic. > >>> > >>> . > > > > [AndyH] - I support this change. >=20 > Changed >=20 > > > > > >>> > >>> > >>> > >>> 3.3.2.2. Additional Requirements > >>> > >>> > >>> > >>> F29 The browser must be able to send streams and > >>> > >>> data to a peer in the presence of NATs *and FWs* that > >>> > >>> block UDP traffic ,* when FW policy allows WebRTC > >> traffic*. > > > > [AndyH] - I support this change. >=20 > Changed >=20 > > > > > >>> > >>> ------------------------------------------------------- > >>> > >>> Proposal 2: If the" Http allowing FW without http proxy deployed" > >>> case is impliedly included in F29. I suggest to change the topics > of > >>> 3.3.3 to "Simple Video Communication Service, FW that only allows > >>> traffic via a http proxy". So the 3.3.3 is a specific case. > >>> > > > > [AndyH] Yes the heading of 3.3.3 should have been changed during the > last edit to "Simple Video Communication Service, FW that only allows > traffic via a HTTP Proxy". I support this change. >=20 > Changed. >=20 > > > > > >>> > >>> > >>> Proposal 3: If " Http allowing FW without http proxy deployed" > >> case > >>> need to be explicitly mentioned. I suggest to add some = descriptions > >> to 3.3.3 > >>> > >>> ----------------------------------------------------------------- > >>> > >>> 3.3.3. Simple Video Communication Service, FW that only allows = http > >>> > >>> > >>> > >>> 3.3.3.1. Description > >>> > >>> > >>> > >>> This use-case is almost identical to the Simple Video > >> Communication > >>> > >>> Service use-case (Section 3.3.1). The difference is that one of > >> the > >>> > >>> users is behind a http allowing FW or a FW that only allows > >> traffic > >>> via a HTTP Proxy. > >>> > >>> > > > > [AndyH] I don't believe the intention here was to state a = requirement > that WebRTC media should be able to flow through a FW only allowing > HTTP. Therefore I think the original description is ok it is just the > heading that needs to change. > > > > > >>> > >>> 3.3.3.2. Additional Requirements > >>> > >>> > >>> > >>> F37 The browser must be able to send streams and > >>> > >>> data to a peer in the presence of http allowing FWs or FWs > >>> that only > >>> > >>> allows traffic via a HTTP Proxy, when FW policy > >>> > >>> allows WebRTC traffic. > >>> > > > > [AndyH] The existing text is in the 012 draft is ok and I don't = think > this change is needed as again I don't believe the intention here was > to > state a requirement that WebRTC media should be able to flow through a > FW only allowing HTTP. > > > > > >>> = ------------------------------------------------------------------- > >>> > >>> > > > >>> > >>> > >>> > >>> Best Regards, > >>> > >>> Xin > >>> > >>> > >>> > >> > >> > >> -- > >> > >> Magnus Westerlund > >> > >> = -------------------------------------------------------------------- > -- > >> Services, Media and Network features, Ericsson Research EAB/TXM > >> = -------------------------------------------------------------------- > -- > >> Ericsson AB | Phone +46 10 7148287 > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden | mailto: = magnus.westerlund@ericsson.com > >> = -------------------------------------------------------------------- > -- > > > > _______________________________________________ > > 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 ted.ietf@gmail.com Fri Feb 7 09:01: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 E08671ACB4E for ; Fri, 7 Feb 2014 09:01:44 -0800 (PST) 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 9tizG-YnwbGt for ; Fri, 7 Feb 2014 09:01:43 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6D57A1A0500 for ; Fri, 7 Feb 2014 09:01:43 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id uq10so2300522igb.2 for ; Fri, 07 Feb 2014 09:01:43 -0800 (PST) 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=F9SnGFwu21RN0sAmWNPgyZ5ELbq7qB++tl4UYq0IOgE=; b=pU4bsCAzLQbv+QYxupAoe9VFOxv01Ltls1vAp0ScuYLVFcqmOxQcExx+Foo17koyKS OSnZe9wtSDmsYTZ7vmuNhOqJDKXLNWPlQTkLLMds7qB2zXprdUkMFhFw2lfGTNA0owJ0 2xzjlfydKJhcpgIii1IQuXd8BNKHXq39K0aE4aKgmSb6JojHmf0nB/UFXQT3X1ohdn/f 9xceFTbCEVLkh3fLBkXIX2TM1lI27JPkEe6nztjjyA7C4+LCUG1yIkRTLC30T1KVSVlB 17LZ5kWA6vha2brpFYmH+APwMxgUJ/tq5U3tohCIlnBXTgOVRQADHao+yp220jg7GbIc 19iw== MIME-Version: 1.0 X-Received: by 10.50.159.194 with SMTP id xe2mr946472igb.13.1391792503279; Fri, 07 Feb 2014 09:01:43 -0800 (PST) Received: by 10.43.164.201 with HTTP; Fri, 7 Feb 2014 09:01:43 -0800 (PST) Date: Fri, 7 Feb 2014 09:01:43 -0800 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=14dae93405f9c2572a04f1d3f176 Subject: [rtcweb] "SCTP New Data Chunk" review requested X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 07 Feb 2014 17:01:45 -0000 --14dae93405f9c2572a04f1d3f176 Content-Type: text/plain; charset=ISO-8859-1 I'm not sure how large the cross-over is between tsvwg and rtcweb, so I'd like to highlight that the tsvwg version of this draft has now been uploaded: http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ Reviews of the document for tsvwg would be great, as they have an aggressive deadline for pushing the document to the IESG (early Summer). thanks, Ted (for the Chairs) --14dae93405f9c2572a04f1d3f176 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm not sure how large the cross-over is between tsvwg and rtcwe= b, so I'd like to highlight that the tsvwg version of this draft has no= w been uploaded:

http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/

<= /div>
Revie= ws of the document for tsvwg would be great, as they have an aggressive dea= dline for pushing the document to the IESG (early Summer).

thanks,

Ted (for the Chairs)
--14dae93405f9c2572a04f1d3f176-- From harald@alvestrand.no Fri Feb 7 10:04: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 9D9F81AC7F2 for ; Fri, 7 Feb 2014 10:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.135 X-Spam-Level: X-Spam-Status: No, score=-0.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NOTICE=2.3, RP_MATCHES_RCVD=-0.535] 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 lWUaEKBLdXag for ; Fri, 7 Feb 2014 10:04:10 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id C7F671A03E1 for ; Fri, 7 Feb 2014 10:04:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 446DA7C4B20; Fri, 7 Feb 2014 19:04:09 +0100 (CET) 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 Uy08W86Tv45i; Fri, 7 Feb 2014 19:04:09 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id 812047C4B1F; Fri, 7 Feb 2014 19:04:08 +0100 (CET) Message-ID: <52F52016.2060703@alvestrand.no> Date: Fri, 07 Feb 2014 19:04:06 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Parthasarathi R , rtcweb@ietf.org References: <3A5DAAA1FDD9764EAA3B2A633A91A0495F8B49D5@xmb-aln-x15.cisco.com> <52F43DF3.1020401@alvestrand.no> <007401cf2421$58729a20$0957ce60$@co.in> In-Reply-To: <007401cf2421$58729a20$0957ce60$@co.in> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] ice-lite in 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: Fri, 07 Feb 2014 18:04:11 -0000 On 02/07/2014 05:26 PM, Parthasarathi R wrote: > > The server doesn't have to claim WebRTC conformance, it just has to >> claim to interoperate with WebRTC endpoints. > The above assumption leads to lot of confusion in WebRTC Server implementation which starts from RTCWeb requirement itself. IMO, it is better to provide the minimum IETF standard guidelines for WebRTC servers like ice-lite/ICE, BUNDLE required or not, ICE-TCP/TURN. It seems to me like a good document to write, but should probably be done after we finish the requirements for WebRTC endpoints. Unless someone wishes to start one, of course. From stefan.lk.hakansson@ericsson.com Fri Feb 7 10:29: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 BBEE81A03E1 for ; Fri, 7 Feb 2014 10:29:06 -0800 (PST) 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, J_CHICKENPOX_84=0.6, MANGLED_LIST=2.3, 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 Qks1wlJxDEZs for ; Fri, 7 Feb 2014 10:29:04 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1F01B1A019E for ; Fri, 7 Feb 2014 10:29:02 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-76-52f525ed8e7c Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 05.35.04249.DE525F25; Fri, 7 Feb 2014 19:29:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Fri, 7 Feb 2014 19:29:01 +0100 From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?= To: Parthasarathi R , "rtcweb@ietf.org" Thread-Topic: [rtcweb] New version of use-case draft uploaded Thread-Index: Ac8jKZAtHwyyT87MQ3ivvr7TXBW1mA== Date: Fri, 7 Feb 2014 18:29:01 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CF533B8@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1CF4A182@ESESSMB209.ericsson.se> <007601cf2423$2d571210$88053630$@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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvje471a9BBvdqLCZ/6mO1WPuvnd2B yWPJkp9MHh/mf2EPYIrisklJzcksSy3St0vgylj3poe94PMmxoqLHa9YGhgXT2HsYuTkkBAw kZj0aDsbhC0mceHeeiCbi0NI4AijxPM/s8ASQgKLGCVebXXsYuTgYBMIlmj66wYSFhEIl3jz /DIziC0sYCPx78Ipdoi4rcS/mf8YIWw9iXsrN4PVsAioSKxfNIkRZAyvgK/Emu+mENPLJebN PQzWygh0wvdTa5hAbGYBcYlbT+YzQZwmILFkz3lmCFtU4uXjf6wQtpJE45InrBD1BhLvz81n hrC1JZYtfA1m8woISpyc+YRlAqPILCRjZyFpmYWkZRaSlgWMLKsYOYpTi5Ny040MNjECQ/7g lt8WOxgv/7U5xCjNwaIkzvvxrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkYzGee1T8z3 zbRYc5u7at2/H+dCfWUdL7/SXHxX7Pkpv2d3RT3e77+wyfn7jw93L/EXa7V9OX2kznC1hFnb BdtfVxZMKVed+0N5inLVXiZfQ/3PH763CRxe6X8x7ZmCd+6D2dFLlr+zufN0mZxCconPDma9 ffMiF11cOUf0WYldzZHjJ73+vK+OUmIpzkg01GIuKk4EAM1IwVhHAgAA Subject: Re: [rtcweb] New version of use-case draft uploaded X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 07 Feb 2014 18:29:06 -0000 Hi Partha!=0A= =0A= On 2014-02-07 17:39, Parthasarathi R wrote:=0A= > Hi Stefan,=0A= >=0A= > Simon proposed the following text after the lengthy mailing discussion:= =0A= >=0A= >> "Note that TURN support being mandatory does not preclude a WebRTC =0A= >> endpoint from supporting additional traversal mechanisms."=0A= > Whereas Sec 3.3.4.1 updated as =0A= >=0A= > "Note that ICE support being mandatory does not preclude a WebRTC=0A= > endpoint from supporting additional traversal mechanisms."=0A= =0A= Yes, I did that change (TURN -> ICE). My understanding was that ICE is=0A= what is used/mandated (and it in turn makes use of STUN and TURN).=0A= =0A= >=0A= > Apart from this, Tiru=0A= > (http://www.ietf.org/mail-archive/web/rtcweb/current/msg11246.html) and= =0A= > myself (http://www.ietf.org/mail-archive/web/rtcweb/current/msg11241.html= )=0A= > mentioned in the different mail thread that Sec 3.3.4.1 is not only the= =0A= > right place to put the above text. Could you please correct the F31, F32= =0A= > requirement text in the next revision of the draft.=0A= =0A= I can update them to what you propose. But I think it is a little bit=0A= silly. If we add that note, then we should probably add to F28 "The=0A= browser must support a baseline audio and video codec" a note saying=0A= "this does not preclude the browser from supporting additional codecs"=0A= and so on. After all, the requirements are meant to be what must be=0A= supported; they do not say that additions are not allowed.=0A= =0A= >=0A= > Thanks=0A= > Partha=0A= >=0A= >> -----Original Message-----=0A= >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan=0A= >> H=E5kansson LK=0A= >> Sent: Thursday, February 06, 2014 4:23 PM=0A= >> To: rtcweb@ietf.org=0A= >> Subject: [rtcweb] New version of use-case draft uploaded=0A= >>=0A= >> Hi,=0A= >>=0A= >> I've uploaded a new version -13 [1]. I have made changes based on input= =0A= >> from Mary, Magnus and Chenxing+Andy, for details read further down.=0A= >>=0A= >> I hope I have caught most things; what remains to my knowledge is:=0A= >> * Include the requirement text the first time a requirement is derived= =0A= >> * Group (and re-number) the claims=0A= >>=0A= >> I am hesitating to do the last thing 'cause of the risk of getting all= =0A= >> internal references into a mess, but one day soon I will feel brave=0A= >> enough :-)=0A= >>=0A= >> Stefan=0A= >>=0A= >> [1]=0A= >> http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-=0A= >> requirements/=0A= >>=0A= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= >> On 2014-01-15 21:57, Mary Barnes wrote:=0A= >>> I had thought I had previously done a detailed review of this doc,=0A= >> but=0A= >> I can't find it to know whether changes suggested have been=0A= >> incorporated. So, I have re-reviewed the document and I think it's=0A= >> almost ready to progress. I think it needs some editorial=0A= >> clarifications=0A= >> and nits to be fixed as summarized below. Note, I did not review the=0A= >> appendix.=0A= >>> Regards,=0A= >>> Mary.=0A= >>> In general, I still find the style of this document very difficult to= =0A= >> grok since the requirements are not grouped in categories and one has=0A= >> to=0A= >> keep switching back and forth in the document to match requirements to= =0A= >> use cases.=0A= >>> Questions/Comments for clarification:=0A= >>> ----------------------------------------------------=0A= >>> 1) Section 1, 1st paragraph, last sentence. It's not clear to me that= =0A= >> "e.g., a telephone" is meaningful. I don't think you're intending to=0A= >> interworking with a legacy PSTN connected black phone. So, it might be= =0A= >> more accurate to say " e.g., a mobile phone or a SIP UA".=0A= >>=0A= >> Changed.=0A= >>=0A= >>> 2) Section 3.3.1.1. Next to last paragraph. I'm not sure what you=0A= >> mean=0A= >> by different "makes". I think you mean different types of devices=0A= >> (e.g.,=0A= >> mobile, SIP UA, etc. ). That all said, I don't think that's not so=0A= >> relevant. I think simply stating different OSs and different browsers=0A= >> is=0A= >> sufficient.=0A= >>=0A= >> Changed.=0A= >>=0A= >>> 3) Section 3.3.6.1. It's not at all clear to me why this requirement=0A= >> is considered specific to WebRTC. I would think the access network=0A= >> changes should be transparent to WebRTC. Certainly, the device needs to= =0A= >> know what's happening, but I think whether this works is entirely based= =0A= >> on the internals of the device and the specific access network=0A= >> technology, and not WebRTC application.=0A= >>=0A= >> It is not WebRTC specific per se, but is important for the use-case.=0A= >> What parts that solve it is of less importance IMO.=0A= >>=0A= >>> 4) Section 3.3.10.1. Why is F24 not considered an additional=0A= >> requirement here? Also, do you not need to have a statement as to what= =0A= >> other use case is the basis for this one such that the core=0A= >> requirements=0A= >> are reference?=0A= >>=0A= >> I added F24 (it belongs here). I don't think we need a statement=0A= >> regarding the basis, it is covered in section 3.2=0A= >>=0A= >>> 5) Section 3.3.11.1, 2nd paragraph, 1st sentence. I don't understand=0A= >> what this is trying to say. What is meant by "enhance intelligibility"?= =0A= >> And, what is meant by "pans the audio from different participants=0A= >> differently when rendering the audio".=0A= >>> [As an aside, I will note that some of the CLUE use cases likely=0A= >> encompass what you are trying to communicate here in this requirements= =0A= >> (including subsequent paragraphs and the last "Note:"), so you may want= =0A= >> to look at those and use similar terminology and concepts, that CLUE=0A= >> spent a lot of time developing. ]=0A= >>=0A= >> I updated (using similar terminology to Clue).=0A= >>=0A= >>> 6) Section 3.4. I would expect F27 to be referenced by at least one=0A= >> of=0A= >> these use cases.=0A= >>=0A= >> I added it to 3.4.1=0A= >>=0A= >>> 7) Section 4.2.=0A= >>> - General: I am a bit confused as there are requirements in this=0A= >> section that aren't referenced in section 3, including F19, F23, and=0A= >> F27=0A= >> . Perhaps, that's because there are some missing references in section= =0A= >> 3=0A= >> (see item 7)? If not, then why are they there. At a minimum you should= =0A= >> add a sentence to section 4.1 indicating that not all the requirements= =0A= >> are derived from the use cases (contrary to what is currently stated).= =0A= >>=0A= >> F19 has been removed. I added ref to F23 (and F24!) from ues-case=0A= >> "multi-party game with voice communication". Ref to F27 added to 3.4.1.= =0A= >>=0A= >>> - What's the difference between F24 and F34?=0A= >> I don't know, and I removed F34=0A= >>=0A= >>> - F30. I had to read this several times to understand it due to=0A= >> structure. I would suggest changing as follows:=0A= >>> OLD:=0A= >>> F30 The browser must be able to use the screen (or=0A= >>> a specific area of the screen) or what a certain=0A= >>> application displays on the screen to generate=0A= >>> streams.=0A= >>> NEW:=0A= >>> F30 The browser must be able to generate streams using the entire=0A= >> user=0A= >> display, a specific area of the user's display or the information being= =0A= >> displayed by a specific application.=0A= >>=0A= >> Updated.=0A= >>=0A= >>> On this one, I also think it would be good to clarify what type of=0A= >> stream - are you talking about using protocol to share content or or is= =0A= >> this just a video stream? Or would you have two separate requirement to= =0A= >> cover both of these?=0A= >>=0A= >> I would like to avoid going into detail; the idea is that it is some=0A= >> kind of "stream" that allows sharing what is rendered on your screen,=0A= >> the requirement does not need to go into what kind it is.=0A= >>=0A= >>> - F32. I can't quite grok this one. Maybe you are trying to say=0A= >> something like the following?=0A= >>> OLD:=0A= >>> F32 There browser must support that STUN and TURN=0A= >>> servers to use are supplied by other entities=0A= >>> than via the web application (i.e. the network=0A= >>> provider).=0A= >>> NEW:=0A= >>> F32 The browser must support the use of STUN and TURN=0A= >>> servers that are supplied by entities=0A= >>> other than the web application (i.e. the network=0A= >>> provider).=0A= >> Updated.=0A= >>=0A= >>> 8) Section 7. I have mixed feelings about leaving this list with URLs= =0A= >> in the document. I think it's good to highlight the use cases that=0A= >> weren't incorporated and why they weren't. I think it would add a lot=0A= >> more value to provide a concise summary of the reasons they weren't=0A= >> added than just including links, in particular, since we usually don't= =0A= >> like to publish RFCs with links.=0A= >>=0A= >> I think the entire list should go before publication. The list has been= =0A= >> kept there as a reminder of what we included and what we did not=0A= >> included. I have removed it in this version.=0A= >>=0A= >>> Nits:=0A= >>> ------=0A= >>> 1) Section 1, 1st paragraph, last sentence, "at least one of the=0A= >> end-user client" -> "at least one of the end-user clients"=0A= >>> 2) Section 3.2, 1st paragraph, 1st sentence:=0A= >>> - "retrives" -> "retrieves"=0A= >>> - add a section reference for "Simple Video Communication Service"=0A= >>> 3) Section 3.2. , next to last sentence. "retrieved from" -> "derived= =0A= >> from"=0A= >>> 4) Section 3.3.5.1, 3rd paragraph,=0A= >>> - 1st sentence. "session" - "session"=0A= >>> - 2nd sentence. "straddle the boundary between the internal network=0A= >> and external." -> "straddles the boundary between the internal and=0A= >> external networks.=0A= >>> 5) Section 3.3.5.1, 4th paragraph. "they still want to have the=0A= >> traffic to stay" -> "they still want the traffic to say"=0A= >>> 6) Section 3.3.61. 1st paragraph. I'm not sure why this ends with ":"= =0A= >>> 7) Section 3.3.6.1, 2nd paragraph. "device used by one of the users=0A= >> have several" -> "device used by one of the users has several"=0A= >>> 8) Section 3.3.11.1, 1st para, 1st sentence. "In this use case is the= =0A= >> Simple..." -> "In this use case, the Simple...."=0A= >>> 9) Section 3.3.11.1 3rd from last paragraph. "use experience" ->=0A= >> "user=0A= >> experience"=0A= >>> 10) Section 3.4.3.1, 2nd paragraph. "participant send" ->=0A= >> "participant=0A= >> sends"=0A= >>> 11) Section 4.2:=0A= >>> - F35. "of that streams" -> "that streams"=0A= >> Most Nit's fixed=0A= >>=0A= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= >>=0A= >>=0A= >> On 2014-01-29 10:29, Magnus Westerlund wrote:=0A= >>> Hi Partha and WG,=0A= >>>=0A= >>> I don't see any support for the changes you proposes in this=0A= >> discussion.=0A= >>> What I see some support for is to add a statement making clear that=0A= >>> there might be additional NAT/Firewall traversal mechanisms than=0A= >>> STUN/TURN. Simon proposed:=0A= >>>=0A= >>> "Note that TURN support being mandatory does not preclude a WebRTC=0A= >>> endpoint from supporting additional traversal mechanisms."=0A= >> I added this to section 3.3.4.1=0A= >>=0A= >>>=0A= >>> However, looking at the document as it is currently written, I am=0A= >>> uncertain where this would be added. The first mention of TURN is in=0A= >>> Section 3.3.4.1, and that section is focused on the global service=0A= >>> provider perspective and the need for location based provisioning of=0A= >>> NAT/Firewall traversal server resources.=0A= >>>=0A= >>> I think it can be added to Section 3.3.5.1 without being misplaced,=0A= >> but=0A= >>> it would be given a slightly narrower scope.=0A= >>>=0A= >>> I any of you want to be more explicit where this should be included,=0A= >>> please be. If you are not forthcoming I will request the authors to=0A= >> add=0A= >>> this in what they consider sensible position.=0A= >>>=0A= >>> Cheers=0A= >>>=0A= >>> Magnus=0A= >>>=0A= >>>=0A= >>> On 2014-01-25 17:46, Parthasarathi R wrote:=0A= >>>> Hi Simon,=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> Thanks for your understanding about my firewall/NAT related problem=0A= >>>> statement in this draft.=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> I have proposed the firewall/NAT related text by which the specific=0A= >>>> mechanism is not highlighted in the requirement document as there is= =0A= >> no=0A= >>>> WG consensus for any of the mechanism including TURN. It is possible= =0A= >> to=0A= >>>> argue hypothetically in PNTAW alias that PCP is the only mechanism=0A= >>>> required in WebRTC endpoint. Also, I=92m more interested in WebRTC=0A= >>>> gateway/server (Sec 4.3. of=0A= >>>> draft-ietf-rtcweb-use-cases-and-requirements-12) requirements=0A= >> wherein it=0A= >>>> is not required to support TURN and the related mail thread is=0A= >>>> http://www.ietf.org/mail-archive/web/pntaw/current/msg00181.html.=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> IMO, my proposed text without mentioning any firewall/NAT mechanism=0A= >> in=0A= >>>> the requirement document helps to move forward without depend on the= =0A= >>>> solution discussion in PNTAW alias.=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> Thanks=0A= >>>>=0A= >>>> Partha=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> *From:*Cb B [mailto:cb.list6@gmail.com]=0A= >>>> *Sent:* Saturday, January 25, 2014 6:22 AM=0A= >>>> *To:* Simon Perreault=0A= >>>> *Cc:* rtcweb@ietf.org; Parthasarathi R=0A= >>>> *Subject:* Re: [rtcweb] Query/Comment on=0A= >>>> draft-ietf-rtcweb-use-cases-and-requirements-12=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> On Jan 24, 2014 10:17 AM, "Simon Perreault"=0A= >> >>> > wrote:=0A= >>>>> Le 2014-01-24 12:14, Parthasarathi R a =E9crit :=0A= >>>>>=0A= >>>>>> Please note that when non-IETFers read this requirement document,=0A= >>>> they come=0A= >>>>>> to the conclusion that IETF RTCWeb WG recommends TURN and not=0A= >> other=0A= >>>>>> mechanisms. I'm saying that requirement document should not be=0A= >> used=0A= >>>> as the=0A= >>>>>> mechanism to eliminate the other alternatives when there is a=0A= >> discussion=0A= >>>>>> going-on in PNTAW alias. So, I'm asking for the change.=0A= >>>>>=0A= >>>>> I would totally agree with that sentiment, although I don't see=0A= >> your=0A= >>>> proposed text change reflecting it accurately. How about simply:=0A= >>>>> "Note that TURN support being mandatory does not preclude a WebRTC=0A= >>>> endpoint from supporting additional traversal mechanisms."=0A= >>>>>=0A= >>>> +1 for the above text.=0A= >>>>=0A= >>>> CB=0A= >>>>=0A= >>>>> Simon=0A= >>>>> --=0A= >>>>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca=0A= >>>>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca=0A= >>>>> STUN/TURN server --> http://numb.viagenie.ca=0A= >>>>> _______________________________________________=0A= >>>>> rtcweb mailing list=0A= >>>>> rtcweb@ietf.org =0A= >>>>> https://www.ietf.org/mailman/listinfo/rtcweb=0A= >>>>=0A= >>>>=0A= >>>> _______________________________________________=0A= >>>> rtcweb mailing list=0A= >>>> rtcweb@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/rtcweb=0A= >>>>=0A= >>>=0A= >>=0A= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= >>=0A= >> On 2014-01-16 15:18, Hutton, Andrew wrote:=0A= >>> Some comments in the text below.=0A= >>>=0A= >>> As a general comment I suggest changing all the "FW" abbreviations to= =0A= >> "Firewall" are have at least a first use definition.=0A= >>=0A= >> Done=0A= >>=0A= >>>=0A= >>> Andy=0A= >>>=0A= >>>=0A= >>>> -----Original Message-----=0A= >>>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=0A= >>>> Sent: 15 January 2014 10:20=0A= >>>> To: Chenxin (Xin); Hutton, Andrew; Christer Holmberg; Parthasarathi=0A= >> R;=0A= >>>> rtcweb@ietf.org=0A= >>>> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-=0A= >> and-=0A= >>>> requirements-12=0A= >>>>=0A= >>>> WG,=0A= >>>>=0A= >>>> It has been quite some time since the WG last call ended and a new=0A= >>>> revision was submitted. As Document Shepherd I want to push this=0A= >>>> document to publication request.=0A= >>>>=0A= >>>> Chenxin proposed below three different sets of changes to the=0A= >> document.=0A= >>>> Does the WG support making these changes? Please indicate within the= =0A= >>>> next week if you support or want to reject these changes.=0A= >>>>=0A= >>>> Thanks=0A= >>>>=0A= >>>> Magnus=0A= >>>>=0A= >>>>=0A= >>>> On 2013-10-17 12:23, Chenxin (Xin) wrote:=0A= >>>>> Hi Andy,=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> I think you means F29 not F27:). When I read it , I realize that=0A= >>>> there=0A= >>>>> is cross and ambiguous between 3.3.2 and 3.3.3=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> More details:=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> The topic of 3.3.2 is "Simple Video Communication Service, *NAT/FW*= =0A= >>>>> that blocks UDP". But in the description and requirement, only=0A= >> *NAT*=0A= >>>> is=0A= >>>>> considered.=0A= >>>>>=0A= >>>>> The topic of 3.3.3 is "Simple Video Communication Service, FW that=0A= >>>>> only allows http", But only *http proxy* deployed scenarios is=0A= >>>> considered.=0A= >>>>>=0A= >>>>>=0A= >>>>> There are other usecases " FW block UDP, incoming TCP, Http=0A= >>>> allowing=0A= >>>>> FW without http proxy deplolyed under the permission of FW policy"=0A= >> ,=0A= >>>>> which is lost in the description. If we need consider these=0A= >> usecases=0A= >>>> , I=0A= >>>>> suggest to make some change to the description.=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> Proposal 1 :=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> add FW related words to section 3.3.2=0A= >>>>>=0A= >>>>> -------------------------------------------------=0A= >>>>>=0A= >>>>> 3.3.2. Simple Video Communication Service, NAT/FW that blocks UDP=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> 3.3.2.1. Description=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> This use-case is almost identical to the Simple Video=0A= >>>> Communication=0A= >>>>> Service use-case (Section 3.3.1). The difference is that one of=0A= >>>> the=0A= >>>>> users is behind a NAT*/FW* that blocks UDP traffic.=0A= >>>>>=0A= >>>>> .=0A= >>> [AndyH] - I support this change.=0A= >> Changed=0A= >>=0A= >>>=0A= >>>>>=0A= >>>>>=0A= >>>>> 3.3.2.2. Additional Requirements=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> F29 The browser must be able to send streams and=0A= >>>>>=0A= >>>>> data to a peer in the presence of NATs *and FWs* that=0A= >>>>>=0A= >>>>> block UDP traffic ,* when FW policy allows WebRTC=0A= >>>> traffic*.=0A= >>> [AndyH] - I support this change.=0A= >> Changed=0A= >>=0A= >>>=0A= >>>>> -------------------------------------------------------=0A= >>>>>=0A= >>>>> Proposal 2: If the" Http allowing FW without http proxy deployed"=0A= >>>>> case is impliedly included in F29. I suggest to change the topics=0A= >> of=0A= >>>>> 3.3.3 to "Simple Video Communication Service, FW that only allows=0A= >>>>> traffic via a http proxy". So the 3.3.3 is a specific case.=0A= >>>>>=0A= >>> [AndyH] Yes the heading of 3.3.3 should have been changed during the=0A= >> last edit to "Simple Video Communication Service, FW that only allows=0A= >> traffic via a HTTP Proxy". I support this change.=0A= >>=0A= >> Changed.=0A= >>=0A= >>>=0A= >>>>>=0A= >>>>> Proposal 3: If " Http allowing FW without http proxy deployed"=0A= >>>> case=0A= >>>>> need to be explicitly mentioned. I suggest to add some descriptions= =0A= >>>> to 3.3.3=0A= >>>>> -----------------------------------------------------------------=0A= >>>>>=0A= >>>>> 3.3.3. Simple Video Communication Service, FW that only allows http= =0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> 3.3.3.1. Description=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> This use-case is almost identical to the Simple Video=0A= >>>> Communication=0A= >>>>> Service use-case (Section 3.3.1). The difference is that one of=0A= >>>> the=0A= >>>>> users is behind a http allowing FW or a FW that only allows=0A= >>>> traffic=0A= >>>>> via a HTTP Proxy.=0A= >>>>>=0A= >>>>>=0A= >>> [AndyH] I don't believe the intention here was to state a requirement= =0A= >> that WebRTC media should be able to flow through a FW only allowing=0A= >> HTTP. Therefore I think the original description is ok it is just the=0A= >> heading that needs to change.=0A= >>>=0A= >>>>> 3.3.3.2. Additional Requirements=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> F37 The browser must be able to send streams and=0A= >>>>>=0A= >>>>> data to a peer in the presence of http allowing FWs or FWs=0A= >>>>> that only=0A= >>>>>=0A= >>>>> allows traffic via a HTTP Proxy, when FW policy=0A= >>>>>=0A= >>>>> allows WebRTC traffic.=0A= >>>>>=0A= >>> [AndyH] The existing text is in the 012 draft is ok and I don't think= =0A= >> this change is needed as again I don't believe the intention here was=0A= >> to=0A= >> state a requirement that WebRTC media should be able to flow through a= =0A= >> FW only allowing HTTP.=0A= >>>=0A= >>>>> -------------------------------------------------------------------= =0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> Best Regards,=0A= >>>>>=0A= >>>>> Xin=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>=0A= >>>> --=0A= >>>>=0A= >>>> Magnus Westerlund=0A= >>>>=0A= >>>> --------------------------------------------------------------------= =0A= >> --=0A= >>>> Services, Media and Network features, Ericsson Research EAB/TXM=0A= >>>> --------------------------------------------------------------------= =0A= >> --=0A= >>>> Ericsson AB | Phone +46 10 7148287=0A= >>>> F=E4r=F6gatan 6 | Mobile +46 73 0949079=0A= >>>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com= =0A= >>>> --------------------------------------------------------------------= =0A= >> --=0A= >>> _______________________________________________=0A= >>> rtcweb mailing list=0A= >>> rtcweb@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/rtcweb=0A= >>>=0A= >> _______________________________________________=0A= >> rtcweb mailing list=0A= >> rtcweb@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From Michael.Tuexen@lurchi.franken.de Fri Feb 7 10:58: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 CE5A41A0422 for ; Fri, 7 Feb 2014 10:58:49 -0800 (PST) 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, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535, 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 rBC9j0eS2B92 for ; Fri, 7 Feb 2014 10:58:47 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 72C341A00FE for ; Fri, 7 Feb 2014 10:58:47 -0800 (PST) Received: from [192.168.1.200] (p54819A15.dip0.t-ipconnect.de [84.129.154.21]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3C8A51C0E965C for ; Fri, 7 Feb 2014 19:58:45 +0100 (CET) From: Michael Tuexen Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Feb 2014 19:58:22 +0100 References: <52F51569.8020501@erg.abdn.ac.uk> To: "rtcweb@ietf.org" Message-Id: <9E293819-EA0F-45C3-905B-74E1A350F22A@lurchi.franken.de> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [rtcweb] Fwd: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-dtls-encaps: To End 28th February 2014 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 07 Feb 2014 18:58:49 -0000 Dear all, any comments would be very welcome! Best regards Michael Begin forwarded message: > From: Gorry Fairhurst > Subject: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-dtls-encaps: To End = 28th February 2014 > Date: February 7, 2014 6:18:33 PM GMT+01:00 > To: tsvwg WG > Cc: tsvwg chair > Reply-To: gorry@erg.abdn.ac.uk >=20 > This email announces the start of a working group last call > of draft-ietf-tsvwg-sctp-dtls-encaps-03, > "DTLS Encapsulation of SCTP Packets". This document was > discussed at the WG meeting in Vancouver and was thought at that > meeting to be ready for WG review, this email starts this process by = requesting review comments. >=20 > Please send any comments, notes of support, or concerns to the TSVWG = list. >=20 > The draft is available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps >=20 > The last call will run for TWO weeks, ending 28th February 2014. >=20 > James, David, and Gorry > (TSVWG Chairs) > tsvwg-chairs@ietf.org >=20 From harald@alvestrand.no Fri Feb 7 11:56: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 1DE541AD0EA for ; Fri, 7 Feb 2014 11:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 sVrue25EPy4n for ; Fri, 7 Feb 2014 11:56:20 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id CE7341AD190 for ; Fri, 7 Feb 2014 11:56:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 306317C4B28 for ; Fri, 7 Feb 2014 20:56:19 +0100 (CET) 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 EcwBkVUl+6lm for ; Fri, 7 Feb 2014 20:56:19 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id 9A41E7C4B26 for ; Fri, 7 Feb 2014 20:56:18 +0100 (CET) Message-ID: <52F53A60.9090601@alvestrand.no> Date: Fri, 07 Feb 2014 20:56:16 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------000809070604010108090803" Subject: Re: [rtcweb] "SCTP New Data Chunk" review requested X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 07 Feb 2014 19:56:23 -0000 This is a multi-part message in MIME format. --------------000809070604010108090803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Based on my understanding of WG consensus, I have added this as a "MUST support" in draft-ietf-rtcweb-transport. (Not uploaded yet; I'll try to get any other comments that come in up to the deadline.) On 02/07/2014 06:01 PM, Ted Hardie wrote: > I'm not sure how large the cross-over is between tsvwg and rtcweb, so > I'd like to highlight that the tsvwg version of this draft has now > been uploaded: > > http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ > > Reviews of the document for tsvwg would be great, as they have an > aggressive deadline for pushing the document to the IESG (early Summer). > > thanks, > > Ted (for the Chairs) > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. --------------000809070604010108090803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Based on my understanding of WG consensus, I have added this as a "MUST support" in draft-ietf-rtcweb-transport. (Not uploaded yet; I'll try to get any other comments that come in up to the deadline.)

On 02/07/2014 06:01 PM, Ted Hardie wrote:
I'm not sure how large the cross-over is between tsvwg and rtcweb, so I'd like to highlight that the tsvwg version of this draft has now been uploaded:

http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/

Reviews of the document for tsvwg would be great, as they have an aggressive deadline for pushing the document to the IESG (early Summer).

thanks,

Ted (for the Chairs)


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



-- 
Surveillance is pervasive. Go Dark.
--------------000809070604010108090803-- From Raju.Makaraju@alcatel-lucent.com Fri Feb 7 14:01: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 3D8701A0506 for ; Fri, 7 Feb 2014 14:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 UcPxgg-66v5j for ; Fri, 7 Feb 2014 14:01:53 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4163C1A01C0 for ; Fri, 7 Feb 2014 14:01:52 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s17M1kpa026229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Feb 2014 16:01:47 -0600 (CST) 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 s17M1j8L015236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 17:01:46 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Fri, 7 Feb 2014 17:01:45 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) Thread-Index: AQHPI5G5uqx5hsIOAEq9u24GTLgZVJqqTeJQ Date: Fri, 7 Feb 2014 22:01:44 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <52F4182F.60404@alvestrand.no> In-Reply-To: <52F4182F.60404@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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 07 Feb 2014 22:01:55 -0000 > >> Also, I think "DOMString" PPID is too specific to Javascript, instead = it > should probably have a generic name like "UTF-16 String". The send API ca= n > still use DOMString as this is Javascript API. > > Any comments from others? >=20 > Note: The WebSockets protocol defines the transferred strings as UTF-8. > http://tools.ietf.org/html/rfc6455#section-5.6 >=20 > As far as I can tell, we've always intended to follow that example. >=20 > The fact that Javascript implementations currently choose to represent > text strings as UTF-16 at their API is sad, but not an argument for > sending that particular text representation over the wire, or reflecting > the name in the API. [Raju] I agree that using UTF-8 is desired and more appropriate! Then, shou= ld the PPID be changed from "DOMString" to "UTF-8"? Javascript based apps h= ave to use some library to do the conversion of DOMString/UTF-16 to UTF-8. = Alternatively, browsers can do this conversion under the APIs (send and onm= essage) before sending and after receiving UTF-8 PPID data. Without such conversion webrtc interworking between browsers and native cli= ents will be problematic (basically, will not work). Another option, which is more flexible, is to define PPIDs for different en= codings like "UTF-8", "UTF-16" (or even "base64" for binary to text instead= of using "binary" directly); then pass this encoding information to send()= and onmessage() calls, which will use these PPIDs. Passing encoding inform= ation might be implicit (like Javavscript DOMString) in most languages by t= he type of the argument to send. This way it is upto the application to dea= l with the encoding conversions as it see fits.=20 The latter approach is best suitable for interworking between clients of si= milar type (web or native); but it is bit painful (to do conversions) for c= lients of different types. I am wondering what kind of API calls native WebRTC API stacks (e.g. Google= Chrome's http://www.webrtc.org/webrtc-native-code-package) provide for dat= a channel send/onmessage ()? UTF-16 strings? Or UTF-8? -Raju From martin.thomson@gmail.com Fri Feb 7 15:45: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 9AE4F1AD791 for ; Fri, 7 Feb 2014 15:45:27 -0800 (PST) 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 EDMkkhOEwECS for ; Fri, 7 Feb 2014 15:45:25 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id DB6E41AD72A for ; Fri, 7 Feb 2014 15:45:24 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id x13so2686029wgg.3 for ; Fri, 07 Feb 2014 15:45:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rQEf02HuQryfXuuPfPVEAgB/gXpvoV1IcCDfDAtHu2M=; b=Gc0Y2ETVSiPZb4fRyzlcJKSDfl43z27tnAqx94iOiyQ4dAVOjhenB+a6HdUrCaTjYc JlzIpYzlNYDKIl5jUl873SVBWBEWQfAdCuFUZbwoT0NFXfw3d/mCNKmxJDso9S4hNAFX 1347FPq+9hRuSXhtDvDyOMAQlyAXHI22D6ARYNs2r1KDZaIm7bJxJFIUmzVhJ9tEe7oL V/0jUGT2mCbfar7ZFsOMV2N11Lmxfd3+pZQXHY6Veh2gzGTuCdF2rFXYAODcrtSujwZ/ MgFxB++Ylza0KBiB93eSkk1W1hNy6ts3V77b35BSx2xOBoVKIVQTmOS2Zstfu0HNJAvY XypQ== MIME-Version: 1.0 X-Received: by 10.195.13.17 with SMTP id eu17mr12784662wjd.24.1391816724221; Fri, 07 Feb 2014 15:45:24 -0800 (PST) Received: by 10.227.10.196 with HTTP; Fri, 7 Feb 2014 15:45:24 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <52F4182F.60404@alvestrand.no> Date: Fri, 7 Feb 2014 15:45:24 -0800 Message-ID: From: Martin Thomson To: "Makaraju, Maridi Raju (Raju)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 07 Feb 2014 23:45:27 -0000 I don't think that we need any complication here. It's a string. Strings are UTF-8 on the wire. Strings are UTF-16 (mostly) in JavaScript. Anything else would generate pain. On 7 February 2014 14:01, Makaraju, Maridi Raju (Raju) wrote: >> >> Also, I think "DOMString" PPID is too specific to Javascript, instead= it >> should probably have a generic name like "UTF-16 String". The send API c= an >> still use DOMString as this is Javascript API. >> > Any comments from others? >> >> Note: The WebSockets protocol defines the transferred strings as UTF-8. >> http://tools.ietf.org/html/rfc6455#section-5.6 >> >> As far as I can tell, we've always intended to follow that example. >> >> The fact that Javascript implementations currently choose to represent >> text strings as UTF-16 at their API is sad, but not an argument for >> sending that particular text representation over the wire, or reflecting >> the name in the API. > > [Raju] I agree that using UTF-8 is desired and more appropriate! Then, sh= ould the PPID be changed from "DOMString" to "UTF-8"? Javascript based apps= have to use some library to do the conversion of DOMString/UTF-16 to UTF-8= . Alternatively, browsers can do this conversion under the APIs (send and o= nmessage) before sending and after receiving UTF-8 PPID data. > Without such conversion webrtc interworking between browsers and native c= lients will be problematic (basically, will not work). > > Another option, which is more flexible, is to define PPIDs for different = encodings like "UTF-8", "UTF-16" (or even "base64" for binary to text inste= ad of using "binary" directly); then pass this encoding information to send= () and onmessage() calls, which will use these PPIDs. Passing encoding info= rmation might be implicit (like Javavscript DOMString) in most languages by= the type of the argument to send. This way it is upto the application to d= eal with the encoding conversions as it see fits. > > The latter approach is best suitable for interworking between clients of = similar type (web or native); but it is bit painful (to do conversions) for= clients of different types. > > I am wondering what kind of API calls native WebRTC API stacks (e.g. Goog= le Chrome's http://www.webrtc.org/webrtc-native-code-package) provide for d= ata channel send/onmessage ()? UTF-16 strings? Or UTF-8? > > -Raju > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Fri Feb 7 16:01: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 8E7471AD682 for ; Fri, 7 Feb 2014 16:01:18 -0800 (PST) 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_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 Dv-gp0YE-7aX for ; Fri, 7 Feb 2014 16:01:17 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id BB47E1A04C8 for ; Fri, 7 Feb 2014 16:01:16 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-6c-52f573cbaa5c Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id EF.E0.04249.BC375F25; Sat, 8 Feb 2014 01:01:16 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Sat, 8 Feb 2014 01:01:15 +0100 From: Christer Holmberg To: Martin Thomson , "Makaraju, Maridi Raju (Raju)" Thread-Topic: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) Thread-Index: AQHPI5G4gedSwhADR0Wr7uzX17tRu5qqSHkAgAAc9wCAABUk/w== Date: Sat, 8 Feb 2014 00:01:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D163B26@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <52F4182F.60404@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.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje6Z4q9BBgc+MlpcO/OP0aJh4xVW i7X/2tkdmD1an+1l9dg56y67x5IlP5kCmKO4bFJSczLLUov07RK4Mo7cWctWsFKi4tGltWwN jN0iXYycHBICJhLvLnezQNhiEhfurWfrYuTiEBI4wigx681NdghnEaPEs0nLgao4ONgELCS6 /2mDmCICRRKLr7uD9DILqEvcWXyOHcQWFiiVuLNvGhtESZnE/q0GIGERASeJnZfXMoLYLAIq Ej/7jjKD2LwCvhK7F7SCtQoJTGaRmLlcFMTmFAiUOLHwDVg9I9Bp30+tYYJYJS5x68l8JoiT BSSW7DnPDGGLSrx8/I8VwlaU+PhqHyNEvY7Egt2f2CBsbYllC19D7RWUODnzCcsERrFZSMbO QtIyC0nLLCQtCxhZVjFyFKcWJ+WmGxlsYgRGzcEtvy12MF7+a3OIUZqDRUmc9+Nb5yAhgfTE ktTs1NSC1KL4otKc1OJDjEwcnFINjGyvn2bZT8npcGBsX3566ybl1Y8m5eZcKnaK0u889vGy U+LjwAnMLWe+vs7YfDfC+YLGDnkz0Z0/2jpCFv15+eF49JWAv57f67OVVmvtrDtw2mKy3IvF k8/vXsLfE3HsvMGWFTrJc7y8o/JmPOLO/dGW/62Qb/Iio9bX1/58KgubIL/pSblN53wlluKM REMt5qLiRAAfxLAkaAIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Feb 2014 00:01:18 -0000 + 1 Regards, Christer ________________________________________ From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Martin Thomson [martin.= thomson@gmail.com] Sent: Saturday, 08 February 2014 1:45 AM To: Makaraju, Maridi Raju (Raju) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: = Usage of PPID for protocol multiplexing) I don't think that we need any complication here. It's a string. Strings are UTF-8 on the wire. Strings are UTF-16 (mostly) in JavaScript. Anything else would generate pain. On 7 February 2014 14:01, Makaraju, Maridi Raju (Raju) wrote: >> >> Also, I think "DOMString" PPID is too specific to Javascript, instead= it >> should probably have a generic name like "UTF-16 String". The send API c= an >> still use DOMString as this is Javascript API. >> > Any comments from others? >> >> Note: The WebSockets protocol defines the transferred strings as UTF-8. >> http://tools.ietf.org/html/rfc6455#section-5.6 >> >> As far as I can tell, we've always intended to follow that example. >> >> The fact that Javascript implementations currently choose to represent >> text strings as UTF-16 at their API is sad, but not an argument for >> sending that particular text representation over the wire, or reflecting >> the name in the API. > > [Raju] I agree that using UTF-8 is desired and more appropriate! Then, sh= ould the PPID be changed from "DOMString" to "UTF-8"? Javascript based apps= have to use some library to do the conversion of DOMString/UTF-16 to UTF-8= . Alternatively, browsers can do this conversion under the APIs (send and o= nmessage) before sending and after receiving UTF-8 PPID data. > Without such conversion webrtc interworking between browsers and native c= lients will be problematic (basically, will not work). > > Another option, which is more flexible, is to define PPIDs for different = encodings like "UTF-8", "UTF-16" (or even "base64" for binary to text inste= ad of using "binary" directly); then pass this encoding information to send= () and onmessage() calls, which will use these PPIDs. Passing encoding info= rmation might be implicit (like Javavscript DOMString) in most languages by= the type of the argument to send. This way it is upto the application to d= eal with the encoding conversions as it see fits. > > The latter approach is best suitable for interworking between clients of = similar type (web or native); but it is bit painful (to do conversions) for= clients of different types. > > I am wondering what kind of API calls native WebRTC API stacks (e.g. Goog= le Chrome's http://www.webrtc.org/webrtc-native-code-package) provide for d= ata channel send/onmessage ()? UTF-16 strings? Or UTF-8? > > -Raju > > _______________________________________________ > rtcweb mailing 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 Raju.Makaraju@alcatel-lucent.com Fri Feb 7 17:15: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 99E081AD8F7 for ; Fri, 7 Feb 2014 17:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 Ky8-_X50XYE1 for ; Fri, 7 Feb 2014 17:14:56 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3B21AD8F4 for ; Fri, 7 Feb 2014 17:14:56 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s181ErsM027292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Feb 2014 19:14:53 -0600 (CST) 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 s181EqDM006149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 20:14:52 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Fri, 7 Feb 2014 20:14:52 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Martin Thomson Thread-Topic: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) Thread-Index: AQHPI5G5uqx5hsIOAEq9u24GTLgZVJqqTeJQgAB8IwCAAARsAP//vsSQ Date: Sat, 8 Feb 2014 01:14:52 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <52F4182F.60404@alvestrand.no> , <7594FB04B1934943A5C02806D1A2204B1D163B26@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D163B26@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Feb 2014 01:15:03 -0000 That's good. Glad to see that no one liked the complex alternate option... = yet! :-) I just put it there for completeness and some discussion. With "utf-8 on wire", which I too think is the right approach, there is som= e spec work todo: 1. Define IANA utf-8 ppid. Creating a new one is better instead of replacin= g existing DOMString as DOMString may be used by browsers for sometime to c= ome and also to have backward compatibility/interworking. 2. Data channel core spec (http://tools.ietf.org/html/draft-ietf-rtcweb-dat= a-channel-06#section-6.6) need to specify explictly the wire format is utf-= 8. Then browsers need to do the conversion from utf-16 DOMstring to utf-8 befo= re writing on wire also in the reverse direction.=20 -Raju > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, February 07, 2014 6:01 PM > To: Martin Thomson; Makaraju, Maridi Raju (Raju) > Cc: rtcweb@ietf.org > Subject: RE: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel= : > Usage of PPID for protocol multiplexing) >=20 >=20 > + 1 >=20 > Regards, >=20 > Christer >=20 > ________________________________________ > From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Martin Thomson > [martin.thomson@gmail.com] > Sent: Saturday, 08 February 2014 1:45 AM > To: Makaraju, Maridi Raju (Raju) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel= : > Usage of PPID for protocol multiplexing) >=20 > I don't think that we need any complication here. It's a string. >=20 > Strings are UTF-8 on the wire. >=20 > Strings are UTF-16 (mostly) in JavaScript. >=20 > Anything else would generate pain. >=20 > On 7 February 2014 14:01, Makaraju, Maridi Raju (Raju) > wrote: > >> >> Also, I think "DOMString" PPID is too specific to Javascript, inste= ad > it > >> should probably have a generic name like "UTF-16 String". The send API > can > >> still use DOMString as this is Javascript API. > >> > Any comments from others? > >> > >> Note: The WebSockets protocol defines the transferred strings as UTF-8= . > >> http://tools.ietf.org/html/rfc6455#section-5.6 > >> > >> As far as I can tell, we've always intended to follow that example. > >> > >> The fact that Javascript implementations currently choose to represent > >> text strings as UTF-16 at their API is sad, but not an argument for > >> sending that particular text representation over the wire, or reflecti= ng > >> the name in the API. > > > > [Raju] I agree that using UTF-8 is desired and more appropriate! Then, > should the PPID be changed from "DOMString" to "UTF-8"? Javascript based > apps have to use some library to do the conversion of DOMString/UTF-16 to > UTF-8. Alternatively, browsers can do this conversion under the APIs (sen= d > and onmessage) before sending and after receiving UTF-8 PPID data. > > Without such conversion webrtc interworking between browsers and native > clients will be problematic (basically, will not work). > > > > Another option, which is more flexible, is to define PPIDs for differen= t > encodings like "UTF-8", "UTF-16" (or even "base64" for binary to text > instead of using "binary" directly); then pass this encoding information = to > send() and onmessage() calls, which will use these PPIDs. Passing encodin= g > information might be implicit (like Javavscript DOMString) in most langua= ges > by the type of the argument to send. This way it is upto the application = to > deal with the encoding conversions as it see fits. > > > > The latter approach is best suitable for interworking between clients o= f > similar type (web or native); but it is bit painful (to do conversions) f= or > clients of different types. > > > > I am wondering what kind of API calls native WebRTC API stacks (e.g. > Google Chrome's http://www.webrtc.org/webrtc-native-code-package) provide > for data channel send/onmessage ()? UTF-16 strings? Or UTF-8? > > > > -Raju > > > > _______________________________________________ > > rtcweb mailing 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 partha@parthasarathi.co.in Sat Feb 8 01:13: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 5A7E11ADF43 for ; Sat, 8 Feb 2014 01:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.996 X-Spam-Level: *** X-Spam-Status: No, score=3.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_84=0.6, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793, 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 lNG4EBanJGw3 for ; Sat, 8 Feb 2014 01:13:03 -0800 (PST) Received: from smtp.mailhostbox.com (unknown [162.222.225.13]) by ietfa.amsl.com (Postfix) with ESMTP id 73EE41AD7C2 for ; Sat, 8 Feb 2014 01:13:02 -0800 (PST) Received: from userPC (unknown [122.167.125.187]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 310EE19080A7; Sat, 8 Feb 2014 09:12:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1391850781; bh=YZUf9hgo8wphE9rWYYbnmbW3uLZZRPptj0gzELDIuh4=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=F4cPaN4HEN2Xw1yu0j5VP6pCrWu1yuUSMDm2iu9Lt1ICgey0k7WYal8aW7odeEJ8u UqeBgBYoZ3n+WKPmRHSeCxg1tvChaZViIjsfzGGLqSRGcEd/14zfABw2SV00PoqyZj B0HH7DIzXhQWBecgjXGDRUgcrgmhMSba8DMPgXQM= From: "Parthasarathi R" To: =?iso-8859-1?Q?'Stefan_H=E5kansson_LK'?= , References: <1447FA0C20ED5147A1AA0EF02890A64B1CF4A182@ESESSMB209.ericsson.se> <007601cf2423$2d571210$88053630$@co.in> <1447FA0C20ED5147A1AA0EF02890A64B1CF533B8@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1CF533B8@ESESSMB209.ericsson.se> Date: Sat, 8 Feb 2014 14:42:48 +0530 Message-ID: <004601cf24ad$f3a1c0c0$dae54240$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8jKZAtHwyyT87MQ3ivvr7TXBW1mABfhTGA Content-Language: en-us X-CTCH-RefID: str=0001.0A020207.52F5F51D.0097, 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 70.87.28.138 Subject: Re: [rtcweb] New version of use-case draft uploaded X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Feb 2014 09:13:07 -0000 Hi Stefan, > Yes, I did that change (TURN -> ICE). My understanding was that ICE is > what is used/mandated (and it in turn makes use of STUN and TURN). > ICE is mandated in RTCWeb but I disagree to your assumption that ICE in = turn makes use of TURN. My concern is that The requirement document is = misleading about TURN requirements. ICE-TCP avoids TURN server as the middle-box in = the network. ICE-TCP is host candidate whereas TURN is relay candidate and = as per ICE candidate selection, host candidate is preferred over relay candidates.=20 In case of WebRTC servers (like conference)/gateway implementation, = WebRTC server is never going to be behind firewall, ICE-TCP serve the purpose = and there is no need of TURN server as a middle-box in the network. So, = Could you please correct the F31, F32 requirement text in the next revision of = the draft. =20 Thanks Partha > -----Original Message----- > From: Stefan H=E5kansson LK [mailto:stefan.lk.hakansson@ericsson.com] > Sent: Friday, February 07, 2014 11:59 PM > To: Parthasarathi R; rtcweb@ietf.org > Subject: Re: [rtcweb] New version of use-case draft uploaded >=20 > Hi Partha! >=20 > On 2014-02-07 17:39, Parthasarathi R wrote: > > Hi Stefan, > > > > Simon proposed the following text after the lengthy mailing > discussion: > > > >> "Note that TURN support being mandatory does not preclude a WebRTC > >> endpoint from supporting additional traversal mechanisms." > > Whereas Sec 3.3.4.1 updated as > > > > "Note that ICE support being mandatory does not preclude a WebRTC > > endpoint from supporting additional traversal mechanisms." >=20 > Yes, I did that change (TURN -> ICE). My understanding was that ICE is > what is used/mandated (and it in turn makes use of STUN and TURN). >=20 > > > > Apart from this, Tiru > > (http://www.ietf.org/mail-archive/web/rtcweb/current/msg11246.html) > and > > myself (http://www.ietf.org/mail- > archive/web/rtcweb/current/msg11241.html) > > mentioned in the different mail thread that Sec 3.3.4.1 is not only > the > > right place to put the above text. Could you please correct the F31, > F32 > > requirement text in the next revision of the draft. >=20 > I can update them to what you propose. But I think it is a little bit > silly. If we add that note, then we should probably add to F28 "The > browser must support a baseline audio and video codec" a note saying > "this does not preclude the browser from supporting additional codecs" > and so on. After all, the requirements are meant to be what must be > supported; they do not say that additions are not allowed. >=20 > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan > >> H=E5kansson LK > >> Sent: Thursday, February 06, 2014 4:23 PM > >> To: rtcweb@ietf.org > >> Subject: [rtcweb] New version of use-case draft uploaded > >> > >> Hi, > >> > >> I've uploaded a new version -13 [1]. I have made changes based on > input > >> from Mary, Magnus and Chenxing+Andy, for details read further down. > >> > >> I hope I have caught most things; what remains to my knowledge is: > >> * Include the requirement text the first time a requirement is > derived > >> * Group (and re-number) the claims > >> > >> I am hesitating to do the last thing 'cause of the risk of getting > all > >> internal references into a mess, but one day soon I will feel brave > >> enough :-) > >> > >> Stefan > >> > >> [1] > >> http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and- > >> requirements/ > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> On 2014-01-15 21:57, Mary Barnes wrote: > >>> I had thought I had previously done a detailed review of this doc, > >> but > >> I can't find it to know whether changes suggested have been > >> incorporated. So, I have re-reviewed the document and I think it's > >> almost ready to progress. I think it needs some editorial > >> clarifications > >> and nits to be fixed as summarized below. Note, I did not review = the > >> appendix. > >>> Regards, > >>> Mary. > >>> In general, I still find the style of this document very difficult > to > >> grok since the requirements are not grouped in categories and one > has > >> to > >> keep switching back and forth in the document to match requirements > to > >> use cases. > >>> Questions/Comments for clarification: > >>> ---------------------------------------------------- > >>> 1) Section 1, 1st paragraph, last sentence. It's not clear to me > that > >> "e.g., a telephone" is meaningful. I don't think you're intending = to > >> interworking with a legacy PSTN connected black phone. So, it might > be > >> more accurate to say " e.g., a mobile phone or a SIP UA". > >> > >> Changed. > >> > >>> 2) Section 3.3.1.1. Next to last paragraph. I'm not sure what you > >> mean > >> by different "makes". I think you mean different types of devices > >> (e.g., > >> mobile, SIP UA, etc. ). That all said, I don't think that's not so > >> relevant. I think simply stating different OSs and different > browsers > >> is > >> sufficient. > >> > >> Changed. > >> > >>> 3) Section 3.3.6.1. It's not at all clear to me why this > requirement > >> is considered specific to WebRTC. I would think the access network > >> changes should be transparent to WebRTC. Certainly, the device = needs > to > >> know what's happening, but I think whether this works is entirely > based > >> on the internals of the device and the specific access network > >> technology, and not WebRTC application. > >> > >> It is not WebRTC specific per se, but is important for the = use-case. > >> What parts that solve it is of less importance IMO. > >> > >>> 4) Section 3.3.10.1. Why is F24 not considered an additional > >> requirement here? Also, do you not need to have a statement as to > what > >> other use case is the basis for this one such that the core > >> requirements > >> are reference? > >> > >> I added F24 (it belongs here). I don't think we need a statement > >> regarding the basis, it is covered in section 3.2 > >> > >>> 5) Section 3.3.11.1, 2nd paragraph, 1st sentence. I don't > understand > >> what this is trying to say. What is meant by "enhance > intelligibility"? > >> And, what is meant by "pans the audio from different participants > >> differently when rendering the audio". > >>> [As an aside, I will note that some of the CLUE use cases likely > >> encompass what you are trying to communicate here in this > requirements > >> (including subsequent paragraphs and the last "Note:"), so you may > want > >> to look at those and use similar terminology and concepts, that = CLUE > >> spent a lot of time developing. ] > >> > >> I updated (using similar terminology to Clue). > >> > >>> 6) Section 3.4. I would expect F27 to be referenced by at least = one > >> of > >> these use cases. > >> > >> I added it to 3.4.1 > >> > >>> 7) Section 4.2. > >>> - General: I am a bit confused as there are requirements in this > >> section that aren't referenced in section 3, including F19, F23, = and > >> F27 > >> . Perhaps, that's because there are some missing references in > section > >> 3 > >> (see item 7)? If not, then why are they there. At a minimum you > should > >> add a sentence to section 4.1 indicating that not all the > requirements > >> are derived from the use cases (contrary to what is currently > stated). > >> > >> F19 has been removed. I added ref to F23 (and F24!) from ues-case > >> "multi-party game with voice communication". Ref to F27 added to > 3.4.1. > >> > >>> - What's the difference between F24 and F34? > >> I don't know, and I removed F34 > >> > >>> - F30. I had to read this several times to understand it due to > >> structure. I would suggest changing as follows: > >>> OLD: > >>> F30 The browser must be able to use the screen (or > >>> a specific area of the screen) or what a certain > >>> application displays on the screen to generate > >>> streams. > >>> NEW: > >>> F30 The browser must be able to generate streams using the entire > >> user > >> display, a specific area of the user's display or the information > being > >> displayed by a specific application. > >> > >> Updated. > >> > >>> On this one, I also think it would be good to clarify what type of > >> stream - are you talking about using protocol to share content or = or > is > >> this just a video stream? Or would you have two separate = requirement > to > >> cover both of these? > >> > >> I would like to avoid going into detail; the idea is that it is = some > >> kind of "stream" that allows sharing what is rendered on your > screen, > >> the requirement does not need to go into what kind it is. > >> > >>> - F32. I can't quite grok this one. Maybe you are trying to say > >> something like the following? > >>> OLD: > >>> F32 There browser must support that STUN and TURN > >>> servers to use are supplied by other entities > >>> than via the web application (i.e. the network > >>> provider). > >>> NEW: > >>> F32 The browser must support the use of STUN and TURN > >>> servers that are supplied by entities > >>> other than the web application (i.e. the network > >>> provider). > >> Updated. > >> > >>> 8) Section 7. I have mixed feelings about leaving this list with > URLs > >> in the document. I think it's good to highlight the use cases that > >> weren't incorporated and why they weren't. I think it would add a > lot > >> more value to provide a concise summary of the reasons they weren't > >> added than just including links, in particular, since we usually > don't > >> like to publish RFCs with links. > >> > >> I think the entire list should go before publication. The list has > been > >> kept there as a reminder of what we included and what we did not > >> included. I have removed it in this version. > >> > >>> Nits: > >>> ------ > >>> 1) Section 1, 1st paragraph, last sentence, "at least one of the > >> end-user client" -> "at least one of the end-user clients" > >>> 2) Section 3.2, 1st paragraph, 1st sentence: > >>> - "retrives" -> "retrieves" > >>> - add a section reference for "Simple Video Communication Service" > >>> 3) Section 3.2. , next to last sentence. "retrieved from" -> > "derived > >> from" > >>> 4) Section 3.3.5.1, 3rd paragraph, > >>> - 1st sentence. "session" - "session" > >>> - 2nd sentence. "straddle the boundary between the internal = network > >> and external." -> "straddles the boundary between the internal and > >> external networks. > >>> 5) Section 3.3.5.1, 4th paragraph. "they still want to have the > >> traffic to stay" -> "they still want the traffic to say" > >>> 6) Section 3.3.61. 1st paragraph. I'm not sure why this ends with > ":" > >>> 7) Section 3.3.6.1, 2nd paragraph. "device used by one of the = users > >> have several" -> "device used by one of the users has several" > >>> 8) Section 3.3.11.1, 1st para, 1st sentence. "In this use case is > the > >> Simple..." -> "In this use case, the Simple...." > >>> 9) Section 3.3.11.1 3rd from last paragraph. "use experience" -> > >> "user > >> experience" > >>> 10) Section 3.4.3.1, 2nd paragraph. "participant send" -> > >> "participant > >> sends" > >>> 11) Section 4.2: > >>> - F35. "of that streams" -> "that streams" > >> Most Nit's fixed > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> > >> On 2014-01-29 10:29, Magnus Westerlund wrote: > >>> Hi Partha and WG, > >>> > >>> I don't see any support for the changes you proposes in this > >> discussion. > >>> What I see some support for is to add a statement making clear = that > >>> there might be additional NAT/Firewall traversal mechanisms than > >>> STUN/TURN. Simon proposed: > >>> > >>> "Note that TURN support being mandatory does not preclude a WebRTC > >>> endpoint from supporting additional traversal mechanisms." > >> I added this to section 3.3.4.1 > >> > >>> > >>> However, looking at the document as it is currently written, I am > >>> uncertain where this would be added. The first mention of TURN is > in > >>> Section 3.3.4.1, and that section is focused on the global service > >>> provider perspective and the need for location based provisioning > of > >>> NAT/Firewall traversal server resources. > >>> > >>> I think it can be added to Section 3.3.5.1 without being = misplaced, > >> but > >>> it would be given a slightly narrower scope. > >>> > >>> I any of you want to be more explicit where this should be > included, > >>> please be. If you are not forthcoming I will request the authors = to > >> add > >>> this in what they consider sensible position. > >>> > >>> Cheers > >>> > >>> Magnus > >>> > >>> > >>> On 2014-01-25 17:46, Parthasarathi R wrote: > >>>> Hi Simon, > >>>> > >>>> > >>>> > >>>> Thanks for your understanding about my firewall/NAT related > problem > >>>> statement in this draft. > >>>> > >>>> > >>>> > >>>> I have proposed the firewall/NAT related text by which the > specific > >>>> mechanism is not highlighted in the requirement document as there > is > >> no > >>>> WG consensus for any of the mechanism including TURN. It is > possible > >> to > >>>> argue hypothetically in PNTAW alias that PCP is the only = mechanism > >>>> required in WebRTC endpoint. Also, I=92m more interested in = WebRTC > >>>> gateway/server (Sec 4.3. of > >>>> draft-ietf-rtcweb-use-cases-and-requirements-12) requirements > >> wherein it > >>>> is not required to support TURN and the related mail thread is > >>>> http://www.ietf.org/mail-archive/web/pntaw/current/msg00181.html. > >>>> > >>>> > >>>> > >>>> IMO, my proposed text without mentioning any firewall/NAT > mechanism > >> in > >>>> the requirement document helps to move forward without depend on > the > >>>> solution discussion in PNTAW alias. > >>>> > >>>> > >>>> > >>>> Thanks > >>>> > >>>> Partha > >>>> > >>>> > >>>> > >>>> *From:*Cb B [mailto:cb.list6@gmail.com] > >>>> *Sent:* Saturday, January 25, 2014 6:22 AM > >>>> *To:* Simon Perreault > >>>> *Cc:* rtcweb@ietf.org; Parthasarathi R > >>>> *Subject:* Re: [rtcweb] Query/Comment on > >>>> draft-ietf-rtcweb-use-cases-and-requirements-12 > >>>> > >>>> > >>>> > >>>> > >>>> On Jan 24, 2014 10:17 AM, "Simon Perreault" > >> >>>> > wrote: > >>>>> Le 2014-01-24 12:14, Parthasarathi R a =E9crit : > >>>>> > >>>>>> Please note that when non-IETFers read this requirement > document, > >>>> they come > >>>>>> to the conclusion that IETF RTCWeb WG recommends TURN and not > >> other > >>>>>> mechanisms. I'm saying that requirement document should not be > >> used > >>>> as the > >>>>>> mechanism to eliminate the other alternatives when there is a > >> discussion > >>>>>> going-on in PNTAW alias. So, I'm asking for the change. > >>>>> > >>>>> I would totally agree with that sentiment, although I don't see > >> your > >>>> proposed text change reflecting it accurately. How about simply: > >>>>> "Note that TURN support being mandatory does not preclude a > WebRTC > >>>> endpoint from supporting additional traversal mechanisms." > >>>>> > >>>> +1 for the above text. > >>>> > >>>> CB > >>>> > >>>>> Simon > >>>>> -- > >>>>> DTN made easy, lean, and smart --> > http://postellation.viagenie.ca > >>>>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > >>>>> STUN/TURN server --> http://numb.viagenie.ca > >>>>> _______________________________________________ > >>>>> rtcweb mailing list > >>>>> rtcweb@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/rtcweb > >>>> > >>>> > >>>> _______________________________________________ > >>>> rtcweb mailing list > >>>> rtcweb@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/rtcweb > >>>> > >>> > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> On 2014-01-16 15:18, Hutton, Andrew wrote: > >>> Some comments in the text below. > >>> > >>> As a general comment I suggest changing all the "FW" abbreviations > to > >> "Firewall" are have at least a first use definition. > >> > >> Done > >> > >>> > >>> Andy > >>> > >>> > >>>> -----Original Message----- > >>>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >>>> Sent: 15 January 2014 10:20 > >>>> To: Chenxin (Xin); Hutton, Andrew; Christer Holmberg; > Parthasarathi > >> R; > >>>> rtcweb@ietf.org > >>>> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use- > cases- > >> and- > >>>> requirements-12 > >>>> > >>>> WG, > >>>> > >>>> It has been quite some time since the WG last call ended and a = new > >>>> revision was submitted. As Document Shepherd I want to push this > >>>> document to publication request. > >>>> > >>>> Chenxin proposed below three different sets of changes to the > >> document. > >>>> Does the WG support making these changes? Please indicate within > the > >>>> next week if you support or want to reject these changes. > >>>> > >>>> Thanks > >>>> > >>>> Magnus > >>>> > >>>> > >>>> On 2013-10-17 12:23, Chenxin (Xin) wrote: > >>>>> Hi Andy, > >>>>> > >>>>> > >>>>> > >>>>> I think you means F29 not F27:). When I read it , I realize that > >>>> there > >>>>> is cross and ambiguous between 3.3.2 and 3.3.3 > >>>>> > >>>>> > >>>>> > >>>>> More details: > >>>>> > >>>>> > >>>>> > >>>>> The topic of 3.3.2 is "Simple Video Communication Service, > *NAT/FW* > >>>>> that blocks UDP". But in the description and requirement, only > >> *NAT* > >>>> is > >>>>> considered. > >>>>> > >>>>> The topic of 3.3.3 is "Simple Video Communication Service, FW > that > >>>>> only allows http", But only *http proxy* deployed scenarios is > >>>> considered. > >>>>> > >>>>> > >>>>> There are other usecases " FW block UDP, incoming TCP, Http > >>>> allowing > >>>>> FW without http proxy deplolyed under the permission of FW > policy" > >> , > >>>>> which is lost in the description. If we need consider these > >> usecases > >>>> , I > >>>>> suggest to make some change to the description. > >>>>> > >>>>> > >>>>> > >>>>> Proposal 1 : > >>>>> > >>>>> > >>>>> > >>>>> add FW related words to section 3.3.2 > >>>>> > >>>>> ------------------------------------------------- > >>>>> > >>>>> 3.3.2. Simple Video Communication Service, NAT/FW that blocks = UDP > >>>>> > >>>>> > >>>>> > >>>>> 3.3.2.1. Description > >>>>> > >>>>> > >>>>> > >>>>> This use-case is almost identical to the Simple Video > >>>> Communication > >>>>> Service use-case (Section 3.3.1). The difference is that one of > >>>> the > >>>>> users is behind a NAT*/FW* that blocks UDP traffic. > >>>>> > >>>>> . > >>> [AndyH] - I support this change. > >> Changed > >> > >>> > >>>>> > >>>>> > >>>>> 3.3.2.2. Additional Requirements > >>>>> > >>>>> > >>>>> > >>>>> F29 The browser must be able to send streams and > >>>>> > >>>>> data to a peer in the presence of NATs *and FWs* that > >>>>> > >>>>> block UDP traffic ,* when FW policy allows WebRTC > >>>> traffic*. > >>> [AndyH] - I support this change. > >> Changed > >> > >>> > >>>>> ------------------------------------------------------- > >>>>> > >>>>> Proposal 2: If the" Http allowing FW without http proxy = deployed" > >>>>> case is impliedly included in F29. I suggest to change the = topics > >> of > >>>>> 3.3.3 to "Simple Video Communication Service, FW that only = allows > >>>>> traffic via a http proxy". So the 3.3.3 is a specific case. > >>>>> > >>> [AndyH] Yes the heading of 3.3.3 should have been changed during > the > >> last edit to "Simple Video Communication Service, FW that only > allows > >> traffic via a HTTP Proxy". I support this change. > >> > >> Changed. > >> > >>> > >>>>> > >>>>> Proposal 3: If " Http allowing FW without http proxy deployed" > >>>> case > >>>>> need to be explicitly mentioned. I suggest to add some > descriptions > >>>> to 3.3.3 > >>>>> = ----------------------------------------------------------------- > >>>>> > >>>>> 3.3.3. Simple Video Communication Service, FW that only allows > http > >>>>> > >>>>> > >>>>> > >>>>> 3.3.3.1. Description > >>>>> > >>>>> > >>>>> > >>>>> This use-case is almost identical to the Simple Video > >>>> Communication > >>>>> Service use-case (Section 3.3.1). The difference is that one of > >>>> the > >>>>> users is behind a http allowing FW or a FW that only allows > >>>> traffic > >>>>> via a HTTP Proxy. > >>>>> > >>>>> > >>> [AndyH] I don't believe the intention here was to state a > requirement > >> that WebRTC media should be able to flow through a FW only allowing > >> HTTP. Therefore I think the original description is ok it is just > the > >> heading that needs to change. > >>> > >>>>> 3.3.3.2. Additional Requirements > >>>>> > >>>>> > >>>>> > >>>>> F37 The browser must be able to send streams and > >>>>> > >>>>> data to a peer in the presence of http allowing FWs or FWs > >>>>> that only > >>>>> > >>>>> allows traffic via a HTTP Proxy, when FW policy > >>>>> > >>>>> allows WebRTC traffic. > >>>>> > >>> [AndyH] The existing text is in the 012 draft is ok and I don't > think > >> this change is needed as again I don't believe the intention here > was > >> to > >> state a requirement that WebRTC media should be able to flow = through > a > >> FW only allowing HTTP. > >>> > >>>>> = ----------------------------------------------------------------- > -- > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Best Regards, > >>>>> > >>>>> Xin > >>>>> > >>>>> > >>>>> > >>>> > >>>> -- > >>>> > >>>> Magnus Westerlund > >>>> > >>>> = ------------------------------------------------------------------ > -- > >> -- > >>>> Services, Media and Network features, Ericsson Research EAB/TXM > >>>> = ------------------------------------------------------------------ > -- > >> -- > >>>> Ericsson AB | Phone +46 10 7148287 > >>>> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >>>> SE-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@ericsson.com > >>>> = ------------------------------------------------------------------ > -- > >> -- > >>> _______________________________________________ > >>> rtcweb mailing 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 > =3D From Michael.Tuexen@lurchi.franken.de Sat Feb 8 01:16: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 2AA5D1ADF44 for ; Sat, 8 Feb 2014 01:16:57 -0800 (PST) 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, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535, 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 seennMCExbpc for ; Sat, 8 Feb 2014 01:16:54 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3981ADF33 for ; Sat, 8 Feb 2014 01:16:53 -0800 (PST) Received: from [192.168.1.200] (p54819A15.dip0.t-ipconnect.de [84.129.154.21]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1D0111C0B3E5C; Sat, 8 Feb 2014 10:16:52 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Sat, 8 Feb 2014 10:16:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <23A98499-FA93-472A-B762-92BF72EAC2F1@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <52F4182F.60404@alvestrand.no> , <7594FB04B1934943A5C02806D1A2204B1D163B26@ESESSMB209.ericsson.se> To: "Makaraju, Maridi Raju (Raju)" X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Feb 2014 09:16:57 -0000 On Feb 8, 2014, at 2:14 AM, "Makaraju, Maridi Raju (Raju)" = wrote: > That's good. Glad to see that no one liked the complex alternate = option... yet! :-) > I just put it there for completeness and some discussion. > With "utf-8 on wire", which I too think is the right approach, there = is some spec work todo: > 1. Define IANA utf-8 ppid. Creating a new one is better instead of = replacing existing DOMString as DOMString may be used by browsers for = sometime to come and also to have backward compatibility/interworking. > 2. Data channel core spec = (http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06#section-6.6)= need to specify explictly the wire format is utf-8. Anu objections? If not, I'll put corresponding text into the spec. Best regards Michael >=20 > Then browsers need to do the conversion from utf-16 DOMstring to utf-8 = before writing on wire also in the reverse direction.=20 >=20 > -Raju >=20 >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Friday, February 07, 2014 6:01 PM >> To: Martin Thomson; Makaraju, Maridi Raju (Raju) >> Cc: rtcweb@ietf.org >> Subject: RE: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data = Channel: >> Usage of PPID for protocol multiplexing) >>=20 >>=20 >> + 1 >>=20 >> Regards, >>=20 >> Christer >>=20 >> ________________________________________ >> From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Martin Thomson >> [martin.thomson@gmail.com] >> Sent: Saturday, 08 February 2014 1:45 AM >> To: Makaraju, Maridi Raju (Raju) >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data = Channel: >> Usage of PPID for protocol multiplexing) >>=20 >> I don't think that we need any complication here. It's a string. >>=20 >> Strings are UTF-8 on the wire. >>=20 >> Strings are UTF-16 (mostly) in JavaScript. >>=20 >> Anything else would generate pain. >>=20 >> On 7 February 2014 14:01, Makaraju, Maridi Raju (Raju) >> wrote: >>>>>> Also, I think "DOMString" PPID is too specific to Javascript, = instead >> it >>>> should probably have a generic name like "UTF-16 String". The send = API >> can >>>> still use DOMString as this is Javascript API. >>>>> Any comments from others? >>>>=20 >>>> Note: The WebSockets protocol defines the transferred strings as = UTF-8. >>>> http://tools.ietf.org/html/rfc6455#section-5.6 >>>>=20 >>>> As far as I can tell, we've always intended to follow that example. >>>>=20 >>>> The fact that Javascript implementations currently choose to = represent >>>> text strings as UTF-16 at their API is sad, but not an argument for >>>> sending that particular text representation over the wire, or = reflecting >>>> the name in the API. >>>=20 >>> [Raju] I agree that using UTF-8 is desired and more appropriate! = Then, >> should the PPID be changed from "DOMString" to "UTF-8"? Javascript = based >> apps have to use some library to do the conversion of = DOMString/UTF-16 to >> UTF-8. Alternatively, browsers can do this conversion under the APIs = (send >> and onmessage) before sending and after receiving UTF-8 PPID data. >>> Without such conversion webrtc interworking between browsers and = native >> clients will be problematic (basically, will not work). >>>=20 >>> Another option, which is more flexible, is to define PPIDs for = different >> encodings like "UTF-8", "UTF-16" (or even "base64" for binary to text >> instead of using "binary" directly); then pass this encoding = information to >> send() and onmessage() calls, which will use these PPIDs. Passing = encoding >> information might be implicit (like Javavscript DOMString) in most = languages >> by the type of the argument to send. This way it is upto the = application to >> deal with the encoding conversions as it see fits. >>>=20 >>> The latter approach is best suitable for interworking between = clients of >> similar type (web or native); but it is bit painful (to do = conversions) for >> clients of different types. >>>=20 >>> I am wondering what kind of API calls native WebRTC API stacks (e.g. >> Google Chrome's http://www.webrtc.org/webrtc-native-code-package) = provide >> for data channel send/onmessage ()? UTF-16 strings? Or UTF-8? >>>=20 >>> -Raju >>>=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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From christer.holmberg@ericsson.com Sat Feb 8 01:23: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 598BD1ADF43 for ; Sat, 8 Feb 2014 01:23:18 -0800 (PST) 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_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 BRz7B8-nn0WP for ; Sat, 8 Feb 2014 01:23:15 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 31FA21AD7C2 for ; Sat, 8 Feb 2014 01:23:15 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-e5-52f5f7813ef4 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 9D.16.04249.187F5F25; Sat, 8 Feb 2014 10:23:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Sat, 8 Feb 2014 10:23:13 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Martin Thomson" Thread-Topic: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) Thread-Index: AQHPI5G4gedSwhADR0Wr7uzX17tRu5qqSHkAgAAc9wCAABUk/4AAA9sAgACZNEg= Date: Sat, 8 Feb 2014 09:23:12 +0000 Message-ID: <3au9wgasyo329a7x4xu2o08l.1391851390844@email.android.com> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <52F4182F.60404@alvestrand.no> , <7594FB04B1934943A5C02806D1A2204B1D163B26@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+JvjW7j969BBisPmltcO/OP0aJh4xVW i7X/2tkdmD1an+1l9dg56y67x5IlP5kCmKO4bFJSczLLUov07RK4Mqat2M5WcE+tovXZF/YG xs3yXYycHBICJhJTZ91lg7DFJC7cWw9kc3EICRxhlFiydQojhLOIUWLz2h2sXYwcHGwCFhLd /7RBGkQESiTObPrBDGIzC6hL3Fl8jh3EFhYolbizbxobSLmIQJnE/q0GEKafxNfVjCAVLAIq Elf+9bGA2LwCbhJL5j+C2rSCVeLlvn52kHpOgViJ2fdtQGoYgU77fmoNE8QmcYlbT+YzQZws ILFkz3lmCFtU4uXjf6wQNToSC3Z/YoOwtSWWLXzNDLFLUOLkzCcsExhFZyEZNQtJyywkLbOQ tCxgZFnFyFGcWpyUm25ksIkRGB0Ht/y22MF4+a/NIUZpDhYlcd6Pb52DhATSE0tSs1NTC1KL 4otKc1KLDzEycXBKNTAulTewsY6IO6G45KrI/KapZ9y+ZdRxKF88dOTUsXAbTZaSmwKdG8/f deD6sficzsli0R+vmWaUH5x+Q+Ntzpll/bcL8mwjlrSpzPJ+l+dQqf94Uvdku71PM+q+nViW y/UhQFOv/ebjLdqbLLZ/DfCxPndBqLVuTvRfHYeIu2zWE7Llb9z8Va2vxFKckWioxVxUnAgA il58/VwCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Feb 2014 09:23:18 -0000 Hi, I guess there is a good reason why the current PPID values have been regist= ered to begin with, because normally any IANA registrations take place prio= r to RFC publication. But, I have no problem with defining a new value for utf-8, and keep the cu= rrent values in the registry - as long as it is clear that they are depreca= ted, and kept in the registry only for "historical" reasons (according to t= he suggestion by Harald). Regards, Christer Sent from my Sony Ericsson Xperia arc S "Makaraju, Maridi Raju (Raju)" wrote: That's good. Glad to see that no one liked the complex alternate option... = yet! :-) I just put it there for completeness and some discussion. With "utf-8 on wire", which I too think is the right approach, there is som= e spec work todo: 1. Define IANA utf-8 ppid. Creating a new one is better instead of replacin= g existing DOMString as DOMString may be used by browsers for sometime to c= ome and also to have backward compatibility/interworking. 2. Data channel core spec (http://tools.ietf.org/html/draft-ietf-rtcweb-dat= a-channel-06#section-6.6) need to specify explictly the wire format is utf-= 8. Then browsers need to do the conversion from utf-16 DOMstring to utf-8 befo= re writing on wire also in the reverse direction. -Raju > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, February 07, 2014 6:01 PM > To: Martin Thomson; Makaraju, Maridi Raju (Raju) > Cc: rtcweb@ietf.org > Subject: RE: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel= : > Usage of PPID for protocol multiplexing) > > > + 1 > > Regards, > > Christer > > ________________________________________ > From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Martin Thomson > [martin.thomson@gmail.com] > Sent: Saturday, 08 February 2014 1:45 AM > To: Makaraju, Maridi Raju (Raju) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel= : > Usage of PPID for protocol multiplexing) > > I don't think that we need any complication here. It's a string. > > Strings are UTF-8 on the wire. > > Strings are UTF-16 (mostly) in JavaScript. > > Anything else would generate pain. > > On 7 February 2014 14:01, Makaraju, Maridi Raju (Raju) > wrote: > >> >> Also, I think "DOMString" PPID is too specific to Javascript, inste= ad > it > >> should probably have a generic name like "UTF-16 String". The send API > can > >> still use DOMString as this is Javascript API. > >> > Any comments from others? > >> > >> Note: The WebSockets protocol defines the transferred strings as UTF-8= . > >> http://tools.ietf.org/html/rfc6455#section-5.6 > >> > >> As far as I can tell, we've always intended to follow that example. > >> > >> The fact that Javascript implementations currently choose to represent > >> text strings as UTF-16 at their API is sad, but not an argument for > >> sending that particular text representation over the wire, or reflecti= ng > >> the name in the API. > > > > [Raju] I agree that using UTF-8 is desired and more appropriate! Then, > should the PPID be changed from "DOMString" to "UTF-8"? Javascript based > apps have to use some library to do the conversion of DOMString/UTF-16 to > UTF-8. Alternatively, browsers can do this conversion under the APIs (sen= d > and onmessage) before sending and after receiving UTF-8 PPID data. > > Without such conversion webrtc interworking between browsers and native > clients will be problematic (basically, will not work). > > > > Another option, which is more flexible, is to define PPIDs for differen= t > encodings like "UTF-8", "UTF-16" (or even "base64" for binary to text > instead of using "binary" directly); then pass this encoding information = to > send() and onmessage() calls, which will use these PPIDs. Passing encodin= g > information might be implicit (like Javavscript DOMString) in most langua= ges > by the type of the argument to send. This way it is upto the application = to > deal with the encoding conversions as it see fits. > > > > The latter approach is best suitable for interworking between clients o= f > similar type (web or native); but it is bit painful (to do conversions) f= or > clients of different types. > > > > I am wondering what kind of API calls native WebRTC API stacks (e.g. > Google Chrome's http://www.webrtc.org/webrtc-native-code-package) provide > for data channel send/onmessage ()? UTF-16 strings? Or UTF-8? > > > > -Raju > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Sat Feb 8 01:26: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 63DBD1ADF44 for ; Sat, 8 Feb 2014 01:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 i2TJcrVzyrLy for ; Sat, 8 Feb 2014 01:26:06 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 269011A00AE for ; Sat, 8 Feb 2014 01:26:04 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-12-52f5f82c462c Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E5.19.10875.C28F5F25; Sat, 8 Feb 2014 10:26:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Sat, 8 Feb 2014 10:26:03 +0100 From: Christer Holmberg To: Michael Tuexen , "Makaraju, Maridi Raju (Raju)" Thread-Topic: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) Thread-Index: AQHPI5G4gedSwhADR0Wr7uzX17tRu5qqSHkAgAAc9wCAABUk/4AAA9sAgACGp4CAABNZEA== Date: Sat, 8 Feb 2014 09:26:03 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <52F4182F.60404@alvestrand.no> , <7594FB04B1934943A5C02806D1A2204B1D163B26@ESESSMB209.ericsson.se> , <23A98499-FA93-472A-B762-92BF72EAC2F1@lurchi.franken.de> In-Reply-To: <23A98499-FA93-472A-B762-92BF72EAC2F1@lurchi.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvja7Oj69BBm/O8FlcO/OP0eJi0xJG i4aNV1gt1v5rZ3dg8Wh9tpfVY+esu+weS5b8ZPLY0LKDKYAlissmJTUnsyy1SN8ugStjwpMe toKz6hUNb28yNTDuUehi5OSQEDCRmPZ1CyOELSZx4d56ti5GLg4hgUOMEnNWboJyFjFKzD+8 ibWLkYODTcBCovufNogpIlAl0dqkDtLLLBAi8fDsO2YQW1igVOJe+3NGiJIyif1bDSDMMImX jzNAKlgEVCRmNn9kA7F5Bdwkfndeh1r0jFXiz5Y7rCAJTgFXiTtPn7CA2IxAp30/tYYJYpW4 xK0n85kgThaQWLLnPDOELQo0/x8rRI2OxILdn9ggbG2JZQtfM0MsE5Q4OfMJywRG0VlIRs1C 0jILScssJC0LGFlWMbLnJmbmpJcbbmIExsvBLb91dzCeOidyiFGag0VJnPfDW+cgIYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYyujMoV8hPfOzE3HY74lHRgnq3c5h8XQ7QUtF/vbTuXqLL3 DuM689NzNS5P4IgOeZvevOnohCrrj9eSfPykdsXNOHzc7Lrnz/VtBfv7Hk9W+3buTPsUdxsb rcmnbJdePMPAfeG3Y65QevneU6+XWUVd/vdW+d/WVYtnb13wccM3jSaGU/PCZxfVKrEUZyQa ajEXFScCAEHF1LRlAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Feb 2014 09:26:09 -0000 Hi, We could have an informative note somewhere.in the draft, pointing out the = format used by JavaScript, if people think it would be useful. Regards, Christer Sent from my Sony Ericsson Xperia arc S Michael Tuexen wrote: On Feb 8, 2014, at 2:14 AM, "Makaraju, Maridi Raju (Raju)" wrote: > That's good. Glad to see that no one liked the complex alternate option..= . yet! :-) > I just put it there for completeness and some discussion. > With "utf-8 on wire", which I too think is the right approach, there is s= ome spec work todo: > 1. Define IANA utf-8 ppid. Creating a new one is better instead of replac= ing existing DOMString as DOMString may be used by browsers for sometime to= come and also to have backward compatibility/interworking. > 2. Data channel core spec (http://tools.ietf.org/html/draft-ietf-rtcweb-d= ata-channel-06#section-6.6) need to specify explictly the wire format is ut= f-8. Anu objections? If not, I'll put corresponding text into the spec. Best regards Michael > > Then browsers need to do the conversion from utf-16 DOMstring to utf-8 be= fore writing on wire also in the reverse direction. > > -Raju > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Friday, February 07, 2014 6:01 PM >> To: Martin Thomson; Makaraju, Maridi Raju (Raju) >> Cc: rtcweb@ietf.org >> Subject: RE: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channe= l: >> Usage of PPID for protocol multiplexing) >> >> >> + 1 >> >> Regards, >> >> Christer >> >> ________________________________________ >> From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Martin Thomson >> [martin.thomson@gmail.com] >> Sent: Saturday, 08 February 2014 1:45 AM >> To: Makaraju, Maridi Raju (Raju) >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channe= l: >> Usage of PPID for protocol multiplexing) >> >> I don't think that we need any complication here. It's a string. >> >> Strings are UTF-8 on the wire. >> >> Strings are UTF-16 (mostly) in JavaScript. >> >> Anything else would generate pain. >> >> On 7 February 2014 14:01, Makaraju, Maridi Raju (Raju) >> wrote: >>>>>> Also, I think "DOMString" PPID is too specific to Javascript, instea= d >> it >>>> should probably have a generic name like "UTF-16 String". The send API >> can >>>> still use DOMString as this is Javascript API. >>>>> Any comments from others? >>>> >>>> Note: The WebSockets protocol defines the transferred strings as UTF-8= . >>>> http://tools.ietf.org/html/rfc6455#section-5.6 >>>> >>>> As far as I can tell, we've always intended to follow that example. >>>> >>>> The fact that Javascript implementations currently choose to represent >>>> text strings as UTF-16 at their API is sad, but not an argument for >>>> sending that particular text representation over the wire, or reflecti= ng >>>> the name in the API. >>> >>> [Raju] I agree that using UTF-8 is desired and more appropriate! Then, >> should the PPID be changed from "DOMString" to "UTF-8"? Javascript based >> apps have to use some library to do the conversion of DOMString/UTF-16 t= o >> UTF-8. Alternatively, browsers can do this conversion under the APIs (se= nd >> and onmessage) before sending and after receiving UTF-8 PPID data. >>> Without such conversion webrtc interworking between browsers and native >> clients will be problematic (basically, will not work). >>> >>> Another option, which is more flexible, is to define PPIDs for differen= t >> encodings like "UTF-8", "UTF-16" (or even "base64" for binary to text >> instead of using "binary" directly); then pass this encoding information= to >> send() and onmessage() calls, which will use these PPIDs. Passing encodi= ng >> information might be implicit (like Javavscript DOMString) in most langu= ages >> by the type of the argument to send. This way it is upto the application= to >> deal with the encoding conversions as it see fits. >>> >>> The latter approach is best suitable for interworking between clients o= f >> similar type (web or native); but it is bit painful (to do conversions) = for >> clients of different types. >>> >>> I am wondering what kind of API calls native WebRTC API stacks (e.g. >> Google Chrome's http://www.webrtc.org/webrtc-native-code-package) provid= e >> for data channel send/onmessage ()? UTF-16 strings? Or UTF-8? >>> >>> -Raju >>> >>> _______________________________________________ >>> rtcweb mailing 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 Michael.Tuexen@lurchi.franken.de Sat Feb 8 02:01: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 5DC791A0456 for ; Sat, 8 Feb 2014 02:01:00 -0800 (PST) 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, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535, 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 eNHVPmzxnRlX for ; Sat, 8 Feb 2014 02:00:58 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id CF9FA1A00AB for ; Sat, 8 Feb 2014 02:00:57 -0800 (PST) Received: from [192.168.1.200] (p54819A15.dip0.t-ipconnect.de [84.129.154.21]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 305E01C0E965C; Sat, 8 Feb 2014 11:00:56 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Sat, 8 Feb 2014 11:00:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3D4F4E8C-9E9D-4DE3-A8EC-D908B15A32AB@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <52F4182F.60404@alvestrand.no> , <7594FB04B1934943A5C02806D1A2204B1D163B26@ESESSMB209.ericsson.se> , <23A98499-FA93-472A-B762-92BF72EAC2F1@lurchi.franken.de> To: Christer Holmberg X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Feb 2014 10:01:00 -0000 On Feb 8, 2014, at 10:26 AM, Christer Holmberg = wrote: > Hi, >=20 > We could have an informative note somewhere.in the draft, pointing out = the format used by JavaScript, if people think it would be useful. Hmm. I don't want to repeat what is in http://heycam.github.io/webidl/#idl-DOMString I like the idea to specify UTF-8 using a new PPID and deprecate the = usage of the current PPID for DOMString. Best regards Michael >=20 > Regards, >=20 > Christer >=20 >=20 > Sent from my Sony Ericsson Xperia arc S >=20 > Michael Tuexen wrote: >=20 >=20 > On Feb 8, 2014, at 2:14 AM, "Makaraju, Maridi Raju (Raju)" = wrote: >=20 >> That's good. Glad to see that no one liked the complex alternate = option... yet! :-) >> I just put it there for completeness and some discussion. >> With "utf-8 on wire", which I too think is the right approach, there = is some spec work todo: >> 1. Define IANA utf-8 ppid. Creating a new one is better instead of = replacing existing DOMString as DOMString may be used by browsers for = sometime to come and also to have backward compatibility/interworking. >> 2. Data channel core spec = (http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06#section-6.6)= need to specify explictly the wire format is utf-8. > Anu objections? >=20 > If not, I'll put corresponding text into the spec. >=20 > Best regards > Michael >>=20 >> Then browsers need to do the conversion from utf-16 DOMstring to = utf-8 before writing on wire also in the reverse direction. >>=20 >> -Raju >>=20 >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Friday, February 07, 2014 6:01 PM >>> To: Martin Thomson; Makaraju, Maridi Raju (Raju) >>> Cc: rtcweb@ietf.org >>> Subject: RE: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data = Channel: >>> Usage of PPID for protocol multiplexing) >>>=20 >>>=20 >>> + 1 >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> ________________________________________ >>> From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Martin Thomson >>> [martin.thomson@gmail.com] >>> Sent: Saturday, 08 February 2014 1:45 AM >>> To: Makaraju, Maridi Raju (Raju) >>> Cc: rtcweb@ietf.org >>> Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data = Channel: >>> Usage of PPID for protocol multiplexing) >>>=20 >>> I don't think that we need any complication here. It's a string. >>>=20 >>> Strings are UTF-8 on the wire. >>>=20 >>> Strings are UTF-16 (mostly) in JavaScript. >>>=20 >>> Anything else would generate pain. >>>=20 >>> On 7 February 2014 14:01, Makaraju, Maridi Raju (Raju) >>> wrote: >>>>>>> Also, I think "DOMString" PPID is too specific to Javascript, = instead >>> it >>>>> should probably have a generic name like "UTF-16 String". The send = API >>> can >>>>> still use DOMString as this is Javascript API. >>>>>> Any comments from others? >>>>>=20 >>>>> Note: The WebSockets protocol defines the transferred strings as = UTF-8. >>>>> http://tools.ietf.org/html/rfc6455#section-5.6 >>>>>=20 >>>>> As far as I can tell, we've always intended to follow that = example. >>>>>=20 >>>>> The fact that Javascript implementations currently choose to = represent >>>>> text strings as UTF-16 at their API is sad, but not an argument = for >>>>> sending that particular text representation over the wire, or = reflecting >>>>> the name in the API. >>>>=20 >>>> [Raju] I agree that using UTF-8 is desired and more appropriate! = Then, >>> should the PPID be changed from "DOMString" to "UTF-8"? Javascript = based >>> apps have to use some library to do the conversion of = DOMString/UTF-16 to >>> UTF-8. Alternatively, browsers can do this conversion under the APIs = (send >>> and onmessage) before sending and after receiving UTF-8 PPID data. >>>> Without such conversion webrtc interworking between browsers and = native >>> clients will be problematic (basically, will not work). >>>>=20 >>>> Another option, which is more flexible, is to define PPIDs for = different >>> encodings like "UTF-8", "UTF-16" (or even "base64" for binary to = text >>> instead of using "binary" directly); then pass this encoding = information to >>> send() and onmessage() calls, which will use these PPIDs. Passing = encoding >>> information might be implicit (like Javavscript DOMString) in most = languages >>> by the type of the argument to send. This way it is upto the = application to >>> deal with the encoding conversions as it see fits. >>>>=20 >>>> The latter approach is best suitable for interworking between = clients of >>> similar type (web or native); but it is bit painful (to do = conversions) for >>> clients of different types. >>>>=20 >>>> I am wondering what kind of API calls native WebRTC API stacks = (e.g. >>> Google Chrome's http://www.webrtc.org/webrtc-native-code-package) = provide >>> for data channel send/onmessage ()? UTF-16 strings? Or UTF-8? >>>>=20 >>>> -Raju >>>>=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 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 >=20 From partha@parthasarathi.co.in Sat Feb 8 02:07: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 3E6D51A05E0 for ; Sat, 8 Feb 2014 02:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.333 X-Spam-Level: *** X-Spam-Status: No, score=3.333 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MANGLED_NOTICE=2.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 4HX-4bHzeDaw for ; Sat, 8 Feb 2014 02:07:14 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.235]) by ietfa.amsl.com (Postfix) with ESMTP id 11ACB1A0456 for ; Sat, 8 Feb 2014 02:07:13 -0800 (PST) Received: from userPC (unknown [122.167.125.187]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id F2AF06392B5; Sat, 8 Feb 2014 10:07:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1391854033; bh=h5YCfGT8QXUYD4O4+i2jhYEvQBL6gCK/0o0ku2YDRa0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=hGVSB67MT3ba9kdwijqrAt0ad9XuedZ5uyCbYP3OAMd7V0cwgmMnVNnaWuxWdSoEL SWyvFlD63wKR5js25HAM7yeicwQIkjNKFxMEh0GSb+3vTJjt6lKgXNglvFvzrRD6lL WMtESK09LSQDU/338uSJXwNVyS+HzNXHquzTWPnM= From: "Parthasarathi R" To: "'Harald Alvestrand'" , References: <3A5DAAA1FDD9764EAA3B2A633A91A0495F8B49D5@xmb-aln-x15.cisco.com> <52F43DF3.1020401@alvestrand.no> <007401cf2421$58729a20$0957ce60$@co.in> <52F52016.2060703@alvestrand.no> In-Reply-To: <52F52016.2060703@alvestrand.no> Date: Sat, 8 Feb 2014 15:37:03 +0530 Message-ID: <004801cf24b5$86777550$93665ff0$@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: Ac8kLwVrFf1lRMkvQcmWxhxY0gRGdgAgmuJw Content-Language: en-us X-CTCH-RefID: str=0001.0A020201.52F601D1.0074, 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 70.87.28.142 Subject: Re: [rtcweb] ice-lite in 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: Sat, 08 Feb 2014 10:07:15 -0000 Hi Harald & all, I agree with Harald that WebRTC Endpoints requirements has to be frozen = before starting WebRTC Server/Gateway guidelines documents. I guess that = draft-ietf-rtcweb-use-cases-and-requirements document open items will be = closed during IETF-89 based on the current open items. I'll write the strawman proposal after IETF-89 to start the discussion. = I'm interested in hearing anybody else interested in contributing for = the same. Thanks Partha > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Friday, February 07, 2014 11:34 PM > To: Parthasarathi R; rtcweb@ietf.org > Subject: Re: [rtcweb] ice-lite in WebRTC ??? >=20 > On 02/07/2014 05:26 PM, Parthasarathi R wrote: > > > The server doesn't have to claim WebRTC conformance, it = just > has to > >> claim to interoperate with WebRTC endpoints. > > The above assumption leads to lot of confusion in WebRTC Server > implementation which starts from RTCWeb requirement itself. IMO, it is > better to provide the minimum IETF standard guidelines for WebRTC > servers like ice-lite/ICE, BUNDLE required or not, ICE-TCP/TURN. >=20 > It seems to me like a good document to write, but should probably be > done after we finish the requirements for WebRTC endpoints. >=20 > Unless someone wishes to start one, of course. From sergio.garcia.murillo@gmail.com Sat Feb 8 03:23: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 6D6571A05EF for ; Sat, 8 Feb 2014 03:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_NOTICE=2.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 kRpq4Lp_82F3 for ; Sat, 8 Feb 2014 03:23:38 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id D0BCE1A020B for ; Sat, 8 Feb 2014 03:23:37 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q58so2968897wes.38 for ; Sat, 08 Feb 2014 03:23:36 -0800 (PST) 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=AyH3T6urXBbT9jy5g62Mpqo4IPqDAPz4/5CMvTYv8I0=; b=R/UJ1WFQp7Gc1h5sqdPq7zRjnpm302jor1wEm3IdnkCpAu+S2cxB06HNBDJUpDGsrA 0i6ZrbKyp04WgOocWLKmPNp3d62Y1JneDs+rbYNEWEd2k6HBu3d3qtkZ63wiE4uzVqAy 1az/kptGKPcKcxcYFV9DIWsV4MBroa0I8CxaPBnoAaW8bh985e4bZpKqGI7fxeaXsdSx XCpsOFfVQ+4uJ+C6A66KZtrm08BWIrhHQPU/G85sFH6fiTfsz2FomPJ4aWIm2DXMs5W+ KYQIzJyk1lNAPK/WiIxBupZM965bKId2ckbq11Ufkd4EYU4UCam79+ohegPpARN3lBnq iOIA== X-Received: by 10.194.142.170 with SMTP id rx10mr14382043wjb.13.1391858616714; Sat, 08 Feb 2014 03:23:36 -0800 (PST) Received: from [192.168.0.192] ([95.61.111.78]) by mx.google.com with ESMTPSA id q2sm17979507wjq.0.2014.02.08.03.23.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Feb 2014 03:23:35 -0800 (PST) Message-ID: <52F613BC.1050204@gmail.com> Date: Sat, 08 Feb 2014 12:23:40 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <3A5DAAA1FDD9764EAA3B2A633A91A0495F8B49D5@xmb-aln-x15.cisco.com> <52F43DF3.1020401@alvestrand.no> <007401cf2421$58729a20$0957ce60$@co.in> <52F52016.2060703@alvestrand.no> <004801cf24b5$86777550$93665ff0$@co.in> In-Reply-To: <004801cf24b5$86777550$93665ff0$@co.in> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] ice-lite in 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: Sat, 08 Feb 2014 11:23:39 -0000 Hi Partha, I have quite some real life experience on webrtc server side implementation, so count on me. Best regards Sergio El 08/02/2014 11:07, Parthasarathi R escribió: > Hi Harald & all, > > I agree with Harald that WebRTC Endpoints requirements has to be frozen before starting WebRTC Server/Gateway guidelines documents. I guess that draft-ietf-rtcweb-use-cases-and-requirements document open items will be closed during IETF-89 based on the current open items. > > I'll write the strawman proposal after IETF-89 to start the discussion. I'm interested in hearing anybody else interested in contributing for the same. > > Thanks > Partha > >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Friday, February 07, 2014 11:34 PM >> To: Parthasarathi R; rtcweb@ietf.org >> Subject: Re: [rtcweb] ice-lite in WebRTC ??? >> >> On 02/07/2014 05:26 PM, Parthasarathi R wrote: >>> > The server doesn't have to claim WebRTC conformance, it just >> has to >>>> claim to interoperate with WebRTC endpoints. >>> The above assumption leads to lot of confusion in WebRTC Server >> implementation which starts from RTCWeb requirement itself. IMO, it is >> better to provide the minimum IETF standard guidelines for WebRTC >> servers like ice-lite/ICE, BUNDLE required or not, ICE-TCP/TURN. >> >> It seems to me like a good document to write, but should probably be >> done after we finish the requirements for WebRTC endpoints. >> >> Unless someone wishes to start one, of course. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From Raju.Makaraju@alcatel-lucent.com Sat Feb 8 05:45: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 E15881A030B for ; Sat, 8 Feb 2014 05:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-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 GJmxMz_N4t0U for ; Sat, 8 Feb 2014 05:45:10 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5771A0309 for ; Sat, 8 Feb 2014 05:45:10 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s18Dj6IL015960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 8 Feb 2014 07:45:07 -0600 (CST) 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 s18Dj6Sj024885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Feb 2014 08:45:06 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Sat, 8 Feb 2014 08:45:06 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Michael Tuexen Thread-Topic: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) Thread-Index: AQHPI5G5uqx5hsIOAEq9u24GTLgZVJqqTeJQgAB8IwCAAARsAP//vsSQgADcd4CAAAKUgP//7a+g Date: Sat, 8 Feb 2014 13:45:05 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <52F4182F.60404@alvestrand.no> , <7594FB04B1934943A5C02806D1A2204B1D163B26@ESESSMB209.ericsson.se> , <23A98499-FA93-472A-B762-92BF72EAC2F1@lurchi.franken.de> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Feb 2014 13:45:14 -0000 > We could have an informative note somewhere.in the draft, pointing out th= e > format used by JavaScript, if people think it would be useful. [Raju] The format used by Javascript is already documented in http://dev.w3= .org/2011/webrtc/editor/webrtc.html#idl-def-RTCSessionDescription via various API calls: void send (DOMString data); void send (Blob data); void send (ArrayBuffer data); void send (ArrayBufferView data); As long as browser+javascript is used by both webrtc clients the receiving = gets these formats in onmessage () callback (NOTE: please see exceptions be= low). So, what goes/comes on wire is controlled by browser to give the applicatio= n suitable format.=20 If one side is a non-browser/javascript webrtc client then the wire format = really matters, for which the Data Channel Core spec will have a note (per = discussion and agreement). The spec is already assuming, though not explictly, onwire UTF-8 format whi= le doing "bufferedAmount" calculations. This is evident from the note: "bufferedAmount of type unsigned long, readonly The bufferedAmount attribute must return the number of bytes of application= data (UTF-8 text and binary data) that have been queued using send() but t= hat, as of the last time the event loop started executing a task, had not y= et been transmitted to the network." May be an additional explicit note in the above text about "onwire format i= s UTF-8" makes it very clear!? Coming back to http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTC= SessionDescription : As shown above the API has send() API which takes Blob or ArrayBuffer or Ar= rayBufferView as arguments. Now since there will only be one "binary" PPID = defined, all these maps to it. Assuming browser on the other end, how does = it knows which type of data type to give in the onmessage() callback? Is th= ere any expectation on the other end it gets same data type? I guess not! O= ther end may always default to using "Blob". In either case, we need a note= here about the data type to be expected in onmessage(), which may always b= e "Blob"/binary or "DOMString"/text?! -Raju From christer.holmberg@ericsson.com Sat Feb 8 08:00: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 2FCC21A040B for ; Sat, 8 Feb 2014 08:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 KCRE7R1f6jkT for ; Sat, 8 Feb 2014 08:00:03 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3B33C1A03A5 for ; Sat, 8 Feb 2014 08:00:03 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-1e-52f654827468 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 06.9C.23809.28456F25; Sat, 8 Feb 2014 17:00:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Sat, 8 Feb 2014 17:00:02 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Michael Tuexen" Thread-Topic: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) Thread-Index: AQHPI5G4gedSwhADR0Wr7uzX17tRu5qqSHkAgAAc9wCAABUk/4AAA9sAgACGp4CAABNZEIAAN5uAgAA2Dto= Date: Sat, 8 Feb 2014 16:00:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D164897@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <52F4182F.60404@alvestrand.no> , <7594FB04B1934943A5C02806D1A2204B1D163B26@ESESSMB209.ericsson.se> , <23A98499-FA93-472A-B762-92BF72EAC2F1@lurchi.franken.de> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvjW5TyLcgg7N7bCyunfnHaHGxaQmj RcPGK6wWa/+1szuweLQ+28vqsXPWXXaPJUt+MnlsaNnBFMASxWWTkpqTWZZapG+XwJWx9/Ub 5oIrohUXDreyNDCeE+xi5OSQEDCRWDxrOxOELSZx4d56NhBbSOAQo8THw7VdjFxA9iJGiU0P Olm7GDk42AQsJLr/aYPUiAjUSBxZN48FxGYWCJF4ePYdM4gtLFAqcWffNDaQchGBMon9Ww0g ypMkJtxcDLaKRUBFYsvEvawgNq+Ar0THjI/MEKu+sEk83tgNVsQpECvRsmMNO4jNCHTb91Nr mCB2iUvcejIf6mYBiSV7zjND2KISLx//Y4WwFSU+vtrHCFGvI7Fg9yc2CFtbYtnC18wQiwUl Ts58wjKBUWwWkrGzkLTMQtIyC0nLAkaWVYzsuYmZOenlRpsYgZF0cMtv1R2Md86JHGKU5mBR Euf98NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjbVqM0+7LerJLv8810Ft1X5rTc7pT iVbhLeNZJt+0XQtZhUTsMvl/rdgure/JsyvaQin8ffkvlq0u62dNXdmwr+LW1J3nhRuW31oy q25jCmu0b63U/rtcc/vk5hS8kOhX+rFMyrnjsA+z3dHAptuBG4SE//atvcW4rmJX/uG2ly1n kjIyF/9VYinOSDTUYi4qTgQAyXW15HICAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Feb 2014 16:00:06 -0000 Hi, Without commenting on specifics: we shall NOT have a mechanism where one si= de needs to know whether the remote peer is a browswer or not. The data cha= nnel mechanism itself shall be generic. Regards, Christer ________________________________________ From: Makaraju, Maridi Raju (Raju) [Raju.Makaraju@alcatel-lucent.com] Sent: Saturday, 08 February 2014 3:45 PM To: Christer Holmberg; Michael Tuexen Cc: Martin Thomson; rtcweb@ietf.org Subject: RE: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: = Usage of PPID for protocol multiplexing) > We could have an informative note somewhere.in the draft, pointing out th= e > format used by JavaScript, if people think it would be useful. [Raju] The format used by Javascript is already documented in http://dev.w3= .org/2011/webrtc/editor/webrtc.html#idl-def-RTCSessionDescription via various API calls: void send (DOMString data); void send (Blob data); void send (ArrayBuffer data); void send (ArrayBufferView data); As long as browser+javascript is used by both webrtc clients the receiving = gets these formats in onmessage () callback (NOTE: please see exceptions be= low). So, what goes/comes on wire is controlled by browser to give the applicatio= n suitable format. If one side is a non-browser/javascript webrtc client then the wire format = really matters, for which the Data Channel Core spec will have a note (per = discussion and agreement). The spec is already assuming, though not explictly, onwire UTF-8 format whi= le doing "bufferedAmount" calculations. This is evident from the note: "bufferedAmount of type unsigned long, readonly The bufferedAmount attribute must return the number of bytes of application= data (UTF-8 text and binary data) that have been queued using send() but t= hat, as of the last time the event loop started executing a task, had not y= et been transmitted to the network." May be an additional explicit note in the above text about "onwire format i= s UTF-8" makes it very clear!? Coming back to http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTC= SessionDescription : As shown above the API has send() API which takes Blob or ArrayBuffer or Ar= rayBufferView as arguments. Now since there will only be one "binary" PPID = defined, all these maps to it. Assuming browser on the other end, how does = it knows which type of data type to give in the onmessage() callback? Is th= ere any expectation on the other end it gets same data type? I guess not! O= ther end may always default to using "Blob". In either case, we need a note= here about the data type to be expected in onmessage(), which may always b= e "Blob"/binary or "DOMString"/text?! -Raju From Raju.Makaraju@alcatel-lucent.com Sat Feb 8 08:38: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 1795F1A040A for ; Sat, 8 Feb 2014 08:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 FLJjRtlDz678 for ; Sat, 8 Feb 2014 08:38:40 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2BC1A03CC for ; Sat, 8 Feb 2014 08:38:40 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s18Gcb1d018857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 8 Feb 2014 10:38:38 -0600 (CST) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s18GcbNo022412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Feb 2014 11:38:37 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Sat, 8 Feb 2014 11:38:37 -0500 From: "Makaraju, Maridi Raju (Raju)" To: "christer.holmberg@ericsson.com" , "michael.tuexen@lurchi.franken.de" Thread-Topic: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) Thread-Index: AQHPI5G5uqx5hsIOAEq9u24GTLgZVJqqTeJQgAB8IwCAAARsAP//vsSQgADcd4CAAAKUgP//7a+ggACAZQD//7b2SQ== Date: Sat, 8 Feb 2014 16:38:37 +0000 Message-ID: <0AD62566-EF8C-4E2B-85D3-CA0C33536906@alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <52F4182F.60404@alvestrand.no> , <7594FB04B1934943A5C02806D1A2204B1D163B26@ESESSMB209.ericsson.se> , <23A98499-FA93-472A-B762-92BF72EAC2F1@lurchi.franken.de> , , <7594FB04B1934943A5C02806D1A2204B1D164897@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D164897@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0AD62566EF8C4E2B85D3CA0C33536906alcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Feb 2014 16:38:43 -0000 --_000_0AD62566EF8C4E2B85D3CA0C33536906alcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, et. al., I completely agree and that's the intention of having just two PPIDs, one f= or text and one for binary. However, it would be good to have the clarifica= tions that I mentioned in my earlier reply. I have a general comment on some of the non-browser/javascript webrtc specs= assuming, unnecessarily, browser+javascript as the client, which leads to = some confusion like utf-8 vs DOMString confusion. It would be nice if these= specs make it generic to apply all webrtc clients: either browser, native = or hybrid. In future I will point these places as I review the relevant spe= cs. But it would be great if authors keep this mind. Regards -Raju ----- Reply message ----- From: "Christer Holmberg" Date: Sat, Feb 8, 2014 10:00 am Subject: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usag= e of PPID for protocol multiplexing) To: "Makaraju, Maridi Raju (Raju)" , "Mic= hael Tuexen" Cc: "rtcweb@ietf.org" Hi, Without commenting on specifics: we shall NOT have a mechanism where one si= de needs to know whether the remote peer is a browswer or not. The data cha= nnel mechanism itself shall be generic. Regards, Christer ________________________________________ From: Makaraju, Maridi Raju (Raju) [Raju.Makaraju@alcatel-lucent.com] Sent: Saturday, 08 February 2014 3:45 PM To: Christer Holmberg; Michael Tuexen Cc: Martin Thomson; rtcweb@ietf.org Subject: RE: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: = Usage of PPID for protocol multiplexing) > We could have an informative note somewhere.in the draft, pointing out th= e > format used by JavaScript, if people think it would be useful. [Raju] The format used by Javascript is already documented in http://dev.w3= .org/2011/webrtc/editor/webrtc.html#idl-def-RTCSessionDescription via various API calls: void send (DOMString data); void send (Blob data); void send (ArrayBuffer data); void send (ArrayBufferView data); As long as browser+javascript is used by both webrtc clients the receiving = gets these formats in onmessage () callback (NOTE: please see exceptions be= low). So, what goes/comes on wire is controlled by browser to give the applicatio= n suitable format. If one side is a non-browser/javascript webrtc client then the wire format = really matters, for which the Data Channel Core spec will have a note (per = discussion and agreement). The spec is already assuming, though not explictly, onwire UTF-8 format whi= le doing "bufferedAmount" calculations. This is evident from the note: "bufferedAmount of type unsigned long, readonly The bufferedAmount attribute must return the number of bytes of application= data (UTF-8 text and binary data) that have been queued using send() but t= hat, as of the last time the event loop started executing a task, had not y= et been transmitted to the network." May be an additional explicit note in the above text about "onwire format i= s UTF-8" makes it very clear!? Coming back to http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTC= SessionDescription : As shown above the API has send() API which takes Blob or ArrayBuffer or Ar= rayBufferView as arguments. Now since there will only be one "binary" PPID = defined, all these maps to it. Assuming browser on the other end, how does = it knows which type of data type to give in the onmessage() callback? Is th= ere any expectation on the other end it gets same data type? I guess not! O= ther end may always default to using "Blob". In either case, we need a note= here about the data type to be expected in onmessage(), which may always b= e "Blob"/binary or "DOMString"/text?! -Raju _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_0AD62566EF8C4E2B85D3CA0C33536906alcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Christer, et. al.,
I completely agree and that's the intention of having just two PPIDs, one f= or text and one for binary. However, it would be good to have the clarifica= tions that I mentioned in my earlier reply.
I have a general comment on some of the non-browser/javascript webrtc specs= assuming, unnecessarily, browser+javascript as the client, which leads= to some confusion like utf-8 vs DOMString confusion. It would be nice if t= hese specs make it generic to apply all webrtc clients: either browser, native or hybrid. In future I will poi= nt these places as I review the relevant specs. But it would be great if au= thors keep this mind.

Regards
-Raju

----- Reply message -----
From: "Christer Holmberg" <christer.holmberg@ericsson.com><= br> Date: Sat, Feb 8, 2014 10:00 am
Subject: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usag= e of PPID for protocol multiplexing)
To: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-luce= nt.com>, "Michael Tuexen" <Michael.Tuexen@lurchi.franken.de= >
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>


Hi,

Without commenting on specifics: we shall NOT have a mechanism where one si= de needs to know whether the remote peer is a browswer or not. The data cha= nnel mechanism itself shall be generic.

Regards,

Christer



________________________________________
From: Makaraju, Maridi Raju (Raju) [Raju.Makaraju@alcatel-lucent.com]
Sent: Saturday, 08 February 2014 3:45 PM
To: Christer Holmberg; Michael Tuexen
Cc: Martin Thomson; rtcweb@ietf.org
Subject: RE: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: = Usage of PPID for protocol multiplexing)

> We could have an informative note somewhere.in the draft, pointing out= the
> format used by JavaScript, if people think it would be useful.

[Raju] The format used by Javascript is already documented in http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCSessionDescript= ion
via various API calls:
    void send (DOMString data);
    void send (Blob data);
    void send (ArrayBuffer data);
    void send (ArrayBufferView data);

As long as browser+javascript is used by both webrtc clients the receiv= ing gets these formats in onmessage () callback (NOTE: please see exception= s below).
So, what goes/comes on wire is controlled by browser to give the applicatio= n suitable format.
If one side is a non-browser/javascript webrtc client then the wire format = really matters, for which the Data Channel Core spec will have a note (per = discussion and agreement).

The spec is already assuming, though not explictly, onwire UTF-8 format whi= le doing "bufferedAmount" calculations. This is evident from the = note:

"bufferedAmount of type unsigned long, readonly
The bufferedAmount attribute must return the number of bytes of application= data (UTF-8 text and binary data) that have been queued using send() but t= hat, as of the last time the event loop started executing a task, had not y= et been transmitted to the network."

May be an additional explicit note in the above text about "onwire for= mat is UTF-8" makes it very clear!?

Coming back to http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCSessionDescript= ion :
As shown above the API has send() API which takes Blob or ArrayBuffer or Ar= rayBufferView as arguments. Now since there will only be one "binary&q= uot; PPID defined, all these maps to it. Assuming browser on the other end,= how does it knows which type of data type to give in the onmessage() callback? Is there any expectation on the other= end it gets same data type? I guess not! Other end may always default to u= sing "Blob". In either case, we need a note here about the data t= ype to be expected in onmessage(), which may always be "Blob"/binary or "DOMString"/text?!


-Raju
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb
 --_000_0AD62566EF8C4E2B85D3CA0C33536906alcatellucentcom_-- From randell-ietf@jesup.org Sat Feb 8 12:24: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 542FF1A055F for ; Sat, 8 Feb 2014 12:24:10 -0800 (PST) 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_50=0.8, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 Kj0kA1v2RNri for ; Sat, 8 Feb 2014 12:24:09 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id DF4161A05D7 for ; Sat, 8 Feb 2014 12:24:07 -0800 (PST) Received: from [12.131.214.70] (port=60273 helo=[10.0.0.14]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCERc-000GLo-0N for rtcweb@ietf.org; Sat, 08 Feb 2014 14:24:08 -0600 Message-ID: <52F69278.4000401@jesup.org> Date: Sat, 08 Feb 2014 12:24:24 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <52F4182F.60404@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Feb 2014 20:24:10 -0000 On 2/7/2014 6:45 PM, Martin Thomson wrote: > I don't think that we need any complication here. It's a string. > > Strings are UTF-8 on the wire. > > Strings are UTF-16 (mostly) in JavaScript. > > Anything else would generate pain. (Back online while traveling; been off mostly due to extended power outage in Philadelphia suburbs) 100% agree. And currently that's what we do in Firefox at the JS->protocol interface: void nsDOMDataChannel::Send(const nsAString& aData, ErrorResult& aRv) { NS_ConvertUTF16toUTF8 msgString(aData); Send(nullptr, msgString, msgString.Length(), false, aRv); } The JS interface matches WebSockets Send(). The wireline interface is (and should be) UTF8; any registrations should be updated to make this clear. -- Randell Jesup randell-ietf@jesup.org From Michael.Tuexen@lurchi.franken.de Sat Feb 8 12:35: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 4596C1A048E for ; Sat, 8 Feb 2014 12:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_47=0.6, RP_MATCHES_RCVD=-0.548, 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 xBJqMgXY9OBu for ; Sat, 8 Feb 2014 12:35:36 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id DCA0E1A0447 for ; Sat, 8 Feb 2014 12:35:35 -0800 (PST) Received: from [192.168.1.200] (p5481B04C.dip0.t-ipconnect.de [84.129.176.76]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D8EBC1C0B303E; Sat, 8 Feb 2014 21:35:34 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <52F69278.4000401@jesup.org> Date: Sat, 8 Feb 2014 21:35:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <52F4182F.60404@alvestrand.no> <52F69278.4000401@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1510) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Feb 2014 20:35:38 -0000 On Feb 8, 2014, at 9:24 PM, Randell Jesup = wrote: > On 2/7/2014 6:45 PM, Martin Thomson wrote: >> I don't think that we need any complication here. It's a string. >>=20 >> Strings are UTF-8 on the wire. >>=20 >> Strings are UTF-16 (mostly) in JavaScript. >>=20 >> Anything else would generate pain. >=20 > (Back online while traveling; been off mostly due to extended power = outage in Philadelphia suburbs) >=20 > 100% agree. And currently that's what we do in Firefox at the = JS->protocol interface: >=20 > void > nsDOMDataChannel::Send(const nsAString& aData, ErrorResult& aRv) > { > NS_ConvertUTF16toUTF8 msgString(aData); > Send(nullptr, msgString, msgString.Length(), false, aRv); > } >=20 > The JS interface matches WebSockets Send(). The wireline interface is = (and should be) UTF8; any registrations should be updated to make this = clear. Great. I'll update the spec. Let's change the name of the PPID... Best regards Michael >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From pkyzivat@alum.mit.edu Sun Feb 9 10:38: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 AB3C01A0446 for ; Sun, 9 Feb 2014 10:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 pQVtIg7hGl6X for ; Sun, 9 Feb 2014 10:37:59 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 88E561A046A for ; Sun, 9 Feb 2014 10:37:57 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA11.westchester.pa.mail.comcast.net with comcast id QHab1n0091HzFnQ5BJdxWT; Sun, 09 Feb 2014 18:37:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id QJdx1n00F3ZTu2S3aJdxTr; Sun, 09 Feb 2014 18:37:57 +0000 Message-ID: <52F7CB05.3090106@alum.mit.edu> Date: Sun, 09 Feb 2014 13:37:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <4CE22DF8-DE34-400A-95AE-2E011828DE88@lurchi.franken.de> <52F3B7A5.6070105@alum.mit.edu>, <3B7B334C-868A-4128-B7BF-07C66B649443@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D160930@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D160A98@ESESSMB209.ericsson.se> <75145993-7226-4C5D-845C-A96D51D3D68B@lurchi.franken.de> <52F4189B.3020309@alvestrand.no> In-Reply-To: <52F4189B.3020309@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391971077; bh=RdlCT0htHK4off10ReL5G2zx0KvdropRWvpIYd0owbo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=W7QIp527b9FaEJtukIVMOvexmLw4pfvxZxRXvP1zAwSt+AxeJ93BzQR0P3Q0y7VVZ 3Vu6dbMaifN2qCdbIt4mH1zkueoGXgdgssqJR2eHzc+wcPj+8m18Rw0txj47UZZv9y s5peW+NgOFjyh2JWweY5cqA03eUu8LfKnm4Ji0V91QpYfhQ+LThhTE93o9OcBP0il8 vp8DE7MSYEPuuCNB3PnqrM6EFunm600hvJLhffocaOaIfYJis/JZ80H/Sp3iHjbDt5 oboA8o3W4lqPtDDWbOpQDOq8S1ktLUXvz42bmHyN/fUVh0XK0GEMgL2hhSIF2Uk09U gWJzmfrKriD2Q== Subject: Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 09 Feb 2014 18:38:00 -0000 On 2/6/14 6:19 PM, Harald Alvestrand wrote: > On 02/06/2014 09:47 PM, Michael Tuexen wrote: >> On Feb 6, 2014, at 9:35 PM, Christer Holmberg wrote: >> >>> Hi, >>> >>>>>>> I hope that if values are retained simply for backward compatibility they are explicitly marked as deprecated. >>>>>> My plan was just not to defined what they are used for... >>>>> I would like to have some explanation text. Having registered values without any kind of explanation is not a good approach, in my opinion. >>>> The reason why I registered them is that they are used by Firefox and there was >>>> the possibility that the PPID based fragmentation and reassembly got >>>> standardised. I wanted to avoid the case that Firefox uses some values >>>> and other protocols register these values. That would have been pretty >>>> bad. Since they are a very cheap resource, I just went ahead and "saved" >>>> the values. >>> That is a all good. But, when people wonder 5 years from now, I don't want them to have to look for this e-mail in oder to get an explanation :) >> Understood. But do you think they walk through the IANA registry? I would expect them >> to read RFCs and follow the procedures described there. > > Updating the registry to read "Obsolete; was used by " > should satisfy all comers. > > People do read registries. Yes. In some cases the registry is how you discover what RFC to read. Maybe five years from now, somebody debugging some app gets one of these values, and doesn't know what it means. It won't be mentioned in any of the current RFCs he has read, because none of them use it. So he ends up looking in the registry to find where it is defined. Thanks, Paul From internet-drafts@ietf.org Sun Feb 9 13:17: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 762861A0464; Sun, 9 Feb 2014 13:17:01 -0800 (PST) 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 yc0Zpt-CSxzF; Sun, 9 Feb 2014 13:16:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D946E1A032B; Sun, 9 Feb 2014 13:16:59 -0800 (PST) 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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140209211659.26091.94840.idtracker@ietfa.amsl.com> Date: Sun, 09 Feb 2014 13:16:59 -0800 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-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: Sun, 09 Feb 2014 21:17: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 : WebRTC Data Channel Protocol Authors : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-protocol-02.txt Pages : 12 Date : 2014-02-09 Abstract: The Web Real-Time Communication (WebRTC) working group is charged to provide protocols to 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-protocol-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 tuexen@fh-muenster.de Sun Feb 9 13:17: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 0BC8D1A0488 for ; Sun, 9 Feb 2014 13:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 ghyodyiWzImH for ; Sun, 9 Feb 2014 13:17:25 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 63E681A0447 for ; Sun, 9 Feb 2014 13:17:24 -0800 (PST) Received: from [192.168.1.200] (p54819372.dip0.t-ipconnect.de [84.129.147.114]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 5B1F71C0E97A0; Sun, 9 Feb 2014 22:17:22 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <52823111.9010701@ericsson.com> Date: Sun, 9 Feb 2014 22:17:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6A8DE43F-C4F7-41EA-9017-6F1B20F73CF3@fh-muenster.de> References: <52823111.9010701@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Sun, 09 Feb 2014 15:31:11 -0800 Cc: draft-ietf-rtcweb-data-protocol@tools.ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-protocol-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 09 Feb 2014 21:17:28 -0000 On Nov 12, 2013, at 2:45 PM, Magnus Westerlund = wrote: > Hi, >=20 > I did review the Data Channel Protocol on my way to IETF, and here are > my comments. Hi Magnus, thank you very much for the comments. I've submitted a new version = according to the comments below. >=20 > 1. Section 4: >=20 > o the outgoing SCTP stream. >=20 > What about incoming SCTP stream? Changed to "the SCTP streams." >=20 > 2. Section 4: > The data channel protocol uses a two way handshake to open a data > channel. The side wanting to open a data channel selects an unused > Stream and sends a DATA_CHANNEL_OPEN message. The peer responds = with > a DATA_CHANNEL_ACK message. Then the data channel is open. Please > note that the opening side can send user messages before the > DATA_CHANNEL_ACK is received. These data channel messages are sent > on the same Stream as the user messages belonging to the data > channel. The demultiplexing is based on the SCTP payload protocol > identifier. >=20 > I find this paragraph a bit confusing on the following things: >=20 > A. Is the DATA_CHANNEL_OPEN message sent on that selected stream? > B. Is the DATA_CHANNEL_ACK sent on the peers corresponding stream = number > as the DATA_CHANNEL_OPEN was received on? > C. "These data channel messages" does this refer to > DATA_CHANNEL_OPEN/ACK, maybe be more explicit. > D. "The demultiplexing is based on the SCTP payload protocol > identifier." Do you mean PPIDs here. And could you be more explicit > about of how this works. Am I wrong in the understanding that you have > have one PPID for this control protocol. But, you are not explicit = about > if which PPID user messages could use. OK, I have updated the above paragraph: The data channel protocol uses a two way handshake to open a data = channel by combining two SCTP streams, one in each direction, with the same SCTP stream identifier. The side wanting to open a data channel selects an SCTP stream = identifier for which the corresponding incoming and outgoing SCTP stream is unused and sends a DATA_CHANNEL_OPEN message on this outgoing SCTP stream. The peer responds with a DATA_CHANNEL_ACK message on its corresponding outgoing SCTP stream. Then the data channel is open. Please note that the opening side can send user messages before the DATA_CHANNEL_ACK is received. Data channel control messages are sent on the same Stream as the user messages belonging to the data channel. The demultiplexing is based on the SCTP payload protocol identifier = (PPID), since the data channel control protocol uses a specific PPID. >=20 > 3. Section 4: > The protocol field is to ease cross-application interoperation > ("federation") by identifying the data being passed with an IANA- > registered string, and may be useful for homogenous applications > which may create more than one type of Channel. >=20 > One more case where I think it is fuzzy what is refered to. Is the > "protocol field" an identifier for the PPID to use, or something else? No, it is something different. > What type of IANA registered string is being used here? Which registry > and field value are referenced? The one defined in Section 8.4. >=20 > 4. Section 5.1: > Priority: 2 bytes (integer) > The priority of the channel. >=20 > What is the definition of the priority field value? It is the priority of the channel. I changed the text to: The higher the number, the lower the priority. In particular, 0 is the highest priority. However, I'm not sure if this should be unsigned. Also the W3C document doesn't specify it yet. >=20 > 5. Section 5.1: > Reliability Parameter: 4 bytes >=20 > I would recommend that you make a table under this parameter where you > make clear the interpretation of the field under differetn channel = types. OK, I have added: The following table summarises this: Channel Type Reliability Parameter DATA_CHANNEL_RELIABLE Ignored DATA_CHANNEL_RELIABLE_UNORDERED Ignored DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT Number of = RTX DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDEREDNumber of = RTX DATA_CHANNEL_PARTIAL_RELIABLE_TIMED Lifetime in = ms DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED Lifetime in = ms >=20 > 6. Section 5.1 >=20 > Protocol: Variable Length (sequence of characters) > The protocol for the channel. This may be an empty string. If > used, it is an IANA-registered protocol (see Section 8.4). >=20 > Can you please be explicit about which IANA registry that is relevant > here. What is the meaning of an empty string? There is already a reference to the registry (Section 8.4). How can it be more explicit? If you use an empty string it is unspecified. I have changed it to: The protocol for the channel. If this is an empty string the protocol us unspecified. If it is an non-empty string, it specifies an IANA-registered protocol (see ). >=20 > 7. Section 6. > What PPID shall be used when sending the user data? The document describes a protocol for opening a data channel (see first = sentence of section 4), not for using or closing it. Sending user data is done the same on all data channel, not matter how they are set up. That is why sending user data is described in draft-ietf-rtcweb-data-channel. >=20 > 8. Section 6. > Therefore, receiving an > SCTP stream reset request for a stream on which no DATA_CHANNEL_ACK > message has been received indicates to the sender of the > corresponding DATA_CHANNEL_OPEN message the failure of the data > channel setup procedure. >=20 > What is allowed to do after having received the reset on a > DATA_CHANNEL_OPEN? Can one try to send a new OPEN? Sure. I added: After also successfully resetting the corresponding outgoing SCTP stream, a new DATA_CHANNEL_OPEN message can be sent on the stream. >=20 > 9. Section 8.2: > | Reserved | 0x00 | [RFCXXXX] | > | Reserved | 0x01 | [RFCXXXX] | >=20 > Why is these values reserved, please include the motivation for this = in > the description of the registry. OK. I have added: Please note that the values 0x00 and 0x01 are reserved to avoid interoperability problems, since they have been used in earlier versions of the document. >=20 > 10. Section 8.4: > IANA is requested to create a new registration table "Protocol > Registry" for the data channel protocol to manage the "Protocol" > field of type string in DATA_CHANNEL_OPEN messages (see Section = 5.1). >=20 > "Protocol Registry" is a lousy name on a registry. Secondly, I think = the I agree that it is a lousy name, but I couldn't come up with a better = one. Maybe Randell can? Or you can? > purpose of this registry needs to be better described. Randell? Best regards Michael >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 From harald@alvestrand.no Sun Feb 9 20:57: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 E67E41A0237 for ; Sun, 9 Feb 2014 20:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] 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 QRjMH6rVQ58e for ; Sun, 9 Feb 2014 20:57:00 -0800 (PST) Received: from mork.alvestrand.no (unknown [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 80B351A0685 for ; Sun, 9 Feb 2014 20:57:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id ECF197C4BC3 for ; Mon, 10 Feb 2014 05:56:59 +0100 (CET) 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 IdQxK68FDhm4 for ; Mon, 10 Feb 2014 05:56:59 +0100 (CET) Received: from [10.1.1.234] (64-71-23-98.static.wiline.com [64.71.23.98]) by mork.alvestrand.no (Postfix) with ESMTPSA id 6221F7C4B9E for ; Mon, 10 Feb 2014 05:56:59 +0100 (CET) Message-ID: <52F85C14.7010904@alvestrand.no> Date: Mon, 10 Feb 2014 05:56:52 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <52F4182F.60404@alvestrand.no> , <7594FB04B1934943A5C02806D1A2204B1D163B26@ESESSMB209.ericsson.se> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 04:57:04 -0000 On 02/08/2014 02:14 AM, Makaraju, Maridi Raju (Raju) wrote: > That's good. Glad to see that no one liked the complex alternate option... yet! :-) > I just put it there for completeness and some discussion. > With "utf-8 on wire", which I too think is the right approach, there is some spec work todo: > 1. Define IANA utf-8 ppid. Creating a new one is better instead of replacing existing DOMString as DOMString may be used by browsers for sometime to come and also to have backward compatibility/interworking. Have you ever seen UTF-16 on the wire in the DataChannel protocol? > 2. Data channel core spec (http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06#section-6.6) need to specify explictly the wire format is utf-8. Fully agreed. > > Then browsers need to do the conversion from utf-16 DOMstring to utf-8 before writing on wire also in the reverse direction. > > -Raju > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Friday, February 07, 2014 6:01 PM >> To: Martin Thomson; Makaraju, Maridi Raju (Raju) >> Cc: rtcweb@ietf.org >> Subject: RE: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: >> Usage of PPID for protocol multiplexing) >> >> >> + 1 >> >> Regards, >> >> Christer >> >> ________________________________________ >> From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Martin Thomson >> [martin.thomson@gmail.com] >> Sent: Saturday, 08 February 2014 1:45 AM >> To: Makaraju, Maridi Raju (Raju) >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: >> Usage of PPID for protocol multiplexing) >> >> I don't think that we need any complication here. It's a string. >> >> Strings are UTF-8 on the wire. >> >> Strings are UTF-16 (mostly) in JavaScript. >> >> Anything else would generate pain. >> >> On 7 February 2014 14:01, Makaraju, Maridi Raju (Raju) >> wrote: >>>>>> Also, I think "DOMString" PPID is too specific to Javascript, instead >> it >>>> should probably have a generic name like "UTF-16 String". The send API >> can >>>> still use DOMString as this is Javascript API. >>>>> Any comments from others? >>>> Note: The WebSockets protocol defines the transferred strings as UTF-8. >>>> http://tools.ietf.org/html/rfc6455#section-5.6 >>>> >>>> As far as I can tell, we've always intended to follow that example. >>>> >>>> The fact that Javascript implementations currently choose to represent >>>> text strings as UTF-16 at their API is sad, but not an argument for >>>> sending that particular text representation over the wire, or reflecting >>>> the name in the API. >>> [Raju] I agree that using UTF-8 is desired and more appropriate! Then, >> should the PPID be changed from "DOMString" to "UTF-8"? Javascript based >> apps have to use some library to do the conversion of DOMString/UTF-16 to >> UTF-8. Alternatively, browsers can do this conversion under the APIs (send >> and onmessage) before sending and after receiving UTF-8 PPID data. >>> Without such conversion webrtc interworking between browsers and native >> clients will be problematic (basically, will not work). >>> Another option, which is more flexible, is to define PPIDs for different >> encodings like "UTF-8", "UTF-16" (or even "base64" for binary to text >> instead of using "binary" directly); then pass this encoding information to >> send() and onmessage() calls, which will use these PPIDs. Passing encoding >> information might be implicit (like Javavscript DOMString) in most languages >> by the type of the argument to send. This way it is upto the application to >> deal with the encoding conversions as it see fits. >>> The latter approach is best suitable for interworking between clients of >> similar type (web or native); but it is bit painful (to do conversions) for >> clients of different types. >>> I am wondering what kind of API calls native WebRTC API stacks (e.g. >> Google Chrome's http://www.webrtc.org/webrtc-native-code-package) provide >> for data channel send/onmessage ()? UTF-16 strings? Or UTF-8? >>> -Raju >>> >>> _______________________________________________ >>> rtcweb mailing 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 christer.holmberg@ericsson.com Mon Feb 10 02:07: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 71BF81A06BF for ; Mon, 10 Feb 2014 02:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 nzwSyYNi_AGt for ; Mon, 10 Feb 2014 02:07:18 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id CA5E41A05DE for ; Mon, 10 Feb 2014 02:07:17 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-64-52f8a4d4624e Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 50.E9.04853.4D4A8F25; Mon, 10 Feb 2014 11:07:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 11:07:16 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare Thread-Index: Ac8mR2/m3LFj8oi+SFKLxbYiytu9PA== Date: Mon, 10 Feb 2014 10:07:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D166CFA@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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D166CFAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvje7VJT+CDJ4u47RY+6+d3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGas/rGEvmGtacb93MXMD42q9LkZODgkBE4muqQsYIWwxiQv3 1rN1MXJxCAmcYJSYcmUeC4SzmFFi+r0fTF2MHBxsAhYS3f+0QRpEBNQlLj+8wA5iCwvYS6z9 /JIFpEREwEXi3g0PiBI9idt3XrKC2CwCqhIv134B28Ur4Cvx/d9bMJsRaO/3U2uYQGxmAXGJ W0/mM0HcIyCxZM95ZghbVOLl43+sELaixM6z7cwQ9fkSN2ctZYWYKShxcuYTlgmMQrOQjJqF pGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ilGyOLW4ODfdyEAvNz23RC+1KDO5 uDg/T684dRMjMDIObvlttIPx5B77Q4zSHCxK4rzXWWuChATSE0tSs1NTC1KL4otKc1KLDzEy cXBKNTBOPnhJ/+2ePr3oCc8kJF2Tb5wsebn2Hufd73smagRrZ8WENnzli3cs5bnzfXHkwz1P 3q+SL1m4yOXugpLYyA1WDBczl1yzmSI+b8uqW38e3Z91uLT1wIavK9foal3JfNj3J8r0pEfi Fndj9oPXjbLyW12f/z6/7feJFUf2h8fX6jnEGf3ISzjZr8RSnJFoqMVcVJwIAK0WP+ZaAgAA Subject: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 10:07:20 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D166CFAESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As is defined in the data channel protocol, an entity can send data once DA= TA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK is re= ceived. The draft also says that, if both endpoints send DATA_CHANNEL_OPEN at the s= ame time, using different stream id values, the result may be TWO data chan= nels, with data sent on both. However, as is also indicated, the draft does not provide a mechanism to pr= event/handle such glare situation. I personally think there shall be a way to prevent such situation, or other= wise I'm sure we are going to end up with interoperability problems. Couldn't we e.g. say that, by default, the DTLS client is responsible for s= ending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it could= even use both an even or odd stream id value. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D166CFAESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As is defined in the data channel protocol, an entit= y can send data once DATA_CHANNEL_OPEN has been sent, before the associated= DATA_CHANNEL_ACK is received.

 

The draft also says that, if both endpoints send DAT= A_CHANNEL_OPEN at the same time, using different stream id values, the resu= lt may be TWO data channels, with data sent on both.

 

However, as is also indicated, the draft does not pr= ovide a mechanism to prevent/handle such glare situation.

 

I personally think there shall be a way to prevent s= uch situation, or otherwise I’m sure we are going to end up with inte= roperability problems.

 

Couldn’t we e.g. say that, by default, the DTL= S client is responsible for sending the DATA_CHANNEL_OPEN? Then there is no= risk for glare, and it could even use both an even or odd stream id value.=

 

Regards,

 

Christer

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D166CFAESESSMB209erics_-- From btdingle@gmail.com Mon Feb 10 02: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 432AB1A06BF for ; Mon, 10 Feb 2014 02:08:22 -0800 (PST) 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 zqkf_yEwhIRs for ; Mon, 10 Feb 2014 02:08:16 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 786BE1A05DE for ; Mon, 10 Feb 2014 02:08:16 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hi5so2607435wib.8 for ; Mon, 10 Feb 2014 02:08:16 -0800 (PST) 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=4t+gjQB4LZFftUhM5xt8yorpZk5FmfBnTg43vc2A9CI=; b=q3pmIVgfdxKed5FsVc1px1GQ9DO1WQWMuqOMdXFsKrJlG9XGfdt3/DfbbplEpXkODp JmJAHOD7YOS7fWS8im2a0cpPbuZThzjEfwPatYjYWaADQUitQ3pqh6V2+pdNZ4N361AR JYX0webR0jFNOEcQycWuw2hE2IAEN/UOwKd3FmZteYHSFo/1s5dwpvkmAs6daCXL3Wjb MOF3Hi/xO2PWCwBSuhFaASpBy4y6xlUa/jFBjbsKcwrqyOgDPbWfCE9ZCTxS1Ss61wwc VLUNFRnjAyJMcD680U5BwshURXnCsoLWYc5IQwXALx+BbGiHsglQtOsS6Ss37LbthqSG osbA== X-Received: by 10.180.19.69 with SMTP id c5mr9642680wie.7.1392026895964; Mon, 10 Feb 2014 02:08:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.226 with HTTP; Mon, 10 Feb 2014 02:07:55 -0800 (PST) In-Reply-To: <20140209211659.26091.94840.idtracker@ietfa.amsl.com> References: <20140209211659.26091.94840.idtracker@ietfa.amsl.com> From: Barry Dingle Date: Mon, 10 Feb 2014 21:07:55 +1100 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=bcaec53d5a8ba6e2b104f20a849e Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-02.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, 10 Feb 2014 10:08:22 -0000 --bcaec53d5a8ba6e2b104f20a849e Content-Type: text/plain; charset=UTF-8 Protocol looks good. One small point - the title of this protocol is "WebRTC Data Channel Protocol" but the Abstract says "*This document specifies a simple protocol for establishing symmetric data channels between the peers.*" This could cause confusion between what is a Data Channel Protocol and what is an Establishing protocol. It appears that the title of this protocol should be "WebRTC Data Channel *Establishment *Protocol" in order to avoid future confusion as to its purpose. /Barry Dingle Australia On Mon, Feb 10, 2014 at 8:16 AM, 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. > > Title : WebRTC Data Channel Protocol > Authors : Randell Jesup > Salvatore Loreto > Michael Tuexen > Filename : draft-ietf-rtcweb-data-protocol-02.txt > Pages : 12 > Date : 2014-02-09 > > Abstract: > The Web Real-Time Communication (WebRTC) working group is charged to > provide protocols to 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 IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-protocol-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/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec53d5a8ba6e2b104f20a849e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Protocol looks good.

One small point - the ti= tle of this protocol is "WebRTC Data Channel Protocol" but the A= bstract says "This document specifies a simple protocol for esta= blishing symmetric data channels between the peers."=C2=A0 This could ca= use confusion between what is a Data Channel Protocol and what is an Establ= ishing protocol.

It appears that the title of this protocol should = be "WebRTC Data Channel Establishment Protocol" in order t= o avoid future confusion as to its purpose.

/Barry Dingle
Australia


On Mon, Feb 10, 2014 at 8:16 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : WebR= TC Data Channel Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Randell J= esup
=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 Salvatore Loreto
=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 Michael Tuexen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-rtcweb-data-protocol-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 12 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-02-09

Abstract:
=C2=A0 =C2=A0The Web Real-Time Communication (WebRTC) working group is char= ged to
=C2=A0 =C2=A0provide protocols to support for direct interactive rich
=C2=A0 =C2=A0communication using audio, video, and data between two peers&#= 39; web-
=C2=A0 =C2=A0browsers. =C2=A0This document specifies a simple protocol for = establishing
=C2=A0 =C2=A0symmetric data channels between the peers. =C2=A0It uses a two= way
=C2=A0 =C2=A0handshake and allows sending of user data without waiting for = the
=C2=A0 =C2=A0handshake to complete.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-dat= a-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol= -02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcw= eb-data-protocol-02


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.

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

--bcaec53d5a8ba6e2b104f20a849e-- From Michael.Tuexen@lurchi.franken.de Mon Feb 10 02:11: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 462931A07D5 for ; Mon, 10 Feb 2014 02:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548, 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 yLzQLstBLK7M for ; Mon, 10 Feb 2014 02:11:53 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA4B1A05DE for ; Mon, 10 Feb 2014 02:11:53 -0800 (PST) Received: from [192.168.1.200] (p54819372.dip0.t-ipconnect.de [84.129.147.114]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6C12A1C0B3FE4; Mon, 10 Feb 2014 11:11:52 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Mon, 10 Feb 2014 11:11:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <122F40CC-C008-4C98-9705-DAD089D6A16C@lurchi.franken.de> References: <20140209211659.26091.94840.idtracker@ietfa.amsl.com> To: Barry Dingle X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-02.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, 10 Feb 2014 10:11:56 -0000 On Feb 10, 2014, at 11:07 AM, Barry Dingle wrote: > Protocol looks good.=20 >=20 > One small point - the title of this protocol is "WebRTC Data Channel = Protocol" but the Abstract says "This document specifies a simple = protocol for establishing symmetric data channels between the peers." = This could cause confusion between what is a Data Channel Protocol and = what is an Establishing protocol.=20 >=20 > It appears that the title of this protocol should be "WebRTC Data = Channel Establishment Protocol" in order to avoid future confusion as to = its purpose.=20 You are right, the protocol is just for establishing data channels. Other opinions regarding the name change? Best regards Michael >=20 > /Barry Dingle > Australia >=20 >=20 > On Mon, Feb 10, 2014 at 8:16 AM, wrote: >=20 > 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 : WebRTC Data Channel Protocol > Authors : Randell Jesup > Salvatore Loreto > Michael Tuexen > Filename : draft-ietf-rtcweb-data-protocol-02.txt > Pages : 12 > Date : 2014-02-09 >=20 > Abstract: > The Web Real-Time Communication (WebRTC) working group is charged = to > provide protocols to 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-protocol-02 >=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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From Michael.Tuexen@lurchi.franken.de Mon Feb 10 02:17: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 2D66A1A07E4 for ; Mon, 10 Feb 2014 02:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548, 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 1Musis_lNbNj for ; Mon, 10 Feb 2014 02:17:03 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFA91A07DE for ; Mon, 10 Feb 2014 02:17:03 -0800 (PST) Received: from [192.168.1.200] (p54819372.dip0.t-ipconnect.de [84.129.147.114]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B74ED1C0B3FE4; Mon, 10 Feb 2014 11:17:02 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se> Date: Mon, 10 Feb 2014 11:17:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4616BFFA-F461-4CE8-9D85-211B86D4BE93@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 10:17:05 -0000 On Feb 10, 2014, at 11:07 AM, Christer Holmberg = wrote: > Hi, > =20 > As is defined in the data channel protocol, an entity can send data = once DATA_CHANNEL_OPEN has been sent, before the associated = DATA_CHANNEL_ACK is received. > =20 > The draft also says that, if both endpoints send DATA_CHANNEL_OPEN at = the same time, using different stream id values, the result may be TWO = data channels, with data sent on both. > =20 > However, as is also indicated, the draft does not provide a mechanism = to prevent/handle such glare situation. > =20 > I personally think there shall be a way to prevent such situation, or = otherwise I=92m sure we are going to end up with interoperability = problems. > =20 > Couldn=92t we e.g. say that, by default, the DTLS client is = responsible for sending the DATA_CHANNEL_OPEN? Then there is no risk for = glare, and it could even use both an even or odd stream id value. Section 4 reads: To avoid glare in opening Channels, each side MUST use either even or odd Streams when sending a DATA_CHANNEL_OPEN message. The method used to determine which side uses odd or even is based on the underlying DTLS connection role when used in WebRTC, with the side acting as the DTLS client using even stream identifiers. So there is no problem in setting up data channels. This should not be confused by both sides setting up a data channel with the same Label. This ends up in two data channels with the same label. You can even create more data channels with the same label. Best regards Michael > =20 > Regards, > =20 > Christer > =20 > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Mon Feb 10 02:20: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 4E0261A07E8 for ; Mon, 10 Feb 2014 02:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 sXvFHvzVqNpl for ; Mon, 10 Feb 2014 02:20:03 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 275F01A07E7 for ; Mon, 10 Feb 2014 02:20:02 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-db-52f8a7d29068 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id FA.2C.04853.2D7A8F25; Mon, 10 Feb 2014 11:20:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 11:20:01 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: Data Channel Protocol: Data before DATA_CHANNEL_ACK Thread-Index: Ac8mSYxkYxWKLCWnTpOI4SR9Ce/EOg== Date: Mon, 10 Feb 2014 10:20:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D166D41@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM+Jvje6l5T+CDG7+V7dY+6+d3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGQ9XT2IpOMtSsbFnO3sD4w3mLkZODgkBE4k7329B2WISF+6t Z+ti5OIQEjjBKNH5q5cZwlnMKHHm4QqgDAcHm4CFRPc/bZAGEQF1icsPL7CD2MICNhInzh5n gog7SvS8OcwCYetJbN+1D6yGRUBV4lnTVbBlvAK+Etf+bAGrYQRa/P3UGrBeZgFxiVtP5jNB HCQgsWTPeajjRCVePv7HCmErSuw8284MUa8jsWD3JzYIW1ti2cLXUPMFJU7OfMIygVF4FpKx s5C0zELSMgtJywJGllWMksWpxcW56UYGernpuSV6qUWZycXF+Xl6xambGIGhfnDLb6MdjCf3 2B9ilOZgURLnvc5aEyQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMZTv2KQvF8V+K/POnHB+ 0/dVsjyq5rPDIo8mZTbsP1+9QvHRz7U1m27tXqN9v51l8ToGzrP5lQqf32zeKaocW1km+e/K VAEPidfqIXPMPUQL1f89Xt42zX+jq9H+Fex73jxbHDQvfebM9srU9WLymROt3Kep1UiWJLA+ qrRvUeD6cMjObzHnNyWW4oxEQy3mouJEAMWLJT9DAgAA Subject: [rtcweb] Data Channel Protocol: Data before DATA_CHANNEL_ACK X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 10:20:05 -0000 Hi, As is defined in the data channel protocol, an entity can send data once DA= TA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK is re= ceived. What is the reason for allowing data to be sent before DATA_CHANNEL_ACK? Th= e sender may not even know (depends on whatever external negotiation mechan= isms are used) whether the remote peer supports the protocol to begin with. It think it would be good to allow the remote peer to accept (DATA_CHANNEL_= ACK) or reject (stream reset) the DATA_CHANNEL_OPEN before data is sent. Regards, Christer From christer.holmberg@ericsson.com Mon Feb 10 02:21: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 DCC221A07DE for ; Mon, 10 Feb 2014 02:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 RAo8XfLCySEH for ; Mon, 10 Feb 2014 02:21:57 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id D9DDA1A06C9 for ; Mon, 10 Feb 2014 02:21:56 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-0f-52f8a8448009 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 32.8C.04853.448A8F25; Mon, 10 Feb 2014 11:21:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 11:21:55 +0100 From: Christer Holmberg To: Michael Tuexen Thread-Topic: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare Thread-Index: Ac8mR2/m3LFj8oi+SFKLxbYiytu9PP//8tkA///uSjA= Date: Mon, 10 Feb 2014 10:21:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D166D7B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se> <4616BFFA-F461-4CE8-9D85-211B86D4BE93@lurchi.franken.de> In-Reply-To: <4616BFFA-F461-4CE8-9D85-211B86D4BE93@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvja7Lih9BBp0XxCwuNi1htFj7r53d gcljyZKfTB4bWnYwBTBFcdmkpOZklqUW6dslcGXsnDyVueACT8W8zxYNjF85uxg5OSQETCQm rFvNAmGLSVy4t56ti5GLQ0jgBKPEuc5nrBDOYkaJL29vMXcxcnCwCVhIdP/TBmkQETCVOLh8 Hlgzs4C6xJ3F59hBbGEBH4llB/YxQ9T4Sly7NI8NwraSeH5gL1gNi4CqxKZ/pxhBRvIC1cy9 xwuxqoNR4vr/ZawgNZwCrhJnH+wHq2cEOu77qTVMELvEJW49mc8EcbSAxJI955khbFGJl4// sULYihI7z7YzQ9TrSCzY/YkNwtaWWLbwNVicV0BQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBk WcUoWZxaXJybbmSgl5ueW6KXWpSZXFycn6dXnLqJERhFB7f8NtrBeHKP/SFGaQ4WJXHe66w1 QUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYVRnfSyxxed4w42Xve+ff28NTItJTO+Mkd000 DrJUOc/mXx5ptvj56pCW+0+Ufv0PESpbE7I4RvtgTGTPnadTZP91f5WbXh4VuU32+BaBe5ZX er5wSQR9OWqtv/pB0wO7O5FCXX9X3GoN63zv68Vx/ALDD5kLQSn3Gv6m9Vg12Z3+2VjbvnCy EktxRqKhFnNRcSIAIMmMTnACAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 10:21:59 -0000 Hi, =20 >> As is defined in the data channel protocol, an entity can send data once= DATA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK is= received. >> =20 >> The draft also says that, if both endpoints send DATA_CHANNEL_OPEN at th= e same time, using different stream id values, the result may be TWO data c= hannels, with data sent on both. >> =20 >> However, as is also indicated, the draft does not provide a mechanism to= prevent/handle such glare situation. >> =20 >> I personally think there shall be a way to prevent such situation, or ot= herwise I'm sure we are going to end up with interoperability problems. >> =20 >> Couldn't we e.g. say that, by default, the DTLS client is responsible fo= r sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it co= uld even use both an even or odd stream id value. > Section 4 reads: > > To avoid glare in opening Channels, each side MUST use either even or > odd Streams when sending a DATA_CHANNEL_OPEN message. The method > used to determine which side uses odd or even is based on the > underlying DTLS connection role when used in WebRTC, with the side > acting as the DTLS client using even stream identifiers. > > So there is no problem in setting up data channels. > > This should not be confused by both sides setting up a data channel with = the same Label. This ends up in two data channels with the same label. > You can even create more data channels with the same label. My point is that I don't want to end up with more than one channel. Regards, Christer From Michael.Tuexen@lurchi.franken.de Mon Feb 10 02:36: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 3CC701A07DD for ; Mon, 10 Feb 2014 02:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548, 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 5Q1vSfoBugej for ; Mon, 10 Feb 2014 02:36:33 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3A81A00AE for ; Mon, 10 Feb 2014 02:36:33 -0800 (PST) Received: from [192.168.1.200] (p54819372.dip0.t-ipconnect.de [84.129.147.114]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 858031C0B404D; Mon, 10 Feb 2014 11:36:32 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D166D7B@ESESSMB209.ericsson.se> Date: Mon, 10 Feb 2014 11:36:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <71288EED-3C82-44A7-950B-EFEFA62616E6@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se> <4616BFFA-F461-4CE8-9D85-211B86D4BE93@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166D7B@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 10:36:36 -0000 On Feb 10, 2014, at 11:21 AM, Christer Holmberg = wrote: > Hi, >=20 >>> As is defined in the data channel protocol, an entity can send data = once DATA_CHANNEL_OPEN has been sent, before the associated = DATA_CHANNEL_ACK is received. >>>=20 >>> The draft also says that, if both endpoints send DATA_CHANNEL_OPEN = at the same time, using different stream id values, the result may be = TWO data channels, with data sent on both. >>>=20 >>> However, as is also indicated, the draft does not provide a = mechanism to prevent/handle such glare situation. >>>=20 >>> I personally think there shall be a way to prevent such situation, = or otherwise I'm sure we are going to end up with interoperability = problems. >>>=20 >>> Couldn't we e.g. say that, by default, the DTLS client is = responsible for sending the DATA_CHANNEL_OPEN? Then there is no risk for = glare, and it could even use both an even or odd stream id value. >> Section 4 reads: >>=20 >> To avoid glare in opening Channels, each side MUST use either even = or >> odd Streams when sending a DATA_CHANNEL_OPEN message. The method >> used to determine which side uses odd or even is based on the >> underlying DTLS connection role when used in WebRTC, with the side >> acting as the DTLS client using even stream identifiers. >>=20 >> So there is no problem in setting up data channels. >>=20 >> This should not be confused by both sides setting up a data channel = with the same Label. This ends up in two data channels with the same = label. >> You can even create more data channels with the same label. >=20 > My point is that I don't want to end up with more than one channel. And you won't, see above. However, there is no mechanism to ensure uniqueness for labels. The WebRTC API already allows one side to create n data channels with the same label. Best regards Michael >=20 > Regards, >=20 > Christer >=20 >=20 From salvatore.loreto@ericsson.com Mon Feb 10 02:53: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 4F55D1A06C7 for ; Mon, 10 Feb 2014 02:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 noGW7chGqhKS for ; Mon, 10 Feb 2014 02:53:00 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B2FB31A06C1 for ; Mon, 10 Feb 2014 02:52:59 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-fb-52f8af8ac294 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B5.83.10875.A8FA8F25; Mon, 10 Feb 2014 11:52:58 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.236]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 11:52:58 +0100 From: Salvatore Loreto To: Michael Tuexen Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-02.txt Thread-Index: AQHPJdxJfCBLqGYV0Ui3lV8JYQFzuJquRVyU///6rAA= Date: Mon, 10 Feb 2014 10:52:58 +0000 Message-ID: References: <20140209211659.26091.94840.idtracker@ietfa.amsl.com> <122F40CC-C008-4C98-9705-DAD089D6A16C@lurchi.franken.de> In-Reply-To: <122F40CC-C008-4C98-9705-DAD089D6A16C@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.149] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW7X+h9BBk8fW1o8vm9rcbFpCaPF 2n/t7A7MHjtn3WX3WLLkJ5PHhpYdTAHMUVw2Kak5mWWpRfp2CVwZ835HF7yQqPj9+R5rA+Nt 4S5GTg4JAROJixO/sULYYhIX7q1n62Lk4hASOMQocX76fGYIZwmjxKNPD1hAqtgEzCSeP9zC DGKLCJhKHFw+DyzOLOAl8Xb+AbBJwgIeEtvX72WFqPGUWLp0MpDNAWRbSTx45g0SZhFQlbh/ 5hgjiM0rYC/xatcHqMWHGSU+3ZgFNpNTwFViwYqDYHMYga77fmoNE8QucYlbT+YzQVwtILFk z3lmCFtU4uXjf1DfKEmsPbwd6jYdiQW7P7FB2NYS/x/cYISwtSWWLXzNDHGEoMTJmU9YJjCK z0KyYhaS9llI2mchaZ+FpH0BI+sqRvbcxMyc9HLDTYzAKDu45bfuDsZT50QOMUpzsCiJ8354 6xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdGpp9BdSrF1Y9T9zcZvFCw89kt8Km5ZMp33 pcLqNWdMN4mveiR64dpV8e6QxbZ9iycsNzp7T7F/2uuPcxkuK/C9d93jWT4l1/pa3PyJazJm /FHJkLa0u852ZKa/ZFT1zJun9dZWbqn64VzaJm+jKDRVfsaTtsTO2HL3LdJvjgh3Pw8xyHxa zaLEUpyRaKjFXFScCABXL5HegAIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-02.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, 10 Feb 2014 10:53:02 -0000 I think is a good suggestion /Salvatore On Feb 10, 2014, at 12:11 PM, Michael Tuexen wrote: > On Feb 10, 2014, at 11:07 AM, Barry Dingle wrote: >=20 >> Protocol looks good.=20 >>=20 >> One small point - the title of this protocol is "WebRTC Data Channel Pro= tocol" but the Abstract says "This document specifies a simple protocol for= establishing symmetric data channels between the peers." This could cause= confusion between what is a Data Channel Protocol and what is an Establish= ing protocol.=20 >>=20 >> It appears that the title of this protocol should be "WebRTC Data Channe= l Establishment Protocol" in order to avoid future confusion as to its purp= ose.=20 > You are right, the protocol is just for establishing data channels. > Other opinions regarding the name change? >=20 > Best regards > Michael >>=20 >> /Barry Dingle >> Australia >>=20 >>=20 >> On Mon, Feb 10, 2014 at 8:16 AM, wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Real-Time Communication in WEB-browsers= Working Group of the IETF. >>=20 >> Title : WebRTC Data Channel Protocol >> Authors : Randell Jesup >> Salvatore Loreto >> Michael Tuexen >> Filename : draft-ietf-rtcweb-data-protocol-02.txt >> Pages : 12 >> Date : 2014-02-09 >>=20 >> Abstract: >> The Web Real-Time Communication (WebRTC) working group is charged to >> provide protocols to 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. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-02 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-protocol-02 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submis= sion >> 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 >> _______________________________________________ >> 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 stefan.lk.hakansson@ericsson.com Mon Feb 10 02:56: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 A837B1A06D2 for ; Mon, 10 Feb 2014 02:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 bKTh5dWqSMOJ for ; Mon, 10 Feb 2014 02:56:40 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEEC1A06C1 for ; Mon, 10 Feb 2014 02:56:38 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-ba-52f8b0652921 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6D.14.10875.560B8F25; Mon, 10 Feb 2014 11:56:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 11:56:37 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "Tirumaleswar Reddy (tireddy)" , Magnus Westerlund , Parthasarathi R , 'Cb B' , 'Simon Perreault' Thread-Topic: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 Thread-Index: AQHPIPZvC8FwdgJWOkCao81vwfT27g== Date: Mon, 10 Feb 2014 10:56:37 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CF542F2@ESESSMB209.ericsson.se> References: <913383AAA69FF945B8F946018B75898A2428E32D@xmb-rcd-x10.cisco.com> <009601cf17ca$5723cb70$056b6250$@co.in> <1447FA0C20ED5147A1AA0EF02890A64B1CF32B82@ESESSMB209.ericsson.se> <004501cf18a1$913c4080$b3b4c180$@co.in> <52E27630.3030300@viagenie.ca> <001c01cf1920$a00c9220$e025b660$@co.in> <52E2952A.2010503@viagenie.ca> <002001cf1927$b502eb00$1f08c100$@co.in> <52E2AE42.5060903@viagenie.ca> <001701cf19ec$f99791b0$ecc6b510$@co.in> <52E8C9D4.30205@ericsson.com> <00a001cf1e23$7a168aa0$6e439fe0$@co.in> <52EB6672.5090704@ericsson.com> <913383AAA69FF945B8F946018B75898A242A6A02@xmb-rcd-x10.cisco.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvjW7ahh9BBisXMFms+vKRyWLypz5W i7X/2tktupf+Z7E4sXsbowOrx5TfG1k9ds66y+6xZMlPJo8P87+we6z7YB7AGsVlk5Kak1mW WqRvl8CVcXLXFeaC174VdybtYW5gvOjYxcjBISFgIvHwL2sXIyeQKSZx4d56ti5GLg4hgUOM ErdXXWGFcBYzSuw7958ZpIpNIFBi674FYFUiAm8YJZZ1nmYBSTALqEvcWXyOHcQWFoiQmDLj AlhcRCBSov//PChbT2Ln1u1gNSwCqhJ/+peADeUV8JWY17QSattGVomX63YzgSQYgW76fmoN E8QCcYlbT+YzQdwqILFkz3lmCFtU4uXjf1A/KEq0P21ghKjXk7gxdQobhK0tsWzha6hlghIn Zz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRvbcxMyc9HLDTYzASDq45bfuDsZT50QOMUpzsCiJ 83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdHf51+pQOn/M/NZFzxubl66ed6GBcZq F1dxNiw8uezolBOG+Y4f111jlVQ0PHW9Zk5sUtabi0yef6aLLjDYeib+qWtZq+f0urqWfdE8 b1jqZr2eNeec3Nd9MwQPHHM8osar8MVmSXFmyQOnzjRZi7n7PoT79KUff/Tm6PqVnkdfPao/ XaeioX1FiaU4I9FQi7moOBEAFhb413ICAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 10:56:42 -0000 On 2014-02-03 16:41, Tirumaleswar Reddy (tireddy) wrote:=0A= >> -----Original Message----- From: rtcweb=0A= >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund=0A= >> Sent: Friday, January 31, 2014 2:32 PM To: Parthasarathi R; 'Cb B';=0A= >> 'Simon Perreault' Cc: rtcweb@ietf.org Subject: Re: [rtcweb]=0A= >> Query/Comment on draft-ietf-rtcweb-use-cases-and- requirements-12=0A= >>=0A= >> Hi Partha,=0A= >>=0A= >> Personal opinion:=0A= >>=0A= >> I think the below places the text in the wrong context. The note is=0A= >> in my mind relevant in the context of the general NAT/FW traversal=0A= >> requirements, not the one discussing need to support multiple=0A= >> NAT/FW traversal servers. Thus, I think Section 3.3.2 and thus=0A= >> requirement F29. Or potentially regarding Requirement F2. Is more=0A= >> appropriate places to include this.=0A= >=0A= > F29, F2 does not mention any NAT/FW traversal techniques. F29 just=0A= > discusses the problems with NAT but IPv6 Firewalls could also be=0A= > configured to block UDP traffic. F19 Requirement seems to be missing=0A= > in the latest version.=0A= =0A= F19 was removed to the -12 version when the following text was removed =0A= from the use-case "Video conferencing system with central server":=0A= =0A= =0A= "The organization has an internal network set up with an aggressive =0A= firewall handling access to the Internet. If users cannot physically =0A= access the internal network, they can establish a Virtual Private =0A= Network (VPN)."=0A= =0A= Stefan=0A= =0A= >=0A= > -Tiru.=0A= >=0A= >>=0A= >> Cheers=0A= >>=0A= >> Magnus=0A= >>=0A= >> On 2014-01-31 02:26, Parthasarathi R wrote:=0A= >>> Hi Magnus,=0A= >>>=0A= >>> I can live with Simon text in case it is documented in Sec 4.2=0A= >>> as=0A= >>>=0A= >>> F31 The browser must be able to use several STUN and TURN=0A= >>> servers. Note that TURN support being mandatory does not preclude=0A= >>> the browser from supporting additional traversal mechanisms.=0A= >>> ----------------------------------------------------------------=0A= >>> F32 There browser must support that STUN and TURN servers to=0A= >>> use are supplied by other entities than via the web application=0A= >>> (i.e. the network provider). Note that TURN support being=0A= >>> mandatory does not preclude the browser from supporting=0A= >>> additional traversal mechanisms.=0A= >>>=0A= >>> and also Appendix A:=0A= >>>=0A= >>> A22 The Web API must provide means for the application to=0A= >>> specify several STUN and/or TURN servers to use. Note that TURN=0A= >>> support being mandatory does not preclude a Web API from=0A= >>> supporting additional traversal mechanisms.=0A= >>>=0A= >>> Please let me know in case you have any issue in the above text.=0A= >>>=0A= >>> BTW, just for the record,=0A= >>> draft-ietf-rtcweb-use-cases-and-requirements-12 does not specify=0A= >>> the list of traversal mechanism requirements for WebRTC=0A= >>> Gateway/Server.=0A= >>>=0A= >>> Thanks Partha=0A= >>>=0A= >>>> -----Original Message----- From: Magnus Westerlund=0A= >>>> [mailto:magnus.westerlund@ericsson.com] Sent: Wednesday,=0A= >>>> January 29, 2014 2:59 PM To: Parthasarathi R; 'Cb B'; 'Simon=0A= >>>> Perreault' Cc: rtcweb@ietf.org Subject: Re: [rtcweb]=0A= >>>> Query/Comment on draft-ietf-rtcweb-use-cases-and-=0A= >>>> requirements-12=0A= >>>>=0A= >>>> Hi Partha and WG,=0A= >>>>=0A= >>>> I don't see any support for the changes you proposes in this=0A= >>>> discussion. What I see some support for is to add a statement=0A= >>>> making clear that there might be additional NAT/Firewall=0A= >>>> traversal mechanisms than STUN/TURN. Simon proposed:=0A= >>>>=0A= >>>> "Note that TURN support being mandatory does not preclude a=0A= >>>> WebRTC endpoint from supporting additional traversal=0A= >>>> mechanisms."=0A= >>>>=0A= >>>> However, looking at the document as it is currently written, I=0A= >>>> am uncertain where this would be added. The first mention of=0A= >>>> TURN is in Section 3.3.4.1, and that section is focused on the=0A= >>>> global service provider perspective and the need for location=0A= >>>> based provisioning of NAT/Firewall traversal server resources.=0A= >>>>=0A= >>>> I think it can be added to Section 3.3.5.1 without being=0A= >>>> misplaced, but it would be given a slightly narrower scope.=0A= >>>>=0A= >>>> I any of you want to be more explicit where this should be=0A= >>>> included, please be. If you are not forthcoming I will request=0A= >>>> the authors to add this in what they consider sensible=0A= >>>> position.=0A= >>>>=0A= >>>> Cheers=0A= >>>>=0A= >>>> Magnus=0A= >>>>=0A= >>>>=0A= >>>> On 2014-01-25 17:46, Parthasarathi R wrote:=0A= >>>>> Hi Simon,=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> Thanks for your understanding about my firewall/NAT related=0A= >>>>> problem statement in this draft.=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> I have proposed the firewall/NAT related text by which the=0A= >>>>> specific mechanism is not highlighted in the requirement=0A= >>>>> document as there is=0A= >>>> no=0A= >>>>> WG consensus for any of the mechanism including TURN. It is=0A= >>>>> possible=0A= >>>> to=0A= >>>>> argue hypothetically in PNTAW alias that PCP is the only=0A= >>>>> mechanism required in WebRTC endpoint. Also, I'm more=0A= >>>>> interested in WebRTC gateway/server (Sec 4.3. of=0A= >>>>> draft-ietf-rtcweb-use-cases-and-requirements-12)=0A= >>>>> requirements wherein=0A= >>>> it=0A= >>>>> is not required to support TURN and the related mail thread=0A= >>>>> is=0A= >>>>> http://www.ietf.org/mail-archive/web/pntaw/current/msg00181.html.=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= IMO, my proposed text without mentioning any firewall/NAT mechanism=0A= >>>> in=0A= >>>>> the requirement document helps to move forward without depend=0A= >>>>> on=0A= >> the=0A= >>>>> solution discussion in PNTAW alias.=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> Thanks=0A= >>>>>=0A= >>>>> Partha=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> *From:*Cb B [mailto:cb.list6@gmail.com] *Sent:* Saturday,=0A= >>>>> January 25, 2014 6:22 AM *To:* Simon Perreault *Cc:*=0A= >>>>> rtcweb@ietf.org; Parthasarathi R *Subject:* Re: [rtcweb]=0A= >>>>> Query/Comment on=0A= >>>>> draft-ietf-rtcweb-use-cases-and-requirements-12=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> On Jan 24, 2014 10:17 AM, "Simon Perreault"=0A= >>>> >>>> > wrote:=0A= >>>>>>=0A= >>>>>> Le 2014-01-24 12:14, Parthasarathi R a =E9crit :=0A= >>>>>>=0A= >>>>>>> Please note that when non-IETFers read this requirement=0A= >>>>>>> document,=0A= >>>>> they come=0A= >>>>>>> to the conclusion that IETF RTCWeb WG recommends TURN and=0A= >>>>>>> not other mechanisms. I'm saying that requirement=0A= >>>>>>> document should not be used=0A= >>>>> as the=0A= >>>>>>> mechanism to eliminate the other alternatives when there=0A= >>>>>>> is a=0A= >>>> discussion=0A= >>>>>>> going-on in PNTAW alias. So, I'm asking for the change.=0A= >>>>>>=0A= >>>>>>=0A= >>>>>> I would totally agree with that sentiment, although I don't=0A= >>>>>> see your=0A= >>>>> proposed text change reflecting it accurately. How about=0A= >>>>> simply:=0A= >>>>>>=0A= >>>>>> "Note that TURN support being mandatory does not preclude=0A= >>>>>> a=0A= >> WebRTC=0A= >>>>> endpoint from supporting additional traversal mechanisms."=0A= >>>>>>=0A= >>>>>>=0A= >>>>>=0A= >>>>> +1 for the above text.=0A= >>>>>=0A= >>>>> CB=0A= >>>>>=0A= >>>>>> Simon -- DTN made easy, lean, and smart -->=0A= >>>>>> http://postellation.viagenie.ca NAT64/DNS64 open-source=0A= >>>>>> --> http://ecdysis.viagenie.ca STUN/TURN server=0A= >>>>>> --> http://numb.viagenie.ca=0A= >>>>>> _______________________________________________ rtcweb=0A= >>>>>> mailing list rtcweb@ietf.org =0A= >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> _______________________________________________ rtcweb=0A= >>>>> mailing list rtcweb@ietf.org=0A= >>>>> https://www.ietf.org/mailman/listinfo/rtcweb=0A= >>>>>=0A= >>>>=0A= >>>>=0A= >>>> --=0A= >>>>=0A= >>>> Magnus Westerlund=0A= >>>>=0A= >>>> ---------------------------------------------------------------------= =0A= >>>>=0A= >>>>=0A= - Services, Media and Network features, Ericsson Research EAB/TXM=0A= >>>> ----------------------------------------------------------------------= =0A= >>>>=0A= >>>>=0A= Ericsson AB | Phone +46 10 7148287=0A= >>>> F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80=0A= >>>> Stockholm, Sweden | mailto:=0A= >> magnus.westerlund@ericsson.com=0A= >>>> ---------------------------------------------------------------------= =0A= >>>>=0A= >>>>=0A= -=0A= >>>=0A= >>>=0A= >>>=0A= >>=0A= >>=0A= >> --=0A= >>=0A= >> Magnus Westerlund=0A= >>=0A= >> ----------------------------------------------------------------------= =0A= >>=0A= >>=0A= Services, Media and Network features, Ericsson Research EAB/TXM=0A= >> ----------------------------------------------------------------------= =0A= >>=0A= >>=0A= Ericsson AB | Phone +46 10 7148287=0A= >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80=0A= >> Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= >> ----------------------------------------------------------------------= =0A= >>=0A= >>=0A= >>=0A= _______________________________________________=0A= >> rtcweb mailing list rtcweb@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/rtcweb=0A= > _______________________________________________ rtcweb mailing list=0A= > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From magnus.westerlund@ericsson.com Mon Feb 10 03:02: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 CED8B1A07FE for ; Mon, 10 Feb 2014 03:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 s_gNRg52v25w for ; Mon, 10 Feb 2014 03:02:05 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 47F161A07F9 for ; Mon, 10 Feb 2014 03:02:05 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-ce-52f8b1ac88cd Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 73.43.04249.CA1B8F25; Mon, 10 Feb 2014 12:02:04 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Feb 2014 12:02:04 +0100 Message-ID: <52F8B1AB.70305@ericsson.com> Date: Mon, 10 Feb 2014 12:02:03 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Parthasarathi R , =?ISO-8859-1?Q?=27Stefa?= =?ISO-8859-1?Q?n_H=E5kansson_LK=27?= , References: <1447FA0C20ED5147A1AA0EF02890A64B1CF4A182@ESESSMB209.ericsson.se> <007601cf2423$2d571210$88053630$@co.in> <1447FA0C20ED5147A1AA0EF02890A64B1CF533B8@ESESSMB209.ericsson.se> <004601cf24ad$f3a1c0c0$dae54240$@co.in> In-Reply-To: <004601cf24ad$f3a1c0c0$dae54240$@co.in> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZGfG3RnfNxh9BBr1P9S0mf+pjtVj7r53d gcljyZKfTB4f5n9hD2CK4rJJSc3JLEst0rdL4MpYtngaU8F34Yqtn64zNzD+4O9i5OSQEDCR WLnlNwuELSZx4d56ti5GLg4hgSOMEt0XJkM5yxklTj3/xAxSxSugKfGm/RUTiM0ioCqx6s0z dhCbTcBC4uaPRjYQW1QgWOLWtAfsEPWCEidnPmEBGSQisIpR4vL+7WBFwgI2Ev8unGKH2HCf UeJHyxRWkAQn0E3PTl0AsjmAbhKX6GkMAgkzC+hJTLnawghhy0s0b50NdpCQgLZEQ1MH6wRG wVlI9s1C0jILScsCRuZVjBzFqcVJuelGBpsYgYF5cMtvix2Ml//aHGKU5mBREuf9+NY5SEgg PbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjpp5SsSgT/UXPZEISq4oe+7Xc35KbdHLGfdYkqzvM nJPWJ9aFBQYf+HV7Nuf39d6OT/YLv1sVGRi4+A1jQbJL/ZVLnx8bv2/xqXdWK4l1SZeY/uZe 0tQ/3J7lPPbSq0w+WVxmzf8XG8SY8Uj9d/8KN/fl1YYXrYLtHjRqWM9ZxGv7TD+34b8SS3FG oqEWc1FxIgBa5Sx0GgIAAA== Subject: Re: [rtcweb] New version of use-case draft uploaded X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 11:02:07 -0000 Hi Partha, See inline On 2014-02-08 10:12, Parthasarathi R wrote: > Hi Stefan, > > >> Yes, I did that change (TURN -> ICE). My understanding was that ICE is >> what is used/mandated (and it in turn makes use of STUN and TURN). >> > > > ICE is mandated in RTCWeb but I disagree to your assumption that ICE in turn > makes use of TURN. My concern is that The requirement document is misleading > about TURN requirements. ICE-TCP avoids TURN server as the middle-box in the > network. ICE-TCP is host candidate whereas TURN is relay candidate and as > per ICE candidate selection, host candidate is preferred over relay > candidates. I will agree that the note as currently worded is not completely accurate and clear. Based on the text in the preceding section, it makes sense to note that ICE using STUN and TURN is not the only solution including additional ICE modes or relay services. I request the authors propose a new formulation of the note. > > In case of WebRTC servers (like conference)/gateway implementation, WebRTC > server is never going to be behind firewall, ICE-TCP serve the purpose and > there is no need of TURN server as a middle-box in the network. So, Could > you please correct the F31, F32 requirement text in the next revision of the > draft. > This is a request to change two requirements. I have not seen a clear consensus on this change. Thus, the change is rejected for now. >From my perspective your proposal for ICE-TCP based solution is a choice to fulfill F2 and F29, not F31 and F32. Thus, I don't see an issue for F31 and F32 being STUN and TURN specific. Is really the current formulations in the requirement documents a hinder against the WG considering an ICE-TCP based traversal addition? I don't see it, and if you do, can you please be clearer in your explanation what the issue is? If not, I think your time is better spent working on building a clear motivation why ICE-TCP is needed to help establish a WG consensus on this. Cheers Magnus Westerlund (As co-chair) ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Raju.Makaraju@alcatel-lucent.com Mon Feb 10 03:08: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 BC9521A080B for ; Mon, 10 Feb 2014 03:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 lq0DZTFjVyYt for ; Mon, 10 Feb 2014 03:08:21 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BE7811A080F for ; Mon, 10 Feb 2014 03:08:20 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1AB8BUZ027902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2014 05:08:11 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s1AB88oX002101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 06:08:10 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 06:08:08 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) Thread-Index: AQHPI5G5uqx5hsIOAEq9u24GTLgZVJqqTeJQgAB8IwCAAARsAP//vsSQgAO4fwCAABHmAA== Date: Mon, 10 Feb 2014 11:08:07 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <52F4182F.60404@alvestrand.no> , <7594FB04B1934943A5C02806D1A2204B1D163B26@ESESSMB209.ericsson.se> <52F85C14.7010904@alvestrand.no> In-Reply-To: <52F85C14.7010904@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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 11:08:23 -0000 =20 > > That's good. Glad to see that no one liked the complex alternate option= ... > yet! :-) > > I just put it there for completeness and some discussion. > > With "utf-8 on wire", which I too think is the right approach, there is > some spec work todo: > > 1. Define IANA utf-8 ppid. Creating a new one is better instead of > replacing existing DOMString as DOMString may be used by browsers for > sometime to come and also to have backward compatibility/interworking. >=20 > Have you ever seen UTF-16 on the wire in the DataChannel protocol? [Raju] I have used websockets and no, I did not see UTF-16 on wire. Further= , after going thru websocket API spec http://www.w3.org/TR/2011/WD-websocke= ts-20110419/ , which does have same send(DOMString) API call, I realized th= at browsers are very well doing this conversion already in other areas. Lat= er, Randell Jesup also comfirmed this for Firefox. So, no concerns on this.= Thanks! -Raju From christer.holmberg@ericsson.com Mon Feb 10 03:32: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 463DA1A080B for ; Mon, 10 Feb 2014 03:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 iB8SaFdAaU_h for ; Mon, 10 Feb 2014 03:32:00 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D77551A081C for ; Mon, 10 Feb 2014 03:31:59 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-5d-52f8b8afbf7f Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E5.99.10875.FA8B8F25; Mon, 10 Feb 2014 12:31:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 12:31:58 +0100 From: Christer Holmberg To: Michael Tuexen Thread-Topic: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare Thread-Index: Ac8mR2/m3LFj8oi+SFKLxbYiytu9PP//8tkA///uSjCAABcpAP//4ZBA Date: Mon, 10 Feb 2014 11:31:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D166F8C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se> <4616BFFA-F461-4CE8-9D85-211B86D4BE93@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166D7B@ESESSMB209.ericsson.se> <71288EED-3C82-44A7-950B-EFEFA62616E6@lurchi.franken.de> In-Reply-To: <71288EED-3C82-44A7-950B-EFEFA62616E6@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje76HT+CDD5fErK42LSE0WLtv3Z2 ByaPJUt+MnlsaNnBFMAUxWWTkpqTWZZapG+XwJVxbvs65oJPAhU3th9hb2Bcw9vFyMkhIWAi 0fZ5CSuELSZx4d56ti5GLg4hgUOMErt2zmeEcBYzSjT2TgPKcHCwCVhIdP/TBmkQETCVOLh8 HguIzSygLnFn8Tl2EFtYwEdi2YF9zBA1vhLXLs1jg7DdJNb8Xs8EYrMIqEqcvDcBLM4LVNO2 6z4rxK52Jon537vBBnEKuEosnzMZrIER6Lrvp9YwQSwTl7j1ZD4TxNUCEkv2nGeGsEUlXj7+ B/WNosTOs+3MEPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZ xciem5iZk15uuIkRGCUHt/zW3cF46pzIIUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otKc1KL DzEycXBKNTAqTj04JXcx37TOe0f5L5eVp+72+Mkk2RjcZf/I4Nvr3XtObLD0t7Rm2rWX6/2b Sz9CCv4Hvtnv9mzR7U7u/AeLuNf/87Ga9yDo+IOln7c+vjgr8JI+Y+qvDqtfcXdWSvw+GvL5 7Hc223tr51Wt3nI+0OwuE8fFtprEe0fTXXYfr1igY/ljS/oBKyWW4oxEQy3mouJEAOE0/KFg AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 11:32:02 -0000 Hi, >>>> As is defined in the data channel protocol, an entity can send data on= ce DATA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK = is received. >>>>=20 >>>> The draft also says that, if both endpoints send DATA_CHANNEL_OPEN at = the same time, using different stream id values, the result may be TWO data= channels, with data sent on both. >>>>=20 >>>> However, as is also indicated, the draft does not provide a mechanism = to prevent/handle such glare situation. >>>>=20 >>>> I personally think there shall be a way to prevent such situation, or = otherwise I'm sure we are going to end up with interoperability problems. >>>>=20 >>>> Couldn't we e.g. say that, by default, the DTLS client is responsible = for sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it = could even use both an even or odd stream id value. >>> Section 4 reads: >>>=20 >>> To avoid glare in opening Channels, each side MUST use either even=20 >>> or odd Streams when sending a DATA_CHANNEL_OPEN message. The method = =20 >>> used to determine which side uses odd or even is based on the =20 >>> underlying DTLS connection role when used in WebRTC, with the side =20 >>> acting as the DTLS client using even stream identifiers. >>>=20 >>> So there is no problem in setting up data channels. >>>=20 >>> This should not be confused by both sides setting up a data channel wit= h the same Label. This ends up in two data channels with the same label. >>> You can even create more data channels with the same label. >>=20 >> My point is that I don't want to end up with more than one channel. > And you won't, see above.=20 I am not sure I understand. What text do you refer to? > However, there is no mechanism to ensure uniqueness for labels. The WebRT= C API already allows one side to create n data channels with the same label= . I am not saying it should be forbidden to do so. But, for protocol X, I wan= t to end up with ONE data channel between my peers. If I end up with two data channels for protocol X, can I send data on which= ever I want to?=20 Regards, Christer From magnus.westerlund@ericsson.com Mon Feb 10 04:34: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 BEFDA1A05EC for ; Mon, 10 Feb 2014 04:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 zXhmBCyxA7n5 for ; Mon, 10 Feb 2014 04:34:38 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id C10291A05E1 for ; Mon, 10 Feb 2014 04:34:37 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-a4-52f8c75c4be2 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id BC.EF.04853.C57C8F25; Mon, 10 Feb 2014 13:34:37 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Feb 2014 13:34:36 +0100 Message-ID: <52F8C75C.4090708@ericsson.com> Date: Mon, 10 Feb 2014 13:34:36 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Parthasarathi R , 'Cb B' , 'Simon Perreault' References: <913383AAA69FF945B8F946018B75898A2428E32D@xmb-rcd-x10.cisco.com> <009601cf17ca$5723cb70$056b6250$@co.in> <1447FA0C20ED5147A1AA0EF02890A64B1CF32B82@ESESSMB209.ericsson.se> <004501cf18a1$913c4080$b3b4c180$@co.in> <52E27630.3030300@viagenie.ca> <001c01cf1920$a00c9220$e025b660$@co.in> <52E2952A.2010503@viagenie.ca> <002001cf1927$b502eb00$1f08c100$@co.in> <52E2AE42.5060903@viagenie.ca> <001701cf19ec$f99791b0$ecc6b510$@co.in> <52E8C9D4.30205@ericsson.com> <00a001cf1e23$7a168aa0$6e439fe0$@co.in> <52EB6672.5090704@ericsson.com> <913383AAA69FF945B8F946018B75898A242A6A02@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242A6A02@xmb-rcd-x10.cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvjW7s8R9BBnN+s1is+vKRyWLypz5W i7X/2tktupf+Z7E4sXsbowOrx5TfG1k9ds66y+6xZMlPJo8P87+we6z7YB7AGsVlk5Kak1mW WqRvl8CVsebob9aCR3wVb5qjGxin8XQxcnJICJhILD3fwgxhi0lcuLeeDcQWEjjBKLH/VXwX IxeQvZxRYveF+ewgCV4BbYn1V64wgdgsAqoS/Ut2gsXZBCwkbv5oBGsWFQiWuDXtAVS9oMTJ mU9YQAaJCGxjlPjwfjoLSIJZQF3izuJzYEXCAmES+5+eYILYNp9VonfeYrAiTgFfiR17/7J2 MXIAnScu0dMYBNGrJzHlagsjhC0v0bx1NjPE1doSDU0drBMYhWYh2T0LScssJC0LGJlXMUoW pxYX56YbGejlpueW6KUWZSYXF+fn6RWnbmIERsLBLb+NdjCe3GN/iFGag0VJnPc6a02QkEB6 YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZgPeat73TfSOp6rZrD4Xf75Mbn7UbHfrwV2s+acvja qZdRX0zTJjOwPLV5ZK0hXKqg7sy2fuH0u77T2oRFuOw+Przb8F55n1WVaB1PiYVt3HN/BYc8 2/bI+REfk1KV3hzsj7DtO6flJHuCKzHgTM/2c6qr/zt1Jnx9eWXrkVdGPML9RkynPiqxFGck GmoxFxUnAgAAWTu9UgIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 12:34:39 -0000 On 2014-02-03 16:41, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- From: rtcweb >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund >> Sent: Friday, January 31, 2014 2:32 PM To: Parthasarathi R; 'Cb B'; >> 'Simon Perreault' Cc: rtcweb@ietf.org Subject: Re: [rtcweb] >> Query/Comment on draft-ietf-rtcweb-use-cases-and- requirements-12 >> >> Hi Partha, >> >> Personal opinion: >> >> I think the below places the text in the wrong context. The note is >> in my mind relevant in the context of the general NAT/FW traversal >> requirements, not the one discussing need to support multiple >> NAT/FW traversal servers. Thus, I think Section 3.3.2 and thus >> requirement F29. Or potentially regarding Requirement F2. Is more >> appropriate places to include this. > > F29, F2 does not mention any NAT/FW traversal techniques. F29 just > discusses the problems with NAT but IPv6 Firewalls could also be > configured to block UDP traffic. F19 Requirement seems to be missing > in the latest version. > Regarding F29 and F2, that is the benefit of having solution neutral requirements. Thus, these requirements are not blocking or hindering you from proposing additional solutions or implementation requirements when it comes to NAT/FW traversal. Thus, these requirements applies to UDP blocking IPv6 firewalls as well as other types. cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From christer.holmberg@ericsson.com Mon Feb 10 05:29: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 E67B71A06DA for ; Mon, 10 Feb 2014 05:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 fODMrdkXFZuw for ; Mon, 10 Feb 2014 05:29:51 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A232B1A0829 for ; Mon, 10 Feb 2014 05:29:50 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-c7-52f8d44d8387 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D6.CA.10875.D44D8F25; Mon, 10 Feb 2014 14:29:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 14:29:49 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: How to determine TLS roles? Thread-Index: Ac8mZBiXQux1+cpSRGeFwm+/NhCfyA== Date: Mon, 10 Feb 2014 13:29:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1672FC@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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1672FCESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvja7flR9BBk3lFmv/tbM7MHosWfKT KYAxissmJTUnsyy1SN8ugSvj//4GpoJW7YpvV5waGCeqdTFyckgImEh82n+VCcIWk7hwbz1b FyMXh5DAIUaJ05cesEM4ixkl7q79wdLFyMHBJmAh0f1PG6RBREBd4vLDC+wgtrCAisSk9WfZ IeKaEi9WL2WCsPUkzpz/ywxiswioSvy/e44RxOYV8JVomvKADcRmBFr8/dQasHpmAXGJW0/m Qx0kILFkz3lmCFtU4uXjf6wQtqLEzrPtzBD1+RIPzk1kgpgpKHFy5hOWCYxCs5CMmoWkbBaS Moi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkT03MTMnvdxwEyMw5A9u+a27g/HUOZFD jNIcLErivB/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYHSdbS43h9HN1vxR+tJJM4xL Kz6ktc/TU+e3Xfsl52a++9rzE99/0brzZerb9SrT/3H9nsR5uGpp5i3BlPxLF4+s0PI6qrL6 ya0sDlWuE5wnujy3d12W1H7zb0UL48Zf8kZ5kgs7ZO/GXDwofJ2J0+/WhaqkJNUJMbpmj/XP fle3trbWfFTDKq7EUpyRaKjFXFScCACcPohbRwIAAA== Subject: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 13:29:53 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1672FCESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, If I understand correctly, in RTCWEB we are going to use a single DTLS asso= ciation for two things: 1) Key exchange for SRTP 2) The data channel Now, this means that there needs to be a generic way to determine the TLS r= oles. In WEBRTC, how are the TLS roles determined? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D1672FCESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

If I understand correctly, in RTCWEB we are going to= use a single DTLS association for two things:

 

1)      Key exchange for SRTP

2)      The data channel

 

Now, this means that there needs to be a generic way= to determine the TLS roles.

 

In WEBRTC, how are the TLS roles determined?

 

Regards,

 

Christer

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D1672FCESESSMB209erics_-- From tim@phonefromhere.com Mon Feb 10 05:45: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 A3DAB1A0835 for ; Mon, 10 Feb 2014 05:45:46 -0800 (PST) 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 6-KlTijiFRrd for ; Mon, 10 Feb 2014 05:45:44 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3A21A05EF for ; Mon, 10 Feb 2014 05:45:43 -0800 (PST) Received: (qmail 25464 invoked from network); 10 Feb 2014 13:45:42 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 11062 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 10 Feb 2014 13:45:42 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 2027E18A05E8; Mon, 10 Feb 2014 13:45:42 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id DF49A18A05BC; Mon, 10 Feb 2014 13:45:41 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> Date: Mon, 10 Feb 2014 13:45:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1827) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 13:45:46 -0000 On 10 Feb 2014, at 13:29, Christer Holmberg = wrote: > Hi, >=20 > If I understand correctly, in RTCWEB we are going to use a single DTLS = association for two things: >=20 > 1) Key exchange for SRTP > 2) The data channel >=20 > Now, this means that there needs to be a generic way to determine the = TLS roles. >=20 > In WEBRTC, how are the TLS roles determined? That was the subject of a rant of mine. I think the correct answer is that the party that ends up being = IceControlling then becomes the DTLS client. Typically the initiator of a session is IceControlling.=20 However the recent addition of=20 a=3Dsetup:passive=20 to chrome's SDP clouds the story somewhat, allowing an IceController to = say that it is DTLS passive and allow the non-initiator to be the DTLS client. Ostensibly this is to support early media - where the receiver of a call = wishes to send media before the initiator does. As I said (rather intemperately) this added complexity is not worth the = benefit. Tim. http://webrtchacks.com/tim-rant/ >=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk From christer.holmberg@ericsson.com Mon Feb 10 05:51: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 0AB921A02A9 for ; Mon, 10 Feb 2014 05:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 hqo7No9j4q_m for ; Mon, 10 Feb 2014 05:51:47 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3318E1A02C9 for ; Mon, 10 Feb 2014 05:51:46 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-93-52f8d9726d76 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id EA.FD.04853.279D8F25; Mon, 10 Feb 2014 14:51:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 14:51:45 +0100 From: Christer Holmberg To: Tim Panton Thread-Topic: [rtcweb] How to determine TLS roles? Thread-Index: Ac8mZBiXQux1+cpSRGeFwm+/NhCfyP//88iA///u0BA= Date: Mon, 10 Feb 2014 13:51:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> In-Reply-To: <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+JvjW7RzR9BBie6ZCzW/mtnt7i4/Raj A5PHkiU/gcSkRrYApigum5TUnMyy1CJ9uwSujDcTZrMUNHJVnJ+8nrGB8T57FyMnh4SAicTD b/+ZIGwxiQv31rOB2EICJxgldv1Q6GLkArIXM0pMeH8GqIGDg03AQqL7nzZIjYiAmsS5H4eZ QWxmAXWJO4vPgc0UFjCUWPp4LhNEjZHE7KWdbBC2lcSW1U8YQWwWAVWJadOngdXzCvhKfO6b xwyxt4NRYuUhGRCbU8BVomv5fLAaRqDbvp9awwSxS1zi1pP5UDcLSCzZc54ZwhaVePn4HyuE rSix82w71G06Egt2f2KDsLUlli18zQyxV1Di5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxShZ nFpcnJtuZKCXm55bopdalJlcXJyfp1ecuokRGEUHt/w22sF4co/9IUZpDhYlcd7rrDVBQgLp iSWp2ampBalF8UWlOanFhxiZODilGhgXXbzQFb792sHY2BnfForNv2bodrlmh232pcTzmr+3 H+gVVqr0y7c8v8RZ6/8uScXmJ/Ib4tVKUpbzOhxc1J7zb1mPyKoCcasOX4ZZayfdcWsvbUqe qi/0darlXM7K+2rFO05N+P3vKcfXwzsUzTQdjL4skYxSVvG88Ddg2o11Uw81/k3Rsy5XYinO SDTUYi4qTgQAupRMznACAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 13:51:49 -0000 Hi, >> If I understand correctly, in RTCWEB we are going to use a single DTLS a= ssociation for two things: >>=20 >> 1) Key exchange for SRTP >> 2) The data channel >>=20 >> Now, this means that there needs to be a generic way to determine the TL= S roles. >>=20 >> In WEBRTC, how are the TLS roles determined? > > That was the subject of a rant of mine. > > I think the correct answer is that the party that ends up being IceContro= lling then becomes the DTLS client. Typically the initiator of a session is= IceControlling.=20 > > However the recent addition of > a=3Dsetup:passive > to chrome's SDP clouds the story somewhat, allowing an IceController to s= ay that it is DTLS passive and allow the non-initiator to be the DTLS clien= t. > > Ostensibly this is to support early media - where the receiver of a call = wishes to send media before the initiator does. > > As I said (rather intemperately) this added complexity is not worth the b= enefit. I think that it should be possible for a JS App to explicitly set the roles= . Because, when SDP O/A is used on the wire, there are specified rules on how= the roles are determined. But, some other on-the-wire protocol may have di= fferent rules. Regards, Christer From christer.holmberg@ericsson.com Mon Feb 10 06:23: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 E527E1A0865 for ; Mon, 10 Feb 2014 06:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 bTnxDzbytPoe for ; Mon, 10 Feb 2014 06:23:56 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2A71A02FA for ; Mon, 10 Feb 2014 06:23:55 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-9c-52f8e0fab08e Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id BC.23.04853.AF0E8F25; Mon, 10 Feb 2014 15:23:55 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 15:23:54 +0100 From: Christer Holmberg To: Tim Panton Thread-Topic: [rtcweb] How to determine TLS roles? Thread-Index: Ac8mZBiXQux1+cpSRGeFwm+/NhCfyP//88iA///u0BCAABk5gP//7dsw Date: Mon, 10 Feb 2014 14:23:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> In-Reply-To: <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvje7vBz+CDPbMZbRY+6+d3eLi9luM DkweS5b8BBKTGtkCmKK4bFJSczLLUov07RK4MuYfnMxW8I234t/vvywNjB+5uhg5OSQETCSW ndvLDGGLSVy4t56ti5GLQ0jgBKPEl02XWCCcxYwSe+89AnI4ONgELCS6/2mDNIgIqEmc+3EY rJlZQF3izuJz7CC2sIChxNLHc5kgaowkZi/tZANpFRFwk9h1Qx3EZBFQlfhyMA6kglfAV+Jd 93RGiE3tTBJTJkwEG8kp4Crxb9sRNhCbEei276fWMEGsEpe49WQ+E8TNAhJL9pyHul9U4uXj f6wQtqLEzrPtUKfpSCzY/YkNwtaWWLbwNTPEYkGJkzOfsExgFJuFZOwsJC2zkLTMQtKygJFl FaNkcWpxcW66kYFebnpuiV5qUWZycXF+nl5x6iZGYBQd3PLbaAfjyT32hxilOViUxHmvs9YE CQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDcKZuyvGe9eYH050/VeVccjsffOHTXnu3zyvPN UqJRt9/lRAXr7pO1+dfPzqqt+/fdnyq/V9yMT2903stt37Nxlecvv3dpLu92nbghnBFleOxK qfWqt1nJC5gOJm2V7rLdz2qTZLTcVFJO7aPqtN++fp9vumucnZ92ltd024et6f7lK8XU7nQo sRRnJBpqMRcVJwIAfk+J9XACAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 14:23:58 -0000 Hi, >>>> If I understand correctly, in RTCWEB we are going to use a single DTLS= association for two things: >>>>=20 >>>> 1) Key exchange for SRTP >>>> 2) The data channel >>>>=20 >>>> Now, this means that there needs to be a generic way to determine the = TLS roles. >>>>=20 >>>> In WEBRTC, how are the TLS roles determined? >>>=20 >>> That was the subject of a rant of mine. >>>=20 >>> I think the correct answer is that the party that ends up being IceCont= rolling then becomes the DTLS client. Typically the initiator of a session = is IceControlling.=20 >>>=20 >>> However the recent addition of >>>> a=3Dsetup:passive >>> to chrome's SDP clouds the story somewhat, allowing an IceController to= say that it is DTLS passive and allow the non-initiator to be the DTLS cli= ent. >>>=20 >>> Ostensibly this is to support early media - where the receiver of a cal= l wishes to send media before the initiator does. >>>=20 >>> As I said (rather intemperately) this added complexity is not worth the= benefit. >>=20 >> I think that it should be possible for a JS App to explicitly set the ro= les. >>=20 >> Because, when SDP O/A is used on the wire, there are specified rules on = how the roles are determined. But, some other on-the-wire protocol may have= different rules. >>=20 > There are many things that the JS app will need to do if we aren't bound = by SDP O/A - but I agreed not to talk about that - until after 1.0 gets out= :-) Fair enough, but for 1.0 we still need to know how the roles are determined= :) The security-arch document does say that a DTLS handshake is performed on e= ach channel that has been established by ICE, but I don't find anything reg= arding the roles. Regards, Christer From tim@phonefromhere.com Mon Feb 10 06:24: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 ED1141A086B for ; Mon, 10 Feb 2014 06:24:43 -0800 (PST) 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 G53EdffVOfRI for ; Mon, 10 Feb 2014 06:24:42 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 670301A0887 for ; Mon, 10 Feb 2014 06:14:30 -0800 (PST) Received: (qmail 26339 invoked from network); 10 Feb 2014 14:14:29 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 11689 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 10 Feb 2014 14:14:29 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 4397918A033B; Mon, 10 Feb 2014 14:14:29 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 0F8C918A0194; Mon, 10 Feb 2014 14:14:28 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> Date: Mon, 10 Feb 2014 14:14:19 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1827) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 14:24:44 -0000 On 10 Feb 2014, at 13:51, Christer Holmberg = wrote: > Hi, >=20 >>> If I understand correctly, in RTCWEB we are going to use a single = DTLS association for two things: >>>=20 >>> 1) Key exchange for SRTP >>> 2) The data channel >>>=20 >>> Now, this means that there needs to be a generic way to determine = the TLS roles. >>>=20 >>> In WEBRTC, how are the TLS roles determined? >>=20 >> That was the subject of a rant of mine. >>=20 >> I think the correct answer is that the party that ends up being = IceControlling then becomes the DTLS client. Typically the initiator of = a session is IceControlling.=20 >>=20 >> However the recent addition of >> a=3Dsetup:passive >> to chrome's SDP clouds the story somewhat, allowing an IceController = to say that it is DTLS passive and allow the non-initiator to be the = DTLS client. >>=20 >> Ostensibly this is to support early media - where the receiver of a = call wishes to send media before the initiator does. >>=20 >> As I said (rather intemperately) this added complexity is not worth = the benefit. >=20 > I think that it should be possible for a JS App to explicitly set the = roles. >=20 > Because, when SDP O/A is used on the wire, there are specified rules = on how the roles are determined. But, some other on-the-wire protocol = may have different rules. >=20 > Regards, >=20 > Christer >=20 There are many things that the JS app will need to do if we aren't bound = by SDP O/A - but I agreed not to talk about that - until after 1.0 gets out :-) T. From ekr@rtfm.com Mon Feb 10 06:48: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 689601A0846 for ; Mon, 10 Feb 2014 06:48:56 -0800 (PST) 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 rb0FjVPrkKMv for ; Mon, 10 Feb 2014 06:48:54 -0800 (PST) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id 179521A02E1 for ; Mon, 10 Feb 2014 06:48:54 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id 11so4769236vbe.38 for ; Mon, 10 Feb 2014 06:48:53 -0800 (PST) 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=q4+SCNpenmuv7Sib85VijN3ReuTCjnkpxfSOVpb3vqI=; b=eCv5WCQa47QTXh0esk5mdFPCIlf2jvSVS2Wekm4ypi+CW4+PcZDEkPOh4azEhPW73+ y1/YSQ1fVQJfOIZaYlhrJDiAkhcHgyeDXOJADx14wJzzKGjc6+RLPHdeXavW8le9OdjJ nh9EXBjpPIsr09thpdtAQOmuK6JMHBCY3PqZHb7y/zLLq3vMp79xCU85z+DA3XyUkUO7 1A7dPDLBg5PfdhHUXXK9lUJXnYy5alOVBJQSIU8CZPbs0/C2KR6z6ACA1HIqxEPs6rz4 YkhjFEtyWG1pcfNNoTVrybXegl6l1Hw8EJ/WQ9OTrI+O5C3qX4JC8Vy2dG8tbaolmaA3 Cy2Q== X-Gm-Message-State: ALoCoQlMhtyr6ed4P5NYkER0fqT4dYI8I/LvgFmQqZ/hYc6EzqImXgu5ognLNL5H+w4Vx7i8HIJs X-Received: by 10.52.61.168 with SMTP id q8mr172396vdr.40.1392043733761; Mon, 10 Feb 2014 06:48:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.106.162 with HTTP; Mon, 10 Feb 2014 06:48:13 -0800 (PST) X-Originating-IP: [74.95.2.168] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Mon, 10 Feb 2014 06:48:13 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1136b37443522804f20e7035 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 14:48:56 -0000 --001a1136b37443522804f20e7035 Content-Type: text/plain; charset=ISO-8859-1 This is defined in RFC 5763 S 5: http://tools.ietf.org/html/rfc5763#section-5 Which points to: http://tools.ietf.org/html/rfc4145 -Ekr On Mon, Feb 10, 2014 at 6:23 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>>> If I understand correctly, in RTCWEB we are going to use a single > DTLS association for two things: > >>>> > >>>> 1) Key exchange for SRTP > >>>> 2) The data channel > >>>> > >>>> Now, this means that there needs to be a generic way to determine the > TLS roles. > >>>> > >>>> In WEBRTC, how are the TLS roles determined? > >>> > >>> That was the subject of a rant of mine. > >>> > >>> I think the correct answer is that the party that ends up being > IceControlling then becomes the DTLS client. Typically the initiator of a > session is IceControlling. > >>> > >>> However the recent addition of > >>>> a=setup:passive > >>> to chrome's SDP clouds the story somewhat, allowing an IceController > to say that it is DTLS passive and allow the non-initiator to be the DTLS > client. > >>> > >>> Ostensibly this is to support early media - where the receiver of a > call wishes to send media before the initiator does. > >>> > >>> As I said (rather intemperately) this added complexity is not worth > the benefit. > >> > >> I think that it should be possible for a JS App to explicitly set the > roles. > >> > >> Because, when SDP O/A is used on the wire, there are specified rules on > how the roles are determined. But, some other on-the-wire protocol may have > different rules. > >> > > There are many things that the JS app will need to do if we aren't bound > by SDP O/A - but I agreed not to talk about that - until after 1.0 gets out > :-) > > Fair enough, but for 1.0 we still need to know how the roles are > determined :) > > The security-arch document does say that a DTLS handshake is performed on > each channel that has been established by ICE, but I don't find anything > regarding the roles. > > Regards, > > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1136b37443522804f20e7035 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is defined in RFC 5763 S 5:

Which points to:


On Mon,= Feb 10, 2014 at 6:23 AM, Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:
Hi,

>>>> If I understand correctly, in RTCWEB we are going to use a= single DTLS association for two things:
>>>>
>>>> 1) =A0 =A0 =A0Key exchange for SRTP
>>>> 2) =A0 =A0 =A0The data channel
>>>>
>>>> Now, this means that there needs to be a generic way to de= termine the TLS roles.
>>>>
>>>> In WEBRTC, how are the TLS roles determined?
>>>
>>> That was the subject of a rant of mine.
>>>
>>> I think the correct answer is that the party that ends up bein= g IceControlling then becomes the DTLS client. Typically the initiator of a= session is IceControlling.
>>>
>>> However the recent addition of
>>>> a=3Dsetup:passive
>>> to chrome's SDP clouds the story somewhat, allowing an Ice= Controller to say that it is DTLS passive and allow the non-initiator to be= the DTLS client.
>>>
>>> Ostensibly this is to support early media - where the receiver= of a call wishes to send media before the initiator does.
>>>
>>> As I said (rather intemperately) this added complexity is not = worth the benefit.
>>
>> I think that it should be possible for a JS App to explicitly set = the roles.
>>
>> Because, when SDP O/A is used on the wire, there are specified rul= es on how the roles are determined. But, some other on-the-wire protocol ma= y have different rules.
>>
> There are many things that the JS app will need = to do if we aren't bound by SDP O/A - but I agreed not to talk about th= at - until after 1.0 gets out :-)

Fair enough, but for 1.0 we still need to know how the roles are dete= rmined :)

The security-arch document does say that a DTLS handshake is performed on e= ach channel that has been established by ICE, but I don't find anything= regarding the roles.

Regards,

Christer
___________________________________= ____________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--001a1136b37443522804f20e7035-- From christer.holmberg@ericsson.com Mon Feb 10 08:37: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 4433A1A0882 for ; Mon, 10 Feb 2014 08:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 NKnQShGZb7ma for ; Mon, 10 Feb 2014 08:37:42 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 85CF41A0887 for ; Mon, 10 Feb 2014 08:37:41 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-5b-52f900548e1b Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 99.48.10875.45009F25; Mon, 10 Feb 2014 17:37:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 17:37:40 +0100 From: Christer Holmberg To: Eric Rescorla Thread-Topic: [rtcweb] How to determine TLS roles? Thread-Index: Ac8mZBiXQux1+cpSRGeFwm+/NhCfyP//88iA///u0BCAABk5gP//7dswgAAbnoCAAC3h+A== Date: Mon, 10 Feb 2014 16:37:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@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.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvjW4Iw88gg1v3DS1WvD7HbrH2Xzu7 xcXttxgdmD2WLPnJ5LFkUiObx+THbcwBzFFcNimpOZllqUX6dglcGZNOpRW0i1UcmTSfpYFx j2AXIyeHhICJxIdl69ggbDGJC/fWA9lcHEIChxglln/eyQThLGaUWH/qBXMXIwcHm4CFRPc/ bZAGEQEFiV9/TrCA2MwC3hL/ptwAGyQsYCix9PFcJogaI4nZSzvZIOwwiccdx1hBbBYBVYkT K56C9fIK+Ep8vvmJGWLXBGaJCZ0v2UESnAKBEpM/tYMVMQJd9/3UGiaIZeISt57MZ4K4WkBi yZ7zzBC2qMTLx/9YQe6UEFCSmLY1DaJcR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo9gsJFNn IWmZhaRlFpKWBYwsqxjZcxMzc9LLDTcxAqPm4JbfujsYT50TOcQozcGiJM774a1zkJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQZGr7Yz/OVzW2Zbbbl9f+WFy+b2bTFiC1QTXO2UiquWJScX iT+7oNDlKrnd0qhq70TndyW65UcCLCQmTN3//djmwrZnr1r0JxpHvHy55lz8edvMM5ItkjPf V246sbhg8jXdBxfl256qqppdjcn8LHXWbkLcNlPRvx5tNeqeRUE+HxhiNn55zqavxFKckWio xVxUnAgA88lsj2gCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 16:37:44 -0000 Hi, >This is defined in RFC 5763 S 5: >http://tools.ietf.org/html/rfc5763#section-5 > >Which points to: >http://tools.ietf.org/html/rfc4145 Ok. So, a few questions to for clarification: Q1: This means that the JS App must set the setup attrbute value before pas= sing an SDP to the browser? Q2: If SDP O/A is not used on the wire, there needs to be another mechanism= for the peers to negotiate/indicate who is "active" and who is "passive"? Q3: If you have mulitple m- lines, all using the same DTLS association, the= setup attribute value must be identical in all m- lines? Q4: The data channel (DTLS/SCTP) will have the same rule (e.g. using the se= tup attribute value) as DTLS/SRTP for determining the TLS role? Regards, Christer On Mon, Feb 10, 2014 at 6:23 AM, Christer Holmberg > wrote: Hi, >>>> If I understand correctly, in RTCWEB we are going to use a single DTLS= association for two things: >>>> >>>> 1) Key exchange for SRTP >>>> 2) The data channel >>>> >>>> Now, this means that there needs to be a generic way to determine the = TLS roles. >>>> >>>> In WEBRTC, how are the TLS roles determined? >>> >>> That was the subject of a rant of mine. >>> >>> I think the correct answer is that the party that ends up being IceCont= rolling then becomes the DTLS client. Typically the initiator of a session = is IceControlling. >>> >>> However the recent addition of >>>> a=3Dsetup:passive >>> to chrome's SDP clouds the story somewhat, allowing an IceController to= say that it is DTLS passive and allow the non-initiator to be the DTLS cli= ent. >>> >>> Ostensibly this is to support early media - where the receiver of a cal= l wishes to send media before the initiator does. >>> >>> As I said (rather intemperately) this added complexity is not worth the= benefit. >> >> I think that it should be possible for a JS App to explicitly set the ro= les. >> >> Because, when SDP O/A is used on the wire, there are specified rules on = how the roles are determined. But, some other on-the-wire protocol may have= different rules. >> > There are many things that the JS app will need to do if we aren't bound = by SDP O/A - but I agreed not to talk about that - until after 1.0 gets out= :-) Fair enough, but for 1.0 we still need to know how the roles are determined= :) The security-arch document does say that a DTLS handshake is performed on e= ach channel that has been established by ICE, but I don't find anything reg= arding the roles. Regards, Christer _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From Michael.Tuexen@lurchi.franken.de Mon Feb 10 08:56: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 E6C5C1A03A5 for ; Mon, 10 Feb 2014 08:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548, 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 EkF1FVg4OCvd for ; Mon, 10 Feb 2014 08:56:51 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id DD7D31A0406 for ; Mon, 10 Feb 2014 08:56:50 -0800 (PST) Received: from [192.168.1.103] (p508F3BD7.dip0.t-ipconnect.de [80.143.59.215]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EE3D51C0E97BB; Mon, 10 Feb 2014 17:56:48 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D166F8C@ESESSMB209.ericsson.se> Date: Mon, 10 Feb 2014 17:56:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se> <4616BFFA-F461-4CE8-9D85-211B86D4BE93@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166D7B@ESESSMB209.ericsson.se> <71288EED-3C82-44A7-950B-EFEFA62616E6@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166F8C@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 16:56:54 -0000 On Feb 10, 2014, at 12:31 PM, Christer Holmberg = wrote: > Hi, >=20 >>>>> As is defined in the data channel protocol, an entity can send = data once DATA_CHANNEL_OPEN has been sent, before the associated = DATA_CHANNEL_ACK is received. >>>>>=20 >>>>> The draft also says that, if both endpoints send DATA_CHANNEL_OPEN = at the same time, using different stream id values, the result may be = TWO data channels, with data sent on both. >>>>>=20 >>>>> However, as is also indicated, the draft does not provide a = mechanism to prevent/handle such glare situation. >>>>>=20 >>>>> I personally think there shall be a way to prevent such situation, = or otherwise I'm sure we are going to end up with interoperability = problems. >>>>>=20 >>>>> Couldn't we e.g. say that, by default, the DTLS client is = responsible for sending the DATA_CHANNEL_OPEN? Then there is no risk for = glare, and it could even use both an even or odd stream id value. >>>> Section 4 reads: >>>>=20 >>>> To avoid glare in opening Channels, each side MUST use either even=20= >>>> or odd Streams when sending a DATA_CHANNEL_OPEN message. The = method =20 >>>> used to determine which side uses odd or even is based on the =20 >>>> underlying DTLS connection role when used in WebRTC, with the side =20= >>>> acting as the DTLS client using even stream identifiers. >>>>=20 >>>> So there is no problem in setting up data channels. >>>>=20 >>>> This should not be confused by both sides setting up a data channel = with the same Label. This ends up in two data channels with the same = label. >>>> You can even create more data channels with the same label. >>>=20 >>> My point is that I don't want to end up with more than one channel. >> And you won't, see above.=20 >=20 > I am not sure I understand. What text do you refer to? To avoid glare in opening Channels, each side MUST use either even=20 or odd Streams when sending a DATA_CHANNEL_OPEN message. The method =20= used to determine which side uses odd or even is based on the =20 underlying DTLS connection role when used in WebRTC, with the side =20 acting as the DTLS client using even stream identifiers. >=20 >> However, there is no mechanism to ensure uniqueness for labels. The = WebRTC API already allows one side to create n data channels with the = same label. >=20 > I am not saying it should be forbidden to do so. But, for protocol X, = I want to end up with ONE data channel between my peers. Then only one side should create a data channel. >=20 > If I end up with two data channels for protocol X, can I send data on = whichever I want to?=20 Sure. These would be two independent bidirectional data channels. Best regards Michael >=20 > Regards, >=20 > Christer >=20 >=20 From christer.holmberg@ericsson.com Mon Feb 10 09:30: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 162761A088E for ; Mon, 10 Feb 2014 09:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 WOl-dFURH7jD for ; Mon, 10 Feb 2014 09:30:37 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id F353F1A08B3 for ; Mon, 10 Feb 2014 09:29:59 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-90-52f90c96aade Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BC.E0.23809.69C09F25; Mon, 10 Feb 2014 18:29:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 18:29:58 +0100 From: Christer Holmberg To: Michael Tuexen Thread-Topic: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare Thread-Index: Ac8mR2/m3LFj8oi+SFKLxbYiytu9PP//8tkA///uSjCAABcpAP//4ZBAgACIq4CAABjmcw== Date: Mon, 10 Feb 2014 17:29:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D167A2E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se> <4616BFFA-F461-4CE8-9D85-211B86D4BE93@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166D7B@ESESSMB209.ericsson.se> <71288EED-3C82-44A7-950B-EFEFA62616E6@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166F8C@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvje50np9BBhvn8VtcbFrCaLH2Xzu7 A5PHkiU/mTw2tOxgCmCK4rJJSc3JLEst0rdL4Mq4uTGtYKlURVvDbPYGxg8iXYycHBICJhJT +laxQdhiEhfurQeyuTiEBA4xShz8No8FwlnMKDHr3wGgDAcHm4CFRPc/bZAGEQFTiYPLQWo4 OZgF1CXuLD7HDmILC/hILDuwjxmixlfi2qV5bBB2mMSL07NYQMawCKhKzPyYBBLmBSq5ee4Y E8SqFmaJU03LGUESnAKuEtN2L2MFsRmBjvt+ag0TxC5xiVtP5jNBHC0gsWTPeWYIW1Ti5eN/ rCDzJQQUJZb3y0GU60gs2P2JDcLWlli28DUzxF5BiZMzn7BMYBSbhWTqLCQts5C0zELSsoCR ZRUje25iZk56udEmRmB8HNzyW3UH451zIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAKDz307+EOenTok6w660KMV0umxl0NdPb72Cq8YQ9c6Zdef2iYMOq+193Nsft VOpadat7tcH7Gbl11lLB8z3vPJZO+bv6dGv7Gj7DrmV7P9+Q+LltU/FStouXvkXe3jrf9Fqk TsC+7rr9Tv0SB6PzZjsYHDWW77Hmmbp41gPe/4vXz5bpSe3ZlqjEUpyRaKjFXFScCADwNkSo XQIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 17:30:40 -0000 Hi, >>>>>> As is defined in the data channel protocol, an entity can send data = once DATA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_AC= K is received. >>>>>> >>>>>> The draft also says that, if both endpoints send DATA_CHANNEL_OPEN a= t the same time, using different stream id values, the result may be TWO da= ta channels, with data sent on both. >>>>>> >>>>>> However, as is also indicated, the draft does not provide a mechanis= m to prevent/handle such glare situation. >>>>>> >>>>>> I personally think there shall be a way to prevent such situation, o= r otherwise I'm sure we are going to end up with interoperability problems. >>>>>> >>>>>> Couldn't we e.g. say that, by default, the DTLS client is responsibl= e for sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and i= t could even use both an even or odd stream id value. >>>>> Section 4 reads: >>>>> >>>>> To avoid glare in opening Channels, each side MUST use either even >>>>> or odd Streams when sending a DATA_CHANNEL_OPEN message. The method >>>>> used to determine which side uses odd or even is based on the >>>>> underlying DTLS connection role when used in WebRTC, with the side >>>>> acting as the DTLS client using even stream identifiers. >>>>> >>>>> So there is no problem in setting up data channels. >>>>> >>>>> This should not be confused by both sides setting up a data channel w= ith the same Label. This ends up in two data channels with the same label. >>>>> You can even create more data channels with the same label. >>>> >>>> My point is that I don't want to end up with more than one channel. >>> And you won't, see above. >> >> I am not sure I understand. What text do you refer to? > To avoid glare in opening Channels, each side MUST use either even > or odd Streams when sending a DATA_CHANNEL_OPEN message. The method > used to determine which side uses odd or even is based on the > underlying DTLS connection role when used in WebRTC, with the side > acting as the DTLS client using even stream identifiers. That part I understand. But, this means that both endpoints may send DATA_CHANNEL_OPEN, for the sam= e protocol, and THAT is what I would like to avoid. I don't want to have tw= o bi-directional data channels for the same thing. For that reason I suggested that we could also specify which endpoint is re= sponsisble for sending DATA_CHANNEL_OPEN. >>> However, there is no mechanism to ensure uniqueness for labels. The Web= RTC API already allows one side to create n data channels with the same lab= el. >> >> I am not saying it should be forbidden to do so. But, for protocol X, I = want to end up with ONE data channel between my peers. >>Then only one side should create a data channel. >> >> If I end up with two data channels for protocol X, can I send data on wh= ichever I want to? > Sure. These would be two independent bidirectional data channels. Possible for the same protocol - and that is what I would want to avoid. I = want to send my protocol X messages on one data channel, and I would like t= o receive the protocol X messages from my peer on the same data channel. Now, one can of course solve this by reseting one of the data channels, but= then the question is which endpoint should reset :) Regards, Christer From tim@phonefromhere.com Mon Feb 10 09: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 62F031A040C for ; Mon, 10 Feb 2014 09:40:08 -0800 (PST) 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 GAU39dnTxBNr for ; Mon, 10 Feb 2014 09:40:05 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 144201A03EF for ; Mon, 10 Feb 2014 09:40:04 -0800 (PST) Received: (qmail 39898 invoked from network); 10 Feb 2014 17:40:04 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 17493 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 10 Feb 2014 17:40:04 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id ADAEE18A0463; Mon, 10 Feb 2014 17:40:02 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id E27F118A03D4; Mon, 10 Feb 2014 17:40:01 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> Date: Mon, 10 Feb 2014 17:39:46 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8991EDBE-71F3-4456-A614-A9F4926F4955@phonefromhere.com> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1827) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 17:40:08 -0000 On 10 Feb 2014, at 16:37, Christer Holmberg = wrote: >=20 > Hi, >=20 >> This is defined in RFC 5763 S 5: >> http://tools.ietf.org/html/rfc5763#section-5 >>=20 >> Which points to: >> http://tools.ietf.org/html/rfc4145 >=20 > Ok. So, a few questions to for clarification: >=20 > Q1: This means that the JS App must set the setup attrbute value = before passing an SDP to the browser? No, peer-to-peer browser calls should 'do the right thing' - based on = the initator/ice-controlling rule=20 Both browsers set=20 a=3Dsetup:act-pass meaning that we fall back to the old rules. >=20 > Q2: If SDP O/A is not used on the wire, there needs to be another = mechanism for the peers to negotiate/indicate who is "active" and who is = "passive"? >=20 If you don't care, and are locally generating the SDP for a remote offer = or answer, set=20 a=3Dsetup:act-pass=20 and the roles sort themselves out. If however you have a gateway initating a call to a browser, and it = wants to do early media (it's an 800 number gateway for example) then it sets =20 a=3Dsetup:active in the SDP it sends (or you create on it's behalf). > Q3: If you have mulitple m- lines, all using the same DTLS = association, the setup attribute value must be identical in all m- = lines? >=20 Yes, I think so. > Q4: The data channel (DTLS/SCTP) will have the same rule (e.g. using = the setup attribute value) as DTLS/SRTP for determining the TLS role? That's the way chrome seems to implement it - and presumably the way the = spec is intended. T. From pthatcher@google.com Mon Feb 10 10:21: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 371681A01F1 for ; Mon, 10 Feb 2014 10:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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, RP_MATCHES_RCVD=-0.548, 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 oFSlwkNx8p-w for ; Mon, 10 Feb 2014 10:21:35 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2C11A02E3 for ; Mon, 10 Feb 2014 10:21:33 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id bj1so6539338pad.11 for ; Mon, 10 Feb 2014 10:21:33 -0800 (PST) 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=3j3sXB8Wrm7nlNtOIwGgv7xs/odDE/vQXjZJKCvs0v8=; b=BavqcSPmZ2nmWaiOsuep3dw7pk1p2kIk6YYIhQ+bdRSTkndgzpj3FrAk7N1jHWd1RS b7qqXSYuRlyeFuGeVwnlHjhXDd75g/0paI2wa4SpLg1/KgFDKZ/pntgcp51KXwpQz4Jn hCbipywgbFsk1GlVc1Y3lHyFCSbZKq3scVqabmI3o6Rr9Pob3ga6gfolshuTQ83lyoPV /KPfZuxxqHF+vIjytsek3vHN7zBYJELJVdPj/QM0zy9QIpqp4nkoOSFmDKigzx3Ps0Sy G7GHm/rwv7Zno4kN7xOoqqYtsACbRdCFVhC9AJVBSsp5bVLLMV0ZJ05sL/QdNAl1z2Qr kSjw== 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=3j3sXB8Wrm7nlNtOIwGgv7xs/odDE/vQXjZJKCvs0v8=; b=aL8MxueH6xETUB5jj3OK0LXhARk3OT/W+zoek1wELAO2ZzNi2X4gRAmuLLPURN8Tju ULWDnC2+UTsf8jMwQUBFAkFwLC2dUJrrLCVya59L48zcZiexxpOLZKVzJHsxSIeD9WVj LW9U+SaX4To1dPfuKneXAkHz0R2Xfo7CAfs1Skv3JWc/iO1h4bkOpwj24OtuHCvRERTx rdCpFElYHnc2I/PkEtcAstUhQx7criNIv17fToWumhQEbT1WA8XhQqCRVyWaoplEmO06 I0aSqrHYQti+T5zyskyNyEyxq4+yHYVuE9rKihCMmTDAnwS6UmVknViDkOmWcKCiPMob MgPQ== X-Gm-Message-State: ALoCoQmzgmdOJrRe2xgtcs9tVLGCwZYgBWP3toblzx/OfhK9tHhspEQI/RpaGr3fEf9H/evUXtCyEq1KlIew0hMAabLXGG9D/Bwp2/Rt5b8kIJfKuYm382XqpebI7+OZLfC/IPSFVk4uh7VSUZKGMZKYEitjs5LVLkB0EfAtw9ZGCTcHSFxTiqJhdMQ4hq/5zffNuXHBph8U X-Received: by 10.66.121.131 with SMTP id lk3mr27108916pab.61.1392056493059; Mon, 10 Feb 2014 10:21:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.163.234 with HTTP; Mon, 10 Feb 2014 10:20:52 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D166D41@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D166D41@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Mon, 10 Feb 2014 10:20:52 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b2e138dc6c64504f21168d2 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Protocol: Data before DATA_CHANNEL_ACK X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 18:21:38 -0000 --047d7b2e138dc6c64504f21168d2 Content-Type: text/plain; charset=UTF-8 If you have to wait for the ACK, it's one more RTT you have to wait before you can send data. We've already got many RTTs form ICE and DTLS and what's built into SCTP. We originally didn't have an ACK message at all, in large part because we didn't want more RTTs. The ACK was put in to handle the edge case of unordered data arriving before the OPEN message. But we added it in a way that it doesn't add more RTTs. On Mon, Feb 10, 2014 at 2:20 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > As is defined in the data channel protocol, an entity can send data once > DATA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK is > received. > > What is the reason for allowing data to be sent before DATA_CHANNEL_ACK? > The sender may not even know (depends on whatever external negotiation > mechanisms are used) whether the remote peer supports the protocol to begin > with. > > It think it would be good to allow the remote peer to accept > (DATA_CHANNEL_ACK) or reject (stream reset) the DATA_CHANNEL_OPEN before > data is sent. > > Regards, > > Christer > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b2e138dc6c64504f21168d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you have to wait for the ACK, it's one more RTT you have= to wait before you can send data. =C2=A0We've already got many RTTs fo= rm ICE and DTLS and what's built into SCTP. =C2=A0We originally didn= 9;t have an ACK message at all, in large part because we didn't want mo= re RTTs. =C2=A0The ACK was put in to handle the edge case of unordered data= arriving before the OPEN message. =C2=A0But we added it in a way that it d= oesn't add more RTTs.


On Mon,= Feb 10, 2014 at 2:20 AM, Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:
Hi,

As is defined in the data channel protocol, an entity can send data once DA= TA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK is re= ceived.

What is the reason for allowing data to be sent before DATA_CHANNEL_ACK? Th= e sender may not even know (depends on whatever external negotiation mechan= isms are used) whether the remote peer supports the protocol to begin with.=

It think it would be good to allow the remote peer to accept (DATA_CHANNEL_= ACK) or reject (stream reset) the DATA_CHANNEL_OPEN before data is sent.
Regards,

Christer


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

--047d7b2e138dc6c64504f21168d2-- From Michael.Tuexen@lurchi.franken.de Mon Feb 10 11:08: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 C3C771A046A for ; Mon, 10 Feb 2014 11:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548, 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 TFvSMjmqFbTn for ; Mon, 10 Feb 2014 11:08:35 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 059EB1A03A5 for ; Mon, 10 Feb 2014 11:08:35 -0800 (PST) Received: from [192.168.1.103] (p508F3BD7.dip0.t-ipconnect.de [80.143.59.215]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3EA261C0E97BB; Mon, 10 Feb 2014 20:08:34 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D167A2E@ESESSMB209.ericsson.se> Date: Mon, 10 Feb 2014 20:08:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se> <4616BFFA-F461-4CE8-9D85-211B86D4BE93@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166D7B@ESESSMB209.ericsson.se> <71288EED-3C82-44A7-950B-EFEFA62616E6@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166F8C@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D167A2E@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 19:08:36 -0000 On Feb 10, 2014, at 6:29 PM, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>>>> As is defined in the data channel protocol, an entity can send = data once DATA_CHANNEL_OPEN has been sent, before the associated = DATA_CHANNEL_ACK is received. >>>>>>>=20 >>>>>>> The draft also says that, if both endpoints send = DATA_CHANNEL_OPEN at the same time, using different stream id values, = the result may be TWO data channels, with data sent on both. >>>>>>>=20 >>>>>>> However, as is also indicated, the draft does not provide a = mechanism to prevent/handle such glare situation. >>>>>>>=20 >>>>>>> I personally think there shall be a way to prevent such = situation, or otherwise I'm sure we are going to end up with = interoperability problems. >>>>>>>=20 >>>>>>> Couldn't we e.g. say that, by default, the DTLS client is = responsible for sending the DATA_CHANNEL_OPEN? Then there is no risk for = glare, and it could even use both an even or odd stream id value. >>>>>> Section 4 reads: >>>>>>=20 >>>>>> To avoid glare in opening Channels, each side MUST use either = even >>>>>> or odd Streams when sending a DATA_CHANNEL_OPEN message. The = method >>>>>> used to determine which side uses odd or even is based on the >>>>>> underlying DTLS connection role when used in WebRTC, with the = side >>>>>> acting as the DTLS client using even stream identifiers. >>>>>>=20 >>>>>> So there is no problem in setting up data channels. >>>>>>=20 >>>>>> This should not be confused by both sides setting up a data = channel with the same Label. This ends up in two data channels with the = same label. >>>>>> You can even create more data channels with the same label. >>>>>=20 >>>>> My point is that I don't want to end up with more than one = channel. >>>> And you won't, see above. >>>=20 >>> I am not sure I understand. What text do you refer to? >> To avoid glare in opening Channels, each side MUST use either even >> or odd Streams when sending a DATA_CHANNEL_OPEN message. The method >> used to determine which side uses odd or even is based on the >> underlying DTLS connection role when used in WebRTC, with the side >> acting as the DTLS client using even stream identifiers. >=20 > That part I understand. >=20 > But, this means that both endpoints may send DATA_CHANNEL_OPEN, for = the same protocol, and THAT is what I would like to avoid. I don't want = to have two bi-directional data channels for the same thing. >=20 > For that reason I suggested that we could also specify which endpoint = is responsisble for sending DATA_CHANNEL_OPEN. But what if the side not allowed to send DATA_CHANNEL_OPEN messages = creates a data channel? The JS API allows both sides to create data channels. >=20 >=20 >>>> However, there is no mechanism to ensure uniqueness for labels. The = WebRTC API already allows one side to create n data channels with the = same label. >>>=20 >>> I am not saying it should be forbidden to do so. But, for protocol = X, I want to end up with ONE data channel between my peers. >>> Then only one side should create a data channel. >>>=20 >>> If I end up with two data channels for protocol X, can I send data = on whichever I want to? >> Sure. These would be two independent bidirectional data channels. >=20 > Possible for the same protocol - and that is what I would want to = avoid. I want to send my protocol X messages on one data channel, and I = would like to receive the protocol X messages from my peer on the same = data channel. That is fine. Then you have two choices: * Use the data channel (establishment) protocol and manage yourself that = only on side creates a data channel. * Don't use the data channel protocol and create the channel manually. = You need to negotiate the parameters out of band. >=20 > Now, one can of course solve this by reseting one of the data = channels, but then the question is which endpoint should reset :) You could always close the data channel with the lower stream id. Both = sides can close it... Best regards Michael >=20 > Regards, >=20 > Christer >=20 >=20 From partha@parthasarathi.co.in Mon Feb 10 11:09: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 E69521A03F5 for ; Mon, 10 Feb 2014 11:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.532 X-Spam-Level: X-Spam-Status: No, score=0.532 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 3Ofbw5S5FFr1 for ; Mon, 10 Feb 2014 11:09:20 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.234]) by ietfa.amsl.com (Postfix) with ESMTP id EA4E61A03A5 for ; Mon, 10 Feb 2014 11:09:19 -0800 (PST) Received: from userPC (unknown [122.172.231.29]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 7E60E6390DE; Mon, 10 Feb 2014 19:09:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1392059359; bh=ugljCc6vU4YfMufK1xasG2oD15hDVU4IAxJd+7K8RoM=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=fg0kpkQGn7saDl9LfW/Qu0QaeqhDP0AloeNJOlXWht+5+j84A8vxYq+B0Pz63feOF utAidkq2lo5p8VSuo+2pN4SAW0t8LuSRkzwMrucIT3vgvbqI6f9BQlRKWPKnvRzn0h VIN4PETec5U49bz6kFGYRMxqmAr19u7mpNu+AmbM= From: "Parthasarathi R" To: "'Magnus Westerlund'" , =?iso-8859-1?Q?'Stefan_H=E5kansson_LK'?= , References: <1447FA0C20ED5147A1AA0EF02890A64B1CF4A182@ESESSMB209.ericsson.se> <007601cf2423$2d571210$88053630$@co.in> <1447FA0C20ED5147A1AA0EF02890A64B1CF533B8@ESESSMB209.ericsson.se> <004601cf24ad$f3a1c0c0$dae54240$@co.in> <52F8B1AB.70305@ericsson.com> In-Reply-To: <52F8B1AB.70305@ericsson.com> Date: Tue, 11 Feb 2014 00:39:10 +0530 Message-ID: <013901cf2693$97c1eb30$c745c190$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8mT4hqE9CveTfBQg6Xv+2A7F9TQAAQGyzA Content-Language: en-us X-CTCH-RefID: str=0001.0A020203.52F923DF.010A, 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 70.87.28.142 Subject: Re: [rtcweb] New version of use-case draft uploaded X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 19:09:22 -0000 Hi Magnus, Thanks for proposing a new formulation of the note by the authors. I = agree with you that F2 and F29 are generic WebRTC NAT/Firewall requirements = which does not restrict ICE-TCP as one of the solution. The confusion with F31 and F32 requirements is because of the missing of WebRTC server/gateway requirements. F31 and F32 leads to the assumption = of mandating TURN servers in the WebRTC server/gateway (by some of the = WebRTC gateway Providers) as there is no text in this usecase & requirement document to clarify. I have already wrote in the separate mail thread (http://www.ietf.org/mail-archive/web/rtcweb/current/msg11338.html) to provide WebRTC server/gateway guidelines document for more clarity. Thanks Partha Note: F31 The browser must be able to use several STUN and TURN servers ---------------------------------------------------------------- F32 The browser must support the use of STUN and TURN servers that are supplied by entities other than the web application (i.e. the network provider). ---------------------------------------------------------------- > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, February 10, 2014 4:32 PM > To: Parthasarathi R; 'Stefan H=E5kansson LK'; rtcweb@ietf.org > Subject: Re: [rtcweb] New version of use-case draft uploaded >=20 > Hi Partha, >=20 > See inline >=20 > On 2014-02-08 10:12, Parthasarathi R wrote: > > Hi Stefan, > > > > > >> Yes, I did that change (TURN -> ICE). My understanding was that ICE > is > >> what is used/mandated (and it in turn makes use of STUN and TURN). > >> > > > > > > ICE is mandated in RTCWeb but I disagree to your assumption that ICE > in turn > > makes use of TURN. My concern is that The requirement document is > misleading > > about TURN requirements. ICE-TCP avoids TURN server as the = middle-box > in the > > network. ICE-TCP is host candidate whereas TURN is relay candidate > and as > > per ICE candidate selection, host candidate is preferred over relay > > candidates. >=20 > I will agree that the note as currently worded is not completely > accurate and clear. Based on the text in the preceding section, it > makes > sense to note that ICE using STUN and TURN is not the only solution > including additional ICE modes or relay services. I request the = authors > propose a new formulation of the note. >=20 > > > > In case of WebRTC servers (like conference)/gateway implementation, > WebRTC > > server is never going to be behind firewall, ICE-TCP serve the > purpose and > > there is no need of TURN server as a middle-box in the network. So, > Could > > you please correct the F31, F32 requirement text in the next = revision > of the > > draft. > > >=20 > This is a request to change two requirements. I have not seen a clear > consensus on this change. Thus, the change is rejected for now. >=20 > From my perspective your proposal for ICE-TCP based solution is a > choice > to fulfill F2 and F29, not F31 and F32. Thus, I don't see an issue for > F31 and F32 being STUN and TURN specific. >=20 > Is really the current formulations in the requirement documents a > hinder > against the WG considering an ICE-TCP based traversal addition? I = don't > see it, and if you do, can you please be clearer in your explanation > what the issue is? If not, I think your time is better spent working = on > building a clear motivation why ICE-TCP is needed to help establish a > WG > consensus on this. >=20 > Cheers >=20 > Magnus Westerlund > (As co-chair) >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From christer.holmberg@ericsson.com Mon Feb 10 11:55: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 B599B1A046A for ; Mon, 10 Feb 2014 11:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 Rc5vLrp13mur for ; Mon, 10 Feb 2014 11:55:56 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF5E1A0549 for ; Mon, 10 Feb 2014 11:55:55 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-87-52f92ecb67a6 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 6B.E7.04853.BCE29F25; Mon, 10 Feb 2014 20:55:55 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 20:55:54 +0100 From: Christer Holmberg To: Peter Thatcher Thread-Topic: [rtcweb] Data Channel Protocol: Data before DATA_CHANNEL_ACK Thread-Index: Ac8mSYxkYxWKLCWnTpOI4SR9Ce/EOgAOuZcAAAUfzMA= Date: Mon, 10 Feb 2014 19:55:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D167CCE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D166D41@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+Jvje5pvZ9BBtsnCFtcW/6a1WLtv3Z2 ByaPBZtKPZYs+ckUwBTFZZOSmpNZllqkb5fAlbHtw23mgi7Oih9/v7I2ML7h6GLk4JAQMJH4 98mvi5ETyBSTuHBvPVsXIxeHkMAJRol3m64xQTiLGSXaL71lB2lgE7CQ6P6nDdIgIqApMXly MyuIzSygLnFn8Tl2EFtYwFNiR/tUdogaL4lj79sZIWwriWsN05hBbBYBVYlzL7aD1fAK+ErM vHsDavEURomuX92sILs4BQIlXmxgAqlhBDru+6k1TBC7xCU+HLzODHG0gMSSPeehbFGJl4// sULYShJrD29nARnDDHTn+l36EK2KElO6H0KtFZQ4OfMJywRGsVlIps5C6JiFpGMWko4FjCyr GCWLU4uLc9ONDPRy03NL9FKLMpOLi/Pz9IpTNzEC4+fglt9GOxhP7rE/xCjNwaIkznudtSZI SCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6N/wyqL+sBDdnNDOJ7MuCClWPo57cXPJJO173Rl W+qE3mdKfncok0ty6dv7WXTvsdal07/7KeQZJU9YZXIr+8nOiaXxFboHgi8e55wdtcKliHXD 8U3J391jEn9NZeO4VDJjTdfLaxv3bXlpdmzVcvvZO4RftvHNfBjJHlTLd7zjkYu6v+L2DiYl luKMREMt5qLiRAAG3eZlbQIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Protocol: Data before DATA_CHANNEL_ACK X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 19:55:58 -0000 SGkgUGV0ZXIsDQoNCj4gSWYgeW91IGhhdmUgdG8gd2FpdCBmb3IgdGhlIEFDSywgaXQncyBvbmUg bW9yZSBSVFQgeW91IGhhdmUgdG8gd2FpdCBiZWZvcmUgeW91IGNhbiBzZW5kIGRhdGEuIMKgV2Un dmUgYWxyZWFkeSANCj4gZ290IG1hbnkgUlRUcyBmb3JtIElDRSBhbmQgRFRMUyBhbmQgd2hhdCdz IGJ1aWx0IGludG8gU0NUUC4gwqBXZSBvcmlnaW5hbGx5IGRpZG4ndCBoYXZlIGFuIEFDSyBtZXNz YWdlIGF0IGFsbCwgaW4gDQo+IGxhcmdlIHBhcnQgYmVjYXVzZSB3ZSBkaWRuJ3Qgd2FudCBtb3Jl IFJUVHMuIMKgVGhlIEFDSyB3YXMgcHV0IGluIHRvIGhhbmRsZSB0aGUgZWRnZSBjYXNlIG9mIHVu b3JkZXJlZCBkYXRhIGFycml2aW5nIA0KPiBiZWZvcmUgdGhlIE9QRU4gbWVzc2FnZS4gwqBCdXQg d2UgYWRkZWQgaXQgaW4gYSB3YXkgdGhhdCBpdCBkb2Vzbid0IGFkZCBtb3JlIFJUVHMuDQoNCkJ1 dCwgeW91IG1heSBub3QgZXZlbiBrbm93IHdoZXRoZXIgSSBzdXBwb3J0IHRoZSBwcm90b2NvbCB5 b3UgYXJlIHNlbmRpbmcuIFdoYXQgc2hvdWxkIEkgZG8gaWYgSSBkb24ndCBsaWtlL3N1cHBvcnQg d2hhdCB5b3Ugc2VuZD8NCg0KSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gaGF2ZSBhIFJF SiBtZXNzYWdlLCBzbyB0aGF0IEkgY2FuIGV4cGxpY2l0bHkgdGVsbCB5b3UgdGhhdCBJIGRvbid0 IHdhbnQgd2hhdCB5b3Ugc2VuZCAtIHJhdGhlciB0aGFuIG1lIHJlc2V0aW5nIHRoZSBzdHJlYW0s IG9yIG1lIG5vdCBzZW5kaW5nIGFuIEFDSyBhbmQgaG9wZSB0aGF0IHlvdSB3aWxsIGV2ZW50dWFs bHkgc3RvcCBzZW5kaW5nIGRhdGEuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From christer.holmberg@ericsson.com Mon Feb 10 12:03: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 5581D1A0473 for ; Mon, 10 Feb 2014 12:03:08 -0800 (PST) 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_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 PhYx4bVpb7Ip for ; Mon, 10 Feb 2014 12:03:05 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id D81101A0863 for ; Mon, 10 Feb 2014 12:03:04 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-5f-52f93077087e Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 8A.0A.04249.77039F25; Mon, 10 Feb 2014 21:03:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 21:03:03 +0100 From: Christer Holmberg To: Tim Panton Thread-Topic: [rtcweb] How to determine TLS roles? Thread-Index: Ac8mZBiXQux1+cpSRGeFwm+/NhCfyP//88iA///u0BCAABk5gP//7dswgAAbnoCAAC3h+IAAAg0A///I9eA= Date: Mon, 10 Feb 2014 20:03:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D167CF8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> <8991EDBE-71F3-4456-A614-A9F4926F4955@phonefromhere.com> In-Reply-To: <8991EDBE-71F3-4456-A614-A9F4926F4955@phonefromhere.com> Accept-Language: en-US Content-Language: fi-FI 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+NgFrrBLMWRmVeSWpSXmKPExsUyM+JvjW6Fwc8ggw/XmCxWvD7HbrH2Xzu7 xcXttxgdmD2WLPnJ5LFkUiObx+THbcwBzFFcNimpOZllqUX6dglcGeuu/mMqaOaraGu5zN7A 2MXdxcjJISFgIrFu3Tw2CFtM4sK99UA2F4eQwBFGiUPndjNCOIsZJdZcfMjexcjBwSZgIdH9 TxukQURATeLcj8PMIDazgKvEuZlTmEBsYQFDiXOz1rFD1BhJzF7ayQZhJ0l0T3oAVsMioCrx Y/1yRhCbV8BX4ubnu0wQu/pZJJZf/gfWzAk0dOrRt2DNjEDXfT+1hglimbjEh4PXmSGuFpBY suc8lC0q8fLxP1YIW0li7eHtLBD1OhILdn9ig7C1JZYtfM0MsVhQ4uTMJywTGMVmIRk7C0nL LCQts5C0LGBkWcXIUZxanJSbbmSwiREYOwe3/LbYwXj5r80hRmkOFiVx3o9vnYOEBNITS1Kz U1MLUovii0pzUosPMTJxcEo1MDI/+DMraW+81xedwqc/97Z+SJ+223SVwIL6K/1NEy9efG5g JsM1T6L5gI5kkMphwyMflrN/+ubS9OKY+dmXh3IWnNlQxTDh9eTbO2fe1f9yLDpq65KEYydj cpSKWGZfUg9W+/2Yb57O34My/yLS4jcKaAdO8XvKOLPP66eVBoul8nmGf4snrLikxFKckWio xVxUnAgAfOteeGsCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 20:03:08 -0000 Hi, >>> This is defined in RFC 5763 S 5: >>> http://tools.ietf.org/html/rfc5763#section-5 >>>=20 >>> Which points to: >>> http://tools.ietf.org/html/rfc4145 >>=20 >> Ok. So, a few questions to for clarification: >>=20 >> Q1: This means that the JS App must set the setup attrbute value before = passing an SDP to the browser? > No, peer-to-peer browser calls should 'do the right thing' - based on the= initator/ice-controlling rule Both browsers set a=3Dsetup:act-pass meaning= that we fall back to the old rules. What "old rules"? :) >> Q2: If SDP O/A is not used on the wire, there needs to be another mechan= ism for the peers to negotiate/indicate who is "active" and who is "passive= "? >>=20 > If you don't care, and are locally generating the SDP for a remote offer = or answer, set a=3Dsetup:act-pass and the roles sort themselves out. According to the "old rules", right? :) >If however you have a gateway initating a call to a browser, and it wants = to do early media (it's an 800 number gateway for example) then it sets a= =3Dsetup:active >in the SDP it sends (or you create on it's behalf). There doesn't necessarily have to be a gateway. It may be a browser-to-brow= ser call, using SIP and SDP O/A on the wire - meaning that the SDP setup at= tribute is used to determine the roles. >> Q3: If you have mulitple m- lines, all using the same DTLS association, = the setup attribute value must be identical in all m- lines? >>=20 > > Yes, I think so. > >> Q4: The data channel (DTLS/SCTP) will have the same rule (e.g. using the= setup attribute value) as DTLS/SRTP for determining the TLS role? > > That's the way chrome seems to implement it - and presumably the way the = spec is intended. Ok. Regards, Christer From pthatcher@google.com Mon Feb 10 12:05: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 7328D1A089E for ; Mon, 10 Feb 2014 12:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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, RP_MATCHES_RCVD=-0.548, 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 PIcm4m_rJtrG for ; Mon, 10 Feb 2014 12:05:18 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id D28521A0882 for ; Mon, 10 Feb 2014 12:05:18 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id fa1so6672419pad.28 for ; Mon, 10 Feb 2014 12:05:18 -0800 (PST) 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=5YoLpZj3aJoFoTr8v1MV2fyB9F4RzcVBs2ZHzfo8+Oo=; b=CCLWzXV5hfOHzdqHDmAIZyMHGwyud1qOHR9ammb0dBfLSTZq5A4w8+w6Ks23YJAbvZ BAe0qmv0Y5j3H6L4Xn+b+mAJEL0rQUcOILuBgu3aq6f9dseyhsRtNa28lqZWCMK5kwpy sOUSvJXSXklYotJUiMxGL6o5LP/UfTq2dzbYEwIW9P1QsXTv9ytrKIbAeZDySGP2jB9X 4RaEhA/PBfHDlG09vxWcH5umXpOVlvZ7cv630HH/mpeKr0bQggwJ/+nvMcRahKstQ7py GSDk94b8w+c1eLbJCoHCZSSR0aDmy15xoBDIYXcgdvSpLjV608FFX61U4vQrqf4Y+n7i CCYw== 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=5YoLpZj3aJoFoTr8v1MV2fyB9F4RzcVBs2ZHzfo8+Oo=; b=mPy9Tgz7o6w7ztiWdjJpn5nbCnCyU07jPl5sgrzwhe44tmG5LBZ40YErFCYZGumK48 EakI0VEjZ3sQznh13k2wzDtkFicyWnRKfSsDqdgZBdRDQjGEGKjap8Kqqi1atWnT0i3z Wd4FB2IXIQN9nrevrZsJEwFO94Z7r+cDQKoX7XOYEyE3mtjF4xnReYYtgUHj1uDQabQH dV56xFtABbbDhnsOjiHVRLli7mUDnlc0/+AQeNeYm8ic60Es3mNQP9WDTilkI6eGBK0U P9ZJUExn3LhqFqlObosq8y6+8sTKVM+E7ukGVEl0ctt+Yinom7gbf0SZz5U4quqGCm6J m5gA== X-Gm-Message-State: ALoCoQkt+QMDM0x1L4mYiGJeVi6PTjY2vOiP1/S/cu8/o6SCq6/35JmgftAR7mBdyjYrSHDKQOE6LpeSeApgGNJg4jdmQCRRSpUFeHksxNAhZXSgiRGuS/4NN1czdwv/Q2tIkx6K9RQ23aHcg7BrfvtYwQnQonPAz4VRQ/7tBVX0xpVibQJ/XOAyyLf5mDz9CGxaWJsMulix X-Received: by 10.66.150.69 with SMTP id ug5mr27721305pab.55.1392062718644; Mon, 10 Feb 2014 12:05:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.163.234 with HTTP; Mon, 10 Feb 2014 12:04:38 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D167CCE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D166D41@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167CCE@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Mon, 10 Feb 2014 12:04:38 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b6dc31ed9aa4404f212db59 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Protocol: Data before DATA_CHANNEL_ACK X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 20:05:21 -0000 --047d7b6dc31ed9aa4404f212db59 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 10, 2014 at 11:55 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Peter, > > > If you have to wait for the ACK, it's one more RTT you have to wait > before you can send data. We've already > > got many RTTs form ICE and DTLS and what's built into SCTP. We > originally didn't have an ACK message at all, in > > large part because we didn't want more RTTs. The ACK was put in to > handle the edge case of unordered data arriving > > before the OPEN message. But we added it in a way that it doesn't add > more RTTs. > > But, you may not even know whether I support the protocol you are sending= . > What should I do if I don't like/support what you send? > > =E2=80=8BThe signalling is up to the application to define. If your applic= ation wants to send a message from the receiver to the sender saying "I support X" or "please send me X", then by all means=E2=80=8B add that to your appli= cation, and don't call channel.send() until the sender knows it should send. > I think it would be useful to have a REJ message, so that I can explicitl= y > tell you that I don't want what you send - rather than me reseting the > stream, or me not sending an ACK and hope that you will eventually stop > sending data. > =E2=80=8B=E2=80=8BThe signalling is up to the application to define. If yo= ur application wants to send a message from the receiver to the sender saying "I don't support X" or "please don't send me X", then by all means=E2=80=8B add that= to your application, and don't call channel.send() if the receiver says it doesn't want the message. I think what is already in the standard is sufficient for your use case. You just need to add a little application-specific signalling. I don't think the in-band signalling is the right place to put things like this. > > Regards, > > Christer > > --047d7b6dc31ed9aa4404f212db59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 10, 2014 at 11:55 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi Peter,

> If you have to wait for the ACK, it's one more RTT you have to wai= t before you can send data. =C2=A0We've already
> got many RTTs form ICE and DTLS and what's built into SCTP. =C2=A0= We originally didn't have an ACK message at all, in
> large part because we didn't want more RTTs. =C2=A0The ACK was put= in to handle the edge case of unordered data arriving
> before the OPEN message. =C2=A0But we added it in a way that it doesn&= #39;t add more RTTs.

But, you may not even know whether I support the protocol you are sen= ding. What should I do if I don't like/support what you send?


=E2=80=8BThe signalling is up to the applic= ation to define. =C2=A0If your application wants to send a message from the= receiver to the sender saying "I support X" or "please send= me X", then by all means=E2=80=8B add that to your application, and d= on't call channel.send() until the sender knows it should send.

=C2=A0
I think it would be useful to have a REJ message, so that I can explicitly = tell you that I don't want what you send - rather than me reseting the = stream, or me not sending an ACK and hope that you will eventually stop sen= ding data.

=E2=80=8B=E2=80=8BThe signalling is up to the a= pplication to define. =C2=A0If your application wants to send a message fro= m the receiver to the sender saying "I don't support X" or &q= uot;please don't send me X", then by all means=E2=80=8B add that t= o your application, and don't call channel.send() if the receiver says = it doesn't want the message.

<= /div>
=
I think what is already in the standard is sufficient for your use cas= e. =C2=A0You just need to add a little application-specific signalling. =C2= =A0I don't think the in-band signalling is the right place to put thing= s like this.

=C2=A0

Regards,

Christer


--047d7b6dc31ed9aa4404f212db59-- From christer.holmberg@ericsson.com Mon Feb 10 12:18: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 EBC401A06AF for ; Mon, 10 Feb 2014 12:18:08 -0800 (PST) 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_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 cRk5QR4PuVJ4 for ; Mon, 10 Feb 2014 12:18:07 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 52E801A06F3 for ; Mon, 10 Feb 2014 12:18:07 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-8d-52f933fea56e Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 4E.1B.04249.EF339F25; Mon, 10 Feb 2014 21:18:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 21:18:06 +0100 From: Christer Holmberg To: Peter Thatcher Thread-Topic: [rtcweb] Data Channel Protocol: Data before DATA_CHANNEL_ACK Thread-Index: Ac8mSYxkYxWKLCWnTpOI4SR9Ce/EOgAOuZcAAAUfzMD///P/AP//7Pxw Date: Mon, 10 Feb 2014 20:18:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D167D92@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D166D41@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167CCE@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvje4/459BBre+aVpcW/6a1WLtv3Z2 ByaPBZtKPZYs+ckUwBTFZZOSmpNZllqkb5fAlTFro1jBB9aKwz+VGhjvsHYxcnJICJhIdD6e yQ5hi0lcuLeerYuRi0NI4AijxKxzC6GcxYwS///cY+li5OBgE7CQ6P6nDdIgIqApMXlyM9gg ZgF1iTuLz4ENEhbwlNjRPpUdosZL4tj7dkYI203izeUHLCA2i4CqxMMLC8FqeAV8Jea1H2eC 2DWfSWL1h81sIAlOgUCJwy+WMYPYjEDXfT+1hglimbjEh4PXmSGuFpBYsuc8lC0q8fLxP6jP lCTWHt4OdjMz0KHrd+lDtCpKTOl+CLVXUOLkzCcsExjFZiGZOguhYxaSjllIOhYwsqxi5ChO LU7KTTcy2MQIjI6DW35b7GC8/NfmEKM0B4uSOO/Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZ ODilGhgz3vz5svZCUdrHZGHbuSfu+hlf3uh74W+q/qHZE+5qlqfnz3dq4z9nt36msM3cM+VZ h+922pTKthwSSShP6MratN9915I3a/VzknwWL7i94oTawT9sYtxC9mVdx5+f2PejW/uTlrgB t2dxf0e/fbz0SvuIbzNl7rqlthXJcvLk35wQeH3RdRklluKMREMt5qLiRACucUOuXAIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Protocol: Data before DATA_CHANNEL_ACK X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 20:18:09 -0000 DQoNCj5JIHRoaW5rIHdoYXQgaXMgYWxyZWFkeSBpbiB0aGUgc3RhbmRhcmQgaXMgc3VmZmljaWVu dCBmb3IgeW91ciB1c2UgY2FzZS4gwqBZb3UganVzdCBuZWVkIHRvIGFkZCBhIGxpdHRsZSBhcHBs aWNhdGlvbi1zcGVjaWZpYyBzaWduYWxsaW5nLiDCoEkgZG9uJ3QgdGhpbmsgdGhlIGluLWJhbmQg c2lnbmFsbGluZyBpcyB0aGUgcmlnaHQgcGxhY2UgdG8gcHV0IHRoaW5ncyBsaWtlIHRoaXMuDQoN CklmIGl0IGlzIHN1ZmZpY2llbnQgdG8gdXNlIGluLWJhbmQgc2lnbmFsbGluZyB0byBzYXkg4oCd SSB3b3VsZCBsaWtlIHRvIHNlbmQgeW91IHRoaXMgZGF0YeKAnSwgSSB0aGluayBpdCBpcyBlcXVh bGx5IHN1ZmZpY2llbnQgdG8gdXNlIGluLWJhbmQgc2lnbmFsaW5nIHRvIHJlcGx5IOKAnE5vLCBJ IGRvbuKAmXQgd2FudCB0aGF0IGRhdGHigJ0uLi4NCg0KQW55d2F5LCBpZiBwZW9wbGUgZG9uJ3Qg dGhpbmsgaXQncyBuZWVkZWQsIHRoZW4gSSBndWVzcyBvbmUgY2FuIHNpbXBseSByZXNldCB0aGUg c3RyZWFtLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From tim@phonefromhere.com Mon Feb 10 12:22: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 87DF91A0835 for ; Mon, 10 Feb 2014 12:22:36 -0800 (PST) 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 7D3wDRA4iTAu for ; Mon, 10 Feb 2014 12:22:30 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by ietfa.amsl.com (Postfix) with ESMTP id 4E92A1A06F3 for ; Mon, 10 Feb 2014 12:22:30 -0800 (PST) Received: (qmail 3981 invoked from network); 10 Feb 2014 20:22:29 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 19484 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 10 Feb 2014 20:22:29 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 6810A18A03CA; Mon, 10 Feb 2014 20:22:29 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 1E8C118A03C9; Mon, 10 Feb 2014 20:22:29 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D167CF8@ESESSMB209.ericsson.se> Date: Mon, 10 Feb 2014 20:22:09 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1FC0C1C7-E5AB-4D4C-ABCC-8371457DCBF0@phonefromhere.com> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> <8991EDBE-71F3-4456-A614-A9F4926F4955@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167CF8@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1827) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 20:22:37 -0000 On 10 Feb 2014, at 20:03, Christer Holmberg = wrote: > Hi, >=20 >>>> This is defined in RFC 5763 S 5: >>>> http://tools.ietf.org/html/rfc5763#section-5 >>>>=20 >>>> Which points to: >>>> http://tools.ietf.org/html/rfc4145 >>>=20 >>> Ok. So, a few questions to for clarification: >>>=20 >>> Q1: This means that the JS App must set the setup attrbute value = before passing an SDP to the browser? >> No, peer-to-peer browser calls should 'do the right thing' - based on = the initator/ice-controlling rule Both browsers set a=3Dsetup:act-pass = meaning that we fall back to the old rules. >=20 > What "old rules"? :) >=20 Sorry that was unclear - As I read it, putting=20 a=3Dsetup:actpass=20 in the SDP indicates that the ice-controlling entity should act as DTLS = client, and typically the ice-controlling entity is the initiator of the = session. So it isn't a matter of O/A negotiation. >>> Q2: If SDP O/A is not used on the wire, there needs to be another = mechanism for the peers to negotiate/indicate who is "active" and who is = "passive"? >>>=20 >> If you don't care, and are locally generating the SDP for a remote = offer or answer, set a=3Dsetup:act-pass and the roles sort themselves = out. >=20 > According to the "old rules", right? :) Yeah, Ice controlling is the DTLS client.=20 >=20 >> If however you have a gateway initating a call to a browser, and it = wants to do early media (it's an 800 number gateway for example) then it = sets a=3Dsetup:active >> in the SDP it sends (or you create on it's behalf). >=20 > There doesn't necessarily have to be a gateway. It may be a = browser-to-browser call, using SIP and SDP O/A on the wire - meaning = that the SDP setup attribute is used to determine the roles. But there is no concept of early media on a peer-to-peer webRTC call, so = there isn't any need to manage which side is the DTLS client or server. >=20 >>> Q3: If you have mulitple m- lines, all using the same DTLS = association, the setup attribute value must be identical in all m- = lines? >>>=20 >>=20 >> Yes, I think so. >>=20 >>> Q4: The data channel (DTLS/SCTP) will have the same rule (e.g. using = the setup attribute value) as DTLS/SRTP for determining the TLS role? >>=20 >> That's the way chrome seems to implement it - and presumably the way = the spec is intended. >=20 > Ok. >=20 > Regards, >=20 > Christer From Michael.Tuexen@lurchi.franken.de Mon Feb 10 12:23: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 2D1501A047C for ; Mon, 10 Feb 2014 12:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548, 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 S-APAM9bFcVv for ; Mon, 10 Feb 2014 12:23:54 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id CC3971A046A for ; Mon, 10 Feb 2014 12:23:53 -0800 (PST) Received: from [192.168.1.103] (p508F3BD7.dip0.t-ipconnect.de [80.143.59.215]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0DF8E1C0E97B8; Mon, 10 Feb 2014 21:23:52 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D167D92@ESESSMB209.ericsson.se> Date: Mon, 10 Feb 2014 21:23:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4F79265D-0671-4338-ABD8-93E2BBDFB4AD@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D166D41@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167CCE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167D92@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Protocol: Data before DATA_CHANNEL_ACK X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 20:23:56 -0000 On Feb 10, 2014, at 9:18 PM, Christer Holmberg = wrote: >=20 >=20 >> I think what is already in the standard is sufficient for your use = case. You just need to add a little application-specific signalling. I = don't think the in-band signalling is the right place to put things like = this. >=20 > If it is sufficient to use in-band signalling to say =94I would like = to send you this data=94, I think it is equally sufficient to use = in-band signaling to reply =93No, I don=92t want that data=94... >=20 > Anyway, if people don't think it's needed, then I guess one can simply = reset the stream. Exactly. If the peer resets the stream before sending a = DATA_CHANNEL_ACK, it is an error. Section 6 of draft-ietf-rtcweb-data-protocol-02.txt contains Therefore, receiving an SCTP stream reset request for a stream on which = no DATA_CHANNEL_ACK message has been received indicates to the sender of = the corresponding DATA_CHANNEL_OPEN message the failure of the data = channel setup procedure. Best regards Michael >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Mon Feb 10 12:30: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 A113C1A0407 for ; Mon, 10 Feb 2014 12:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 NDkQOJkfHVZM for ; Mon, 10 Feb 2014 12:30:53 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id EEB2F1A01FD for ; Mon, 10 Feb 2014 12:30:52 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-88-52f936fbd192 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 61.2A.04853.BF639F25; Mon, 10 Feb 2014 21:30:52 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 21:30:51 +0100 From: Christer Holmberg To: Tim Panton Thread-Topic: [rtcweb] How to determine TLS roles? Thread-Index: Ac8mZBiXQux1+cpSRGeFwm+/NhCfyP//88iA///u0BCAABk5gP//7dswgAAbnoCAAC3h+IAAAg0A///I9eAADI1GgP//7kBQ Date: Mon, 10 Feb 2014 20:30:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D167EAC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> <8991EDBE-71F3-4456-A614-A9F4926F4955@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167CF8@ESESSMB209.ericsson.se> <1FC0C1C7-E5AB-4D4C-ABCC-8371457DCBF0@phonefromhere.com> In-Reply-To: <1FC0C1C7-E5AB-4D4C-ABCC-8371457DCBF0@phonefromhere.com> Accept-Language: en-US Content-Language: fi-FI 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+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvje4fs59BBr92sVmseH2O3WLtv3Z2 i4vbbzE6MHssWfKTyWPJpEY2j8mP25gDmKO4bFJSczLLUov07RK4Mnra9rMV9PJW3G+8z9rA uIuri5GTQ0LAROLi553sELaYxIV769m6GLk4hAROMErM3PSIEcJZzChxp/kPUIaDg03AQqL7 nzZIg4iAmsS5H4eZQWxmAVeJczOnMIHYwgKGEudmrWOHqDGSmL20kw3CzpM4c+gTM8gYFgFV ift74kDCvAK+EhdPdTBDrOpjlbh3eTILSIITaObHTcvAZjICHff91BomiF3iEh8OXmeGOFpA Ysme81C2qMTLx/9YIWwlibWHt7NA1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7Cwk LbOQtMxC0rKAkWUVo2RxanFxbrqRgV5uem6JXmpRZnJxcX6eXnHqJkZgbB3c8ttoB+PJPfaH GKU5WJTEea+z1gQJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYFxw1+6ArNa/h1UqHxQ28P76 t7xs1fdKv5sclYXnt11VdV481eG8oG2o8XergrDvIpd/LvEzedPgPs/jvL7XLrb9+7m5W5f8 fZ21dP2Dgwnczw1NEyc7OZbpr9oatpy17Ey3lb2Kc6T4lh/ThWPEGPa6nD350Ejj9c05q5bP 2szo4tEqUFfRsk2JpTgj0VCLuag4EQAEoOBSewIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 20:30:54 -0000 Hi, >>>>> This is defined in RFC 5763 S 5: >>>>> http://tools.ietf.org/html/rfc5763#section-5 >>>>>=20 >>>>> Which points to: >>>>> http://tools.ietf.org/html/rfc4145 >>>>=20 >>>> Ok. So, a few questions to for clarification: >>>>=20 >>>> Q1: This means that the JS App must set the setup attrbute value befor= e passing an SDP to the browser? >>> No, peer-to-peer browser calls should 'do the right thing' - based on t= he initator/ice-controlling rule Both browsers set a=3Dsetup:act-pass meani= ng that we fall back to the old rules. >>=20 >> What "old rules"? :) >>=20 > > Sorry that was unclear - As I read it, putting a=3Dsetup:actpass in the S= DP indicates that the ice-controlling entity should act as DTLS client, and= typically the ice-controlling entity is the initiator of the session. So i= t isn't a matter of O/A negotiation. Do you have a reference to where you read that? >>> If however you have a gateway initating a call to a browser, and it=20 >>> wants to do early media (it's an 800 number gateway for example) then i= t sets a=3Dsetup:active in the SDP it sends (or you create on it's behalf). >>=20 >> There doesn't necessarily have to be a gateway. It may be a browser-to-b= rowser call, using SIP and SDP O/A on the wire - meaning that the SDP setup= attribute is used to determine the roles. > > But there is no concept of early media on a peer-to-peer webRTC call, so = there isn't any need to manage which side is the DTLS client or server. Not sure what this has to do with early media. You can have two browser bas= ed applications, using SDP O/A to negotiate the DTLS roles. Regards, Christer From ekr@rtfm.com Mon Feb 10 12:42: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 657741A0701 for ; Mon, 10 Feb 2014 12:42:35 -0800 (PST) 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 fvX8Te5Ddh3e for ; Mon, 10 Feb 2014 12:42:32 -0800 (PST) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id 890CA1A0405 for ; Mon, 10 Feb 2014 12:42:32 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id oy12so5545151veb.0 for ; Mon, 10 Feb 2014 12:42:32 -0800 (PST) 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=feojh5L5RmUVhPVcb0A+30Fnar7dDvsyqcMf5re/doA=; b=jG7123TRjvKmVLqg0Ok1+6hFAILFC2d3AQklZZeC25S7wtsVAP+ZwuYxPvh7Gr3D3x hUH+u3gMA5nx+4rpStYGFVT4QVFZuWNi89In3JULWcHGY9f/Hly5CHp/tOAMbiag/SmW fsVJCfs2BRK5roGGDrGMXzR8ZpTu7TqnAOjVcfnW98fHWPCbajyaY6fjAMx/DBp/IufI NebuHdOE5Dj5mBilUhX29s1EhTtqbQcozYONjF9QqmV9TFUtxDeqsxmq6VSiXhGw5RCV WSSVKfHu4zsQJ+VIkQE3laR30o+BqrLzpHVb0AAtZpV+34+NTrxHXTI/c5u+TxY79nIw msyw== X-Gm-Message-State: ALoCoQkmETYBmX3m+uszwq5g8ZLS0egS/q7nnwxyrA+4O4rM9Wu5e0eCvAta6oUqehxmtBfOnLFd X-Received: by 10.52.110.201 with SMTP id ic9mr21253435vdb.22.1392064952139; Mon, 10 Feb 2014 12:42:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.106.162 with HTTP; Mon, 10 Feb 2014 12:41:52 -0800 (PST) X-Originating-IP: [2620:101:8003:300:c532:42b5:40ec:6bd9] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Mon, 10 Feb 2014 12:41:52 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec547c741fa1d3704f2136056 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 20:42:35 -0000 --bcaec547c741fa1d3704f2136056 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 10, 2014 at 8:37 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > >This is defined in RFC 5763 S 5: > >http://tools.ietf.org/html/rfc5763#section-5 > > > >Which points to: > >http://tools.ietf.org/html/rfc4145 > > Ok. So, a few questions to for clarification: > > Q1: This means that the JS App must set the setup attrbute value before > passing an SDP to the browser? > No. The browser does it. Q2: If SDP O/A is not used on the wire, there needs to be another mechanism > for the peers to negotiate/indicate who is "active" and who is "passive"? > I don't see how this is our problem. > Q3: If you have mulitple m- lines, all using the same DTLS association, > the setup attribute value must be identical in all m- lines? > You mean because they are bundled? This should follow the same rules we generally use for things that are bundled. > Q4: The data channel (DTLS/SCTP) will have the same rule (e.g. using the > setup attribute value) as DTLS/SRTP for determining the TLS role? > I would think so. -Ekr Regards, > > Christer > > > > > > > > On Mon, Feb 10, 2014 at 6:23 AM, Christer Holmberg < > christer.holmberg@ericsson.com> > wrote: > Hi, > > >>>> If I understand correctly, in RTCWEB we are going to use a single > DTLS association for two things: > >>>> > >>>> 1) Key exchange for SRTP > >>>> 2) The data channel > >>>> > >>>> Now, this means that there needs to be a generic way to determine the > TLS roles. > >>>> > >>>> In WEBRTC, how are the TLS roles determined? > >>> > >>> That was the subject of a rant of mine. > >>> > >>> I think the correct answer is that the party that ends up being > IceControlling then becomes the DTLS client. Typically the initiator of a > session is IceControlling. > >>> > >>> However the recent addition of > >>>> a=setup:passive > >>> to chrome's SDP clouds the story somewhat, allowing an IceController > to say that it is DTLS passive and allow the non-initiator to be the DTLS > client. > >>> > >>> Ostensibly this is to support early media - where the receiver of a > call wishes to send media before the initiator does. > >>> > >>> As I said (rather intemperately) this added complexity is not worth > the benefit. > >> > >> I think that it should be possible for a JS App to explicitly set the > roles. > >> > >> Because, when SDP O/A is used on the wire, there are specified rules on > how the roles are determined. But, some other on-the-wire protocol may have > different rules. > >> > > There are many things that the JS app will need to do if we aren't bound > by SDP O/A - but I agreed not to talk about that - until after 1.0 gets out > :-) > > Fair enough, but for 1.0 we still need to know how the roles are > determined :) > > The security-arch document does say that a DTLS handshake is performed on > each channel that has been established by ICE, but I don't find anything > regarding the roles. > > Regards, > > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec547c741fa1d3704f2136056 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 10, 2014 at 8:37 AM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:

Hi,

>This is defined in RFC 5763 S 5:
>http://tools.ietf.org/html/rfc5763#section-5
>
>Which points to:
>http:/= /tools.ietf.org/html/rfc4145

Ok. So, a few questions to for clarification:

Q1: This means that the JS App must set the setup attrbute value before pas= sing an SDP to the browser?

No. The bro= wser does it.=A0

Q2: If SDP O/A is not used on the wire, there needs to be another mechanism= for the peers to negotiate/indicate who is "active" and who is &= quot;passive"?

I don't see how= this is our problem.

=A0
Q3: If you have mulitple m- lines, all using the same DTLS association, the= setup attribute value must be identical in all m- lines?
<= div>
You mean because they are bundled? This should follow th= e same rules we generally
use for things that are bundled.
=A0
Q4: The data channel (DTLS/SCTP) will have the same rule (e.g. using the se= tup attribute value) as DTLS/SRTP for determining the TLS role?

I would think so.

-Ekr

Regards,

Christer







On Mon, Feb 10, 2014 at 6:23 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:= christer.holmberg@ericsso= n.com>> wrote:
Hi,

>>>> If I understand correctly, in RTCWEB we are going to use a= single DTLS association for two things:
>>>>
>>>> 1) =A0 =A0 =A0Key exchange for SRTP
>>>> 2) =A0 =A0 =A0The data channel
>>>>
>>>> Now, this means that there needs to be a generic way to de= termine the TLS roles.
>>>>
>>>> In WEBRTC, how are the TLS roles determined?
>>>
>>> That was the subject of a rant of mine.
>>>
>>> I think the correct answer is that the party that ends up bein= g IceControlling then becomes the DTLS client. Typically the initiator of a= session is IceControlling.
>>>
>>> However the recent addition of
>>>> a=3Dsetup:passive
>>> to chrome's SDP clouds the story somewhat, allowing an Ice= Controller to say that it is DTLS passive and allow the non-initiator to be= the DTLS client.
>>>
>>> Ostensibly this is to support early media - where the receiver= of a call wishes to send media before the initiator does.
>>>
>>> As I said (rather intemperately) this added complexity is not = worth the benefit.
>>
>> I think that it should be possible for a JS App to explicitly set = the roles.
>>
>> Because, when SDP O/A is used on the wire, there are specified rul= es on how the roles are determined. But, some other on-the-wire protocol ma= y have different rules.
>>
> There are many things that the JS app will need to do if we aren't= bound by SDP O/A - but I agreed not to talk about that - until after 1.0 g= ets out :-)

Fair enough, but for 1.0 we still need to know how the roles are determined= :)

The security-arch document does say that a DTLS handshake is performed on e= ach channel that has been established by ICE, but I don't find anything= regarding the roles.

Regards,

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


--bcaec547c741fa1d3704f2136056-- From christer.holmberg@ericsson.com Mon Feb 10 12:54: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 B55C21A0410 for ; Mon, 10 Feb 2014 12:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 aWz9FDhvTSNs for ; Mon, 10 Feb 2014 12:54:38 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7F71A06B7 for ; Mon, 10 Feb 2014 12:54:37 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-03-52f93c8c448c Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E4.12.23809.C8C39F25; Mon, 10 Feb 2014 21:54:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 21:54:36 +0100 From: Christer Holmberg To: Eric Rescorla Thread-Topic: [rtcweb] How to determine TLS roles? Thread-Index: Ac8mZBiXQux1+cpSRGeFwm+/NhCfyP//88iA///u0BCAABk5gP//7dswgAAbnoCAAC3h+IAANO4A///uyOA= Date: Mon, 10 Feb 2014 20:54:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D167F68@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvjW6Pzc8gg3WbTS1WvD7HbrH2Xzu7 xcXttxgdmD2WLPnJ5LFkUiObx+THbcwBzFFcNimpOZllqUX6dglcGad/Xmcp+MJVcWHaA9YG xuMcXYycHBICJhI/7x9ggrDFJC7cW8/WxcjFISRwiFFi5pVuZghnMaPEoudLgao4ONgELCS6 /2mDNIgIKEj8+nOCBcRmFvCW+DflBhuILSxgKHFu1jp2iBojidlLO9kg7CSJE3MXMYPYLAKq EluWvgNbzCvgK3HgzUomiF1zWSTu/f0P1swpECix6243I4jNCHTd91NrmCCWiUt8OHidGeJq AYkle85D2aISLx//Y4WwlSTWHt4OdZyexI2pU9ggbG2JZQtfM0MsFpQ4OfMJywRGsVlIxs5C 0jILScssJC0LGFlWMbLnJmbmpJcbbWIERs7BLb9VdzDeOSdyiFGag0VJnPfDW+cgIYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYwlDzS+Zto8sf/7NPmJb/3zornbtjGXO2xsUTl24LWQw9k9 7XICVkfa5kruk3hrcEz/nZLe9KD4+q97MqLKfqbMUA+8Fm0a5DrHsDTI8N2BtLObFzkV6SVJ flruvze5clFsruja65pXZFhv/S8LDavaumXuB0nFojV665OuswmdXv9eVSOh5pwSS3FGoqEW c1FxIgA/OSwUagIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 20:54:40 -0000 Hi, >>This is defined in RFC 5763 S 5: >>http://tools.ietf.org/html/rfc5763#section-5 >> >>Which points to: >>http://tools.ietf.org/html/rfc4145 > Ok. So, a few questions to for clarification: > > Q1: This means that the JS App must set the setup attrbute value before p= assing an SDP to the browser? > > No. The browser does it.=A0 > >> Q2: If SDP O/A is not used on the wire, there needs to be another mechan= ism for the peers to negotiate/indicate who is "active" and who is "passive= "? > > I don't see how this is our problem. Ok, let me rephrase: we use SDP O/A in the API between the JS App and the b= rowser, and the RFCs you pointed to above say that the SDP setup attribute = is used to negotiate the roles.=20 So, can the JS App, using the setup attribute, control the DTLS role in the= browser? >> Q3: If you have mulitple m- lines, all using the same DTLS association, = the setup attribute value must be identical in all m- lines? > > You mean because they are bundled? This should follow the same rules we g= enerally use for things that are bundled. We haven't specified the rules for the setup attribute yet, but I assume it= will have to be identical for each m- line within a BUNDLE group. And, in case the m- lines are NOT bundled, there will be separate DTLS asso= ciations, with separate roles, right? Regards, Christer From ekr@rtfm.com Mon Feb 10 14:10: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 C113D1A08B3 for ; Mon, 10 Feb 2014 14:10:13 -0800 (PST) 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 GhRSdnLZGkv4 for ; Mon, 10 Feb 2014 14:10:11 -0800 (PST) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by ietfa.amsl.com (Postfix) with ESMTP id 592661A05F4 for ; Mon, 10 Feb 2014 14:10:11 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id m10so5355113vbh.32 for ; Mon, 10 Feb 2014 14:10:11 -0800 (PST) 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=Ts7mgot6fFLBjJ8XB1Ro73l8aztsFddxioS3nuY40dQ=; b=NHiuikNmQ3tXDda5jgQwUm2m4hiyiq6TNl8l8Tl2r7+Mf44pEBOtbEoP3TpQKjdI1n QkjntRveB4uSFm/bEBsQNJyUoi1bbULdZnyCHqSZgi9aOLacG7IR6BFRPYpSklwXpt0k lj9n00AFVDPD/XOdAkBi4UTaN9QIUanJaOeoqZH72ndx2N+o/BUZdjoymE9eBsqXKmK+ +bgicjiFYgGmz2rNKnB6BPgw8TE4ISiDMLfrTFwwAn2FUKpq//ujPKrcTr96RytIhYg5 oMSl9TB9WB+mAMl/zbbNkGqZPsL+F+SQXfCpjwvnYva6/nFZFryFSrXFpVQ/mEq6ZtkJ ESWg== X-Gm-Message-State: ALoCoQlaLGjfxLvhCSvSY8XUsISKE6/HNZ6+J8PKgjFU8mOaGNMGdC/0924uBLHWV/Xb+iP+tQF/ X-Received: by 10.58.134.101 with SMTP id pj5mr6074veb.38.1392070210974; Mon, 10 Feb 2014 14:10:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.106.162 with HTTP; Mon, 10 Feb 2014 14:09:30 -0800 (PST) X-Originating-IP: [2620:101:8003:300:816b:de46:ae49:8a05] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D167F68@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167F68@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Mon, 10 Feb 2014 14:09:30 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e01183daa6d8b5c04f2149a4b Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Feb 2014 22:10:14 -0000 --089e01183daa6d8b5c04f2149a4b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 10, 2014 at 12:54 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>This is defined in RFC 5763 S 5: > >>http://tools.ietf.org/html/rfc5763#section-5 > >> > >>Which points to: > >>http://tools.ietf.org/html/rfc4145 > > Ok. So, a few questions to for clarification: > > > > Q1: This means that the JS App must set the setup attrbute value before > passing an SDP to the browser? > > > > No. The browser does it. > > > >> Q2: If SDP O/A is not used on the wire, there needs to be another > mechanism for the peers to negotiate/indicate who is "active" and who is > "passive"? > > > > I don't see how this is our problem. > > Ok, let me rephrase: we use SDP O/A in the API between the JS App and the > browser, and the RFCs you pointed to above say that the SDP setup attribute > is used to negotiate the roles. > > So, can the JS App, using the setup attribute, control the DTLS role in > the browser That ties into the general question of which a-lines can be modified in the JS app. It's no more decided than those questions. > >> Q3: If you have mulitple m- lines, all using the same DTLS association, > the setup attribute value must be identical in all m- lines? > > > > You mean because they are bundled? This should follow the same rules we > generally use for things that are bundled. > > We haven't specified the rules for the setup attribute yet, but I assume > it will have to be identical for each m- line within a BUNDLE group. > OK. > And, in case the m- lines are NOT bundled, there will be separate DTLS > associations, with separate roles, right? > Yes. -Ekr > Regards, > > Christer > --089e01183daa6d8b5c04f2149a4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 10, 2014 at 12:54 PM, Christer Holmberg <= christer.holmberg@ericsson.com> wrote:
Hi,

>>This is defined in RFC 5763 S 5:
>>http://tools.ietf.org/html/rfc5763#section-5
>>
>>Which points to:
>>ht= tp://tools.ietf.org/html/rfc4145
> Ok. So, a few questions to for clarification:
>
> Q1: This means that the JS App must set the setup attrbute value befor= e passing an SDP to the browser?
>
> No. The browser does it.=A0
>
>> Q2: If SDP O/A is not used on the wire, there needs to be another = mechanism for the peers to negotiate/indicate who is "active" and= who is "passive"?
>
> I don't see how this is our problem.

Ok, let me rephrase: we use SDP O/A in the API between the JS App and= the browser, and the RFCs you pointed to above say that the SDP setup attr= ibute is used to negotiate the roles.

So, can the JS App, using the setup attribute, control the DTLS role in the= browser

That ties into the general questio= n of which a-lines can be modified in
the JS app. It's no mor= e decided than those questions.

=A0
>> Q3: If you have mulitple m- lines, all using the same DTLS associa= tion, the setup attribute value must be identical in all m- lines?
>
> You mean because they are bundled? This should follow the same rules w= e generally use for things that are bundled.

We haven't specified the rules for the setup attribute yet, but I= assume it will have to be identical for each m- line within a BUNDLE group= .

OK.
=A0
And, in case the m- lines are NOT bundled, there will be separate DTLS asso= ciations, with separate roles, right?

Y= es.

-Ekr

=A0
Regards,

Christer

--089e01183daa6d8b5c04f2149a4b-- From pkyzivat@alum.mit.edu Mon Feb 10 17:10: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 9DDD61A0641 for ; Mon, 10 Feb 2014 17:10:10 -0800 (PST) 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 4qZCVrh2ZFoe for ; Mon, 10 Feb 2014 17:10:08 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6CB1A0630 for ; Mon, 10 Feb 2014 17:10:08 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta08.westchester.pa.mail.comcast.net with comcast id Qovo1n0020QuhwU58pA71H; Tue, 11 Feb 2014 01:10:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id QpA71n00U3ZTu2S3NpA7tb; Tue, 11 Feb 2014 01:10:07 +0000 Message-ID: <52F9786F.60809@alum.mit.edu> Date: Mon, 10 Feb 2014 20:10:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se> <4616BFFA-F461-4CE8-9D85-211B86D4BE93@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166D7B@ESESSMB209.ericsson.se> <71288EED-3C82-44A7-950B-EFEFA62616E6@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166F8C@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D167A2E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D167A2E@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=q20121106; t=1392081007; bh=E9Id14Mq54mRMN9nMQ4abpC152U4H/Cl3aJ1qCeUbIo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nxJWiUzlEdvdTfa/fSRPeR/w0PbjlaDlSLXuVQ6/camBi9s7m0qIJES1CqinFJbRO l/I2QjYSTfqkRXfztSkl8q+mjZ4xqOnzprShqhJ7KWur7lj6OSM6s44r+u08YMUpMg NBpEzYrl3sqC+211AiTixtkpj255htugwQqdGgALKBIm3VCoF2yrr68HgMzwvHHard IaSpCtyAPUZA6OBCtlOKEHMuKorZ2z/fXBmYA/QjcKJ1QKxY6hYBPECo4oVZYuYRjb 8Dh3tLoxQzPH3GNllI/40xf4154870U99yXt3t0eomVyOmP0ksa5uEtfGZEmM6zy0t 1tN0GZICWz01A== Subject: Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 01:10:10 -0000 You two guys are talking past one another. Christer's point is that the *application" distributed between the two endpoints, needs a *single* instance of a channel for a particular application specific purpose. But the two ends are generally symmetric. There is no obvious choice of which side should create the channel. So how do we use the mechanism to achieve this result? I think I can predict what Michael is going to say: it isn't a protocol issue - the two ends should negotiate this some other way. (In the normal rtcweb scenario, a *single* app in the middle can arrange for one side to do the open.) This is a problem with a sip app - there is no middle, just two ends. Previously Christer said: > Couldn’t we e.g. say that, by default, the DTLS client is responsible for sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it could even use both an even or odd stream id value. That is a bad thing for data channel in general. But I suppose the app can choose to follow this rule if it wants for particular channels. Thanks, Paul On 2/10/14 12:29 PM, Christer Holmberg wrote: > > Hi, > >>>>>>> As is defined in the data channel protocol, an entity can send data once DATA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK is received. >>>>>>> >>>>>>> The draft also says that, if both endpoints send DATA_CHANNEL_OPEN at the same time, using different stream id values, the result may be TWO data channels, with data sent on both. >>>>>>> >>>>>>> However, as is also indicated, the draft does not provide a mechanism to prevent/handle such glare situation. >>>>>>> >>>>>>> I personally think there shall be a way to prevent such situation, or otherwise I'm sure we are going to end up with interoperability problems. >>>>>>> >>>>>>> Couldn't we e.g. say that, by default, the DTLS client is responsible for sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it could even use both an even or odd stream id value. >>>>>> Section 4 reads: >>>>>> >>>>>> To avoid glare in opening Channels, each side MUST use either even >>>>>> or odd Streams when sending a DATA_CHANNEL_OPEN message. The method >>>>>> used to determine which side uses odd or even is based on the >>>>>> underlying DTLS connection role when used in WebRTC, with the side >>>>>> acting as the DTLS client using even stream identifiers. >>>>>> >>>>>> So there is no problem in setting up data channels. >>>>>> >>>>>> This should not be confused by both sides setting up a data channel with the same Label. This ends up in two data channels with the same label. >>>>>> You can even create more data channels with the same label. >>>>> >>>>> My point is that I don't want to end up with more than one channel. >>>> And you won't, see above. >>> >>> I am not sure I understand. What text do you refer to? >> To avoid glare in opening Channels, each side MUST use either even >> or odd Streams when sending a DATA_CHANNEL_OPEN message. The method >> used to determine which side uses odd or even is based on the >> underlying DTLS connection role when used in WebRTC, with the side >> acting as the DTLS client using even stream identifiers. > > That part I understand. > > But, this means that both endpoints may send DATA_CHANNEL_OPEN, for the same protocol, and THAT is what I would like to avoid. I don't want to have two bi-directional data channels for the same thing. > > For that reason I suggested that we could also specify which endpoint is responsisble for sending DATA_CHANNEL_OPEN. > > >>>> However, there is no mechanism to ensure uniqueness for labels. The WebRTC API already allows one side to create n data channels with the same label. >>> >>> I am not saying it should be forbidden to do so. But, for protocol X, I want to end up with ONE data channel between my peers. >>> Then only one side should create a data channel. >>> >>> If I end up with two data channels for protocol X, can I send data on whichever I want to? >> Sure. These would be two independent bidirectional data channels. > > Possible for the same protocol - and that is what I would want to avoid. I want to send my protocol X messages on one data channel, and I would like to receive the protocol X messages from my peer on the same data channel. > > Now, one can of course solve this by reseting one of the data channels, but then the question is which endpoint should reset :) > > Regards, > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From christer.holmberg@ericsson.com Mon Feb 10 23:56: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 1430C1A08E9 for ; Mon, 10 Feb 2014 23:56:04 -0800 (PST) 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_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 Unwad_g33hIg for ; Mon, 10 Feb 2014 23:56:02 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 029251A07B0 for ; Mon, 10 Feb 2014 23:56:01 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-4f-52f9d7901d64 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 90.30.04249.097D9F25; Tue, 11 Feb 2014 08:56:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 08:56:00 +0100 From: Christer Holmberg To: Eric Rescorla Thread-Topic: [rtcweb] How to determine TLS roles? Thread-Index: Ac8mZBiXQux1+cpSRGeFwm+/NhCfyP//88iA///u0BCAABk5gP//7dswgAAbnoCAAC3h+IAANO4A///uyOAABTaPAP//S8SA Date: Tue, 11 Feb 2014 07:56:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D169003@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167F68@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+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje7E6z+DDM7vYLdY8focu8Xaf+3s Fhe332J0YPZYsuQnk8eSSY1sHpMftzEHMEdx2aSk5mSWpRbp2yVwZRyed5Cp4CtrxYLLNxkb GE+zdDFyckgImEgsvtPOCGGLSVy4t56ti5GLQ0jgCKNE76pDjBDOYkaJKRtAMhwcbAIWEt3/ tEEaRAQUJH79OQE2iFnAW+LflBtsILawgKHE0sdzmSBqjCRmL+1kg7DzJGb33mUGsVkEVCWm TzwEVsMr4Cuxb/8DVohdK1glrh7ewwSyi1MgUOLMfB2QGkag476fWsMEsUtc4taT+UwQRwtI LNlznhnCFpV4+fgfK4StKNH+tIERol5HYsHuT2wQtrbEsoWvmSH2CkqcnPmEZQKj2CwkY2ch aZmFpGUWkpYFjCyrGDmKU4uTctONDDYxAiPn4JbfFjsYL/+1OcQozcGiJM778a1zkJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbGB2apGfc5P16eaHux5vx7yyMTOL5aqb4z4Lwa+eDwvGcu bkkPDKoPe/Ss9RdKkVxmKjq9WUHl79wWkfb+ko+X2rey3O8MyznMXrnr/dvIcPWrT7Zp88o/ 2bA+KvOtlNG8L5I3DYJPTlrELBlS8sviUI9c5sugyMc1jz90T561MURRfKrvzjcnlFiKMxIN tZiLihMBjuZxNmoCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 07:56:04 -0000 Hi, >>>> Q2: If SDP O/A is not used on the wire, there needs to be another mech= anism for the peers to negotiate/indicate who is "active" and who is "passi= ve"? >>> >>> I don't see how this is our problem. >>Ok, let me rephrase: we use SDP O/A in the API between the JS App and the= browser, and the RFCs you pointed to above say that the SDP setup attribut= e is used to negotiate the roles. >> >>So, can the JS App, using the setup attribute, control the DTLS role in t= he browser > > That ties into the general question of which a-lines can be modified in > the JS app. It's no more decided than those questions. So, if I understand correctly, currently the JS App CANNOT control the brow= ser DTLS role? Regards, Christer From ekr@rtfm.com Tue Feb 11 00:02: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 52A1A1A08EE for ; Tue, 11 Feb 2014 00:02:45 -0800 (PST) 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 8wvwqlarFYaY for ; Tue, 11 Feb 2014 00:02:42 -0800 (PST) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7DD1A08EF for ; Tue, 11 Feb 2014 00:02:40 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id jy13so5783391veb.41 for ; Tue, 11 Feb 2014 00:02:40 -0800 (PST) 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=Nv+MP1KlwUPIqgveg5/uxrvqlmXISYdEx7qHG+HgVsA=; b=FZo703UaLZ6hgf9woA9Px8dz8dNCMwOI4GVsSaFsyvGJOvACumv5T79gC3CRGF98fv OqAzmmCux+deZZUUf0E1dlQ5gkgekRlZsRerMly5U2EYz85v5Dy5MywiK1pdm1WNNqpU O9oZNR1WXq/eHzle3nOSoPwj/3sL035otJKhep/GDsd/iau+fq3VBmZOblQO7nnZNNTZ LkYFOM+TpnoIB1BLlSonONR4Jw8Kqj5/P7A7ozzz+TyzKmesZoNNRbUrudOSmpi2NVtS rskpbILhiJSf7c/e3ezougFByvkgVjdliPprSaiLyH+9HwecvngX25pnk7T3Y88k6Zc7 0JXQ== X-Gm-Message-State: ALoCoQnNj6xNFwi3ZgDFI2H/YVli60Z+zoA8l6PfG30ihCvG27QpMoR+z07C/h2w05lDMD4JglFm X-Received: by 10.52.170.241 with SMTP id ap17mr22840518vdc.13.1392105760051; Tue, 11 Feb 2014 00:02:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.106.162 with HTTP; Tue, 11 Feb 2014 00:01:59 -0800 (PST) X-Originating-IP: [74.95.2.168] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D169003@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167F68@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D169003@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Tue, 11 Feb 2014 00:01:59 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b33d050516a7304f21ce1a1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 08:02:45 -0000 --047d7b33d050516a7304f21ce1a1 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 10, 2014 at 11:56 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>>> Q2: If SDP O/A is not used on the wire, there needs to be another > mechanism for the peers to negotiate/indicate who is "active" and who is > "passive"? > >>> > >>> I don't see how this is our problem. > >>Ok, let me rephrase: we use SDP O/A in the API between the JS App and > the browser, and the RFCs you pointed to above say that the SDP setup > attribute is used to negotiate the roles. > >> > >>So, can the JS App, using the setup attribute, control the DTLS role in > the browser > > > > That ties into the general question of which a-lines can be modified in > > the JS app. It's no more decided than those questions. > > So, if I understand correctly, currently the JS App CANNOT control the > browser DTLS role? > Well, that may turn out to be the case, but it's not what I said. JSEP Section 6 contains a list of which SDP parameters can be manipulated by the JS, however, it's clearly unfinished. http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-05#section-6 Thus, it seems to me to be an open question whether the JS can manipulate this field. -Ekr --047d7b33d050516a7304f21ce1a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 10, 2014 at 11:56 PM, Christer Holmberg <= christer.holmberg@ericsson.com> wrote:
Hi,

>>>> Q2: If SDP O/A is not used on the wire, there needs to be = another mechanism for the peers to negotiate/indicate who is "active&q= uot; and who is "passive"?
>>>
>>> I don't see how this is our problem.
>>Ok, let me rephrase: we use SDP O/A in the API between the JS App a= nd the browser, and the RFCs you pointed to above say that the SDP setup at= tribute is used to negotiate the roles.
>>
>>So, can the JS App, using the setup attribute, control the DTLS rol= e in the browser
>
> That ties into the general question of which a-lines can be modified i= n
> the JS app. It's no more decided than those questions.

So, if I understand correctly, currently the JS App CANNOT control th= e browser DTLS role?

Well, that may tur= n out to be the case, but it's not what I said.

JSEP Section 6 contains a list of which SDP parameters can
b= e manipulated by the JS, however, it's clearly unfinished.

Thus, it seems to me to be an open question wheth= er the JS
can manipulate this field.

-Ek= r

--047d7b33d050516a7304f21ce1a1-- From tim@phonefromhere.com Tue Feb 11 02:08: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 404671A092A for ; Tue, 11 Feb 2014 02:08:10 -0800 (PST) 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_56=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 CG3HI6aipCwd for ; Tue, 11 Feb 2014 02:08:07 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB8D1A07E0 for ; Tue, 11 Feb 2014 02:08:06 -0800 (PST) Received: (qmail 68853 invoked from network); 11 Feb 2014 10:08:05 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 3013 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 11 Feb 2014 10:08:05 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 4FCFE18A0555; Tue, 11 Feb 2014 10:08:05 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id F052718A01D1; Tue, 11 Feb 2014 10:08:04 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F9F913AA-78E7-4BA2-9C1E-543A1977AB7D" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton In-Reply-To: Date: Tue, 11 Feb 2014 10:08:03 +0000 Message-Id: <062345FE-A68C-4380-A0DB-ED6F3D20C2FB@phonefromhere.com> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167F68@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D169003@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1827) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 10:08:10 -0000 --Apple-Mail=_F9F913AA-78E7-4BA2-9C1E-543A1977AB7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 11 Feb 2014, at 08:01, Eric Rescorla wrote: >=20 >=20 >=20 > On Mon, Feb 10, 2014 at 11:56 PM, Christer Holmberg = wrote: > Hi, >=20 > >>>> Q2: If SDP O/A is not used on the wire, there needs to be another = mechanism for the peers to negotiate/indicate who is "active" and who is = "passive"? > >>> > >>> I don't see how this is our problem. > >>Ok, let me rephrase: we use SDP O/A in the API between the JS App = and the browser, and the RFCs you pointed to above say that the SDP = setup attribute is used to negotiate the roles. > >> > >>So, can the JS App, using the setup attribute, control the DTLS role = in the browser > > > > That ties into the general question of which a-lines can be modified = in > > the JS app. It's no more decided than those questions. >=20 > So, if I understand correctly, currently the JS App CANNOT control the = browser DTLS role? >=20 > Well, that may turn out to be the case, but it's not what I said. >=20 > JSEP Section 6 contains a list of which SDP parameters can > be manipulated by the JS, however, it's clearly unfinished. >=20 > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-05#section-6 >=20 > Thus, it seems to me to be an open question whether the JS > can manipulate this field. But be aware those rules apply to manipulation that happens between=20 createOffer and setLocalDescription In concrete terms this means that a browser might create an offer (with = setup:actpass) set it unaltered as the local description, then send it to a peer. The peer might reply with an answer with setup:active This signals that the remote peer wants to be the DTLS client - and the = offer said that the local browser was ok with that. So this example allows the normal roles to be reversed, the = non-initiator would be the DTLS client. However, in a browser-to-browser call this may not be possible, because = the JS at the far end may not be allowed (see above) to change the setup: field between createAnswer() = and setting it locally. A gateway might not feel bound by such rules (code permitting). Tim. >=20 > -Ekr >=20 --Apple-Mail=_F9F913AA-78E7-4BA2-9C1E-543A1977AB7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 11 Feb 2014, at 08:01, Eric = Rescorla <ekr@rtfm.com> = wrote:




On Mon, Feb 10, 2014 at 11:56 PM, Christer = Holmberg <christer.holmberg@ericsson.com> = wrote:
Hi,

>>>> Q2: If SDP O/A is not used on the wire, there needs to = be another mechanism for the peers to negotiate/indicate who is "active" = and who is "passive"?
>>>
>>> I don't see how this is our problem.
>>Ok, let me rephrase: we use SDP O/A in the API between the JS = App and the browser, and the RFCs you pointed to above say that the SDP = setup attribute is used to negotiate the roles.
>>
>>So, can the JS App, using the setup attribute, control the DTLS = role in the browser
>
> That ties into the general question of which a-lines can be = modified in
> the JS app. It's no more decided than those questions.

So, if I understand correctly, currently the JS App CANNOT control = the browser DTLS role?

Well, that = may turn out to be the case, but it's not what I = said.

JSEP Section 6 contains a list of which SDP parameters = can
be manipulated by the JS, however, it's clearly = unfinished.


Thus, it seems to me to be an open question = whether the JS
can manipulate this = field.

But be = aware those rules apply to manipulation that happens = between 
createOffer and = setLocalDescription

In concrete terms this = means that a browser might create an offer (with = setup:actpass)
set it unaltered as the local description, then = send it to a peer.
The peer might reply with an answer with = setup:active

This signals that the remote peer = wants to be the DTLS client - and the offer said that the local browser = was ok with that.
So this example allows the normal roles to = be reversed, the non-initiator would be the DTLS = client.

However, in a browser-to-browser call = this may not be possible, because the JS at the far end may not = be
allowed (see above) to change the setup: field between = createAnswer() and setting it locally.

A = gateway might not feel bound by such rules (code = permitting).

Tim.


-Ekr

<= /div>

= --Apple-Mail=_F9F913AA-78E7-4BA2-9C1E-543A1977AB7D-- From stefan.lk.hakansson@ericsson.com Tue Feb 11 02:15: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 07FF11A0724 for ; Tue, 11 Feb 2014 02:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 lZHfgt8rL6vK for ; Tue, 11 Feb 2014 02:15:44 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2F71A07D6 for ; Tue, 11 Feb 2014 02:15:42 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-4f-52f9f84c97fe Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E2.DF.23809.C48F9F25; Tue, 11 Feb 2014 11:15:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 11:15:40 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Magnus Westerlund , Parthasarathi R , "rtcweb@ietf.org" Thread-Topic: [rtcweb] New version of use-case draft uploaded Thread-Index: Ac8jKZAtHwyyT87MQ3ivvr7TXBW1mA== Date: Tue, 11 Feb 2014 10:15:39 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CF54AD5@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1CF4A182@ESESSMB209.ericsson.se> <007601cf2423$2d571210$88053630$@co.in> <1447FA0C20ED5147A1AA0EF02890A64B1CF533B8@ESESSMB209.ericsson.se> <004601cf24ad$f3a1c0c0$dae54240$@co.in> <52F8B1AB.70305@ericsson.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvja7Pj59BBo2f9Cwmf+pjtVj7r53d gcljyZKfTB4f5n9hD2CK4rJJSc3JLEst0rdL4Mo4uGQaS0Ejd0XTZZ4Gxo8cXYycHBICJhIz jrezQ9hiEhfurWfrYuTiEBI4xChxbOl1NpCEkMBiRolLMxJAbDaBQImt+xaAFYkIdDNKHN00 iwUkISxgI/HvwimwSSICthL/Zv5jhLD1JO6t3MzcxcjBwSKgKrHhbglImFfAV+LhhOXMEMua mSQOz3wLtowR6Irvp9YwgdjMAuISt57MZ4K4TkBiyZ7zzBC2qMTLx/9YQWZKCChKLO+XgyjX k7gxdQobhK0tsWzha2aIXYISJ2c+YZnAKDILydRZSFpmIWmZhaRlASPLKkb23MTMnPRyo02M wIA/uOW36g7GO+dEDjFKc7AoifN+eOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRaH1F 2rRjd74sruK0/n8u30Pi2D7+tZNWndaOyS0VMd7b8DAqoOLANJ0I4anVbgumxPz8eiEo890f ff6r5h9Nl2ywUjK4ta1gupWM2W735Vfkp350yWMNLf+ue4TxUg9D4Zd81728P5wLNp6cFjll ou7i6OWlevNMNTVlw04Lqhjvzt0bIGSlxFKckWioxVxUnAgAK+kV50YCAAA= Subject: Re: [rtcweb] New version of use-case draft uploaded X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 10:15:46 -0000 On 2014-02-10 12:02, Magnus Westerlund wrote:=0A= > Hi Partha,=0A= >=0A= > See inline=0A= >=0A= > On 2014-02-08 10:12, Parthasarathi R wrote:=0A= >> Hi Stefan,=0A= >>=0A= >> =0A= >>> Yes, I did that change (TURN -> ICE). My understanding was that ICE is= =0A= >>> what is used/mandated (and it in turn makes use of STUN and TURN).=0A= >>>=0A= >> =0A= >>=0A= >> ICE is mandated in RTCWeb but I disagree to your assumption that ICE in = turn=0A= >> makes use of TURN. My concern is that The requirement document is mislea= ding=0A= >> about TURN requirements. ICE-TCP avoids TURN server as the middle-box in= the=0A= >> network. ICE-TCP is host candidate whereas TURN is relay candidate and a= s=0A= >> per ICE candidate selection, host candidate is preferred over relay=0A= >> candidates.=0A= >=0A= > I will agree that the note as currently worded is not completely=0A= > accurate and clear. Based on the text in the preceding section, it makes= =0A= > sense to note that ICE using STUN and TURN is not the only solution=0A= > including additional ICE modes or relay services. I request the authors= =0A= > propose a new formulation of the note.=0A= =0A= Proposal:=0A= =0A= "Note that ICE support being mandatory does not preclude a WebRTC =0A= endpoint from supporting more traversal mechanisms than ICE using STUN =0A= and TURN."=0A= =0A= OK?=0A= =0A= From tim@phonefromhere.com Tue Feb 11 02:19: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 2B6731A0935 for ; Tue, 11 Feb 2014 02:19:29 -0800 (PST) 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 aCgOcefCcI6O for ; Tue, 11 Feb 2014 02:19:27 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by ietfa.amsl.com (Postfix) with ESMTP id 98BF71A07D6 for ; Tue, 11 Feb 2014 02:19:26 -0800 (PST) Received: (qmail 81609 invoked from network); 11 Feb 2014 10:19:25 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 3322 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 11 Feb 2014 10:19:25 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id BAB2C18A0596; Tue, 11 Feb 2014 10:19:25 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7169E18A0407; Tue, 11 Feb 2014 10:19:25 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D167EAC@ESESSMB209.ericsson.se> Date: Tue, 11 Feb 2014 10:19:24 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> <8991EDBE-71F3-4456-A614-A9F4926F4955@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167CF8@ESESSMB209.ericsson.se> <1FC0C1C7-E5AB-4D4C-ABCC-8371457DCBF0@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167EAC@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1827) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 10:19:29 -0000 On 10 Feb 2014, at 20:30, Christer Holmberg = wrote: > Hi, >=20 >>>>>> This is defined in RFC 5763 S 5: >>>>>> http://tools.ietf.org/html/rfc5763#section-5 >>>>>>=20 >>>>>> Which points to: >>>>>> http://tools.ietf.org/html/rfc4145 >>>>>=20 >>>>> Ok. So, a few questions to for clarification: >>>>>=20 >>>>> Q1: This means that the JS App must set the setup attrbute value = before passing an SDP to the browser? >>>> No, peer-to-peer browser calls should 'do the right thing' - based = on the initator/ice-controlling rule Both browsers set a=3Dsetup:act-pass = meaning that we fall back to the old rules. >>>=20 >>> What "old rules"? :) >>>=20 >>=20 >> Sorry that was unclear - As I read it, putting a=3Dsetup:actpass in = the SDP indicates that the ice-controlling entity should act as DTLS = client, and typically the ice-controlling entity is the initiator of the = session. So it isn't a matter of O/A negotiation. >=20 > Do you have a reference to where you read that? No, I don't think I have seen it explicitly stated. >=20 >>>> If however you have a gateway initating a call to a browser, and it=20= >>>> wants to do early media (it's an 800 number gateway for example) = then it sets a=3Dsetup:active in the SDP it sends (or you create on it's = behalf). >>>=20 >>> There doesn't necessarily have to be a gateway. It may be a = browser-to-browser call, using SIP and SDP O/A on the wire - meaning = that the SDP setup attribute is used to determine the roles. >>=20 >> But there is no concept of early media on a peer-to-peer webRTC call, = so there isn't any need to manage which side is the DTLS client or = server. >=20 > Not sure what this has to do with early media. You can have two = browser based applications, using SDP O/A to negotiate the DTLS roles. You only care about manipulating the DTLS roles if you want the side = that _didn't_ initiate the call to initiate the media flow. The only = instance where that happens is early media.=20 Without early media there is no need to manipulate which end is = client/server since the default or initiator is client makes sense - or = am I missing something? >=20 > Regards, >=20 > Christer From christer.holmberg@ericsson.com Tue Feb 11 02:49: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 CBA3A1A0959 for ; Tue, 11 Feb 2014 02:49:47 -0800 (PST) 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_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 hT4zEMJuxyI8 for ; Tue, 11 Feb 2014 02:49:46 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id C2D4F1A07E1 for ; Tue, 11 Feb 2014 02:49:45 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-fd-52fa0048f681 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 1F.30.04249.8400AF25; Tue, 11 Feb 2014 11:49:44 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 11:49:44 +0100 From: Christer Holmberg To: Tim Panton Thread-Topic: [rtcweb] How to determine TLS roles? Thread-Index: Ac8mZBiXQux1+cpSRGeFwm+/NhCfyP//88iA///u0BCAABk5gP//7dswgAAbnoCAAC3h+IAAAg0A///I9eAADI1GgP//7kBQ//8EUwD//fBFYA== Date: Tue, 11 Feb 2014 10:49:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1695A8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> <8991EDBE-71F3-4456-A614-A9F4926F4955@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167CF8@ESESSMB209.ericsson.se> <1FC0C1C7-E5AB-4D4C-ABCC-8371457DCBF0@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167EAC@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+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvja4Hw68ggz09FhYrXp9jt1j7r53d 4uL2W4wOzB5Llvxk8lgyqZHNY/LjNuYA5igum5TUnMyy1CJ9uwSujNarrxgLrnBVrJvcxdTA uJGji5GTQ0LAROLa+n3sELaYxIV769m6GLk4hASOMEo8/XCVEcJZzCjR/ek4UxcjBwebgIVE 9z9tkAYRATWJcz8OM4PYzAKuEudmTmECsYUFDCWWPp7LBFFjJDF7aScbhF0nseH3SxYQm0VA VeL/5B4WkJG8Ar4S5//wg4SFBHrZJNZ9DwUJcwKNfLSdFSTMCHTa91NrmCA2iUvcejKfCeJk AYkle84zQ9iiEi8f/2OFsBUl2p82MELU60gs2P2JDcLWlli28DVYPa+AoMTJmU9YJjCKzUIy dhaSlllIWmYhaVnAyLKKkaM4tTgpN93IYBMjMGoObvltsYPx8l+bQ4zSHCxK4rwf3zoHCQmk J5akZqemFqQWxReV5qQWH2Jk4uCUamBcdeJKc8iEdFbb93uY1P40xv20vn1ujnphrqOvhw/3 wilzZ/gxJWwy3HzCwvDTKiMpka51rUXbz+0Tvvxi0WzNPx4VTJzG6/P4+16vyuPc4jBb9Er9 zviE/VpT17mIVkvN//Ip8cczznelP3nFGaSaLl9TaW2vmHB+xQ27sDMm/oJvv2fJrOVVYinO SDTUYi4qTgQAmzuogGgCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 10:49:48 -0000 Hi, >>>>> If however you have a gateway initating a call to a browser, and it=20 >>>>> wants to do early media (it's an 800 number gateway for example) then= it sets a=3Dsetup:active in the SDP it sends (or you create on it's behalf= ). >>>>=20 >>>> There doesn't necessarily have to be a gateway. It may be a browser-to= -browser call, using SIP and SDP O/A on the wire - meaning that the SDP set= up attribute is used to determine the roles. >>>=20 >>> But there is no concept of early media on a peer-to-peer webRTC call, s= o there isn't any need to manage which side is the DTLS client or server. >>=20 >> Not sure what this has to do with early media. You can have two browser = based applications, using SDP O/A to negotiate the DTLS roles. > > You only care about manipulating the DTLS roles if you want the side that= _didn't_ initiate the call to initiate the media flow. The only instance w= here that happens is early media.=20 > Without early media there is no need to manipulate which end is client/se= rver since the default or initiator is client makes sense - or am I missing= something? I don't really have a need to "manipulate" the roles. I just want my JS App= to know what role its browser will take, so it can inform its peer (using = whatever signaling protocol) about the role. Regards, Christer From magnus.westerlund@ericsson.com Tue Feb 11 04:47: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 A53E91A0033 for ; Tue, 11 Feb 2014 04:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 V-hbWD-CnnTn for ; Tue, 11 Feb 2014 04:47:26 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3B41A0008 for ; Tue, 11 Feb 2014 04:47:25 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-88-52fa1bdc387c Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 08.72.04853.CDB1AF25; Tue, 11 Feb 2014 13:47:24 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.2.347.0; Tue, 11 Feb 2014 13:47:23 +0100 Message-ID: <52FA1BDB.5010709@ericsson.com> Date: Tue, 11 Feb 2014 13:47:23 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Parthasarathi R , =?ISO-8859-1?Q?=27Stefa?= =?ISO-8859-1?Q?n_H=E5kansson_LK=27?= , References: <1447FA0C20ED5147A1AA0EF02890A64B1CF4A182@ESESSMB209.ericsson.se> <007601cf2423$2d571210$88053630$@co.in> <1447FA0C20ED5147A1AA0EF02890A64B1CF533B8@ESESSMB209.ericsson.se> <004601cf24ad$f3a1c0c0$dae54240$@co.in> <52F8B1AB.70305@ericsson.com> <013901cf2693$97c1eb30$c745c190$@co.in> In-Reply-To: <013901cf2693$97c1eb30$c745c190$@co.in> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvje4d6V9BBtuOSFhM/tTHarH2Xzu7 A5PHkiU/mTw+zP/CHsAUxWWTkpqTWZZapG+XwJWx+OgdloL3fBWLt81mbWDs5uli5OSQEDCR 2P3tChOELSZx4d56ti5GLg4hgROMEv8+X2eGcJYzSiycdZoVpIpXQFvi5srzYB0sAqoSE690 sYDYbAIWEjd/NLKB2KICwRI7D/xmhKgXlDg58wkLyCARgVWMEpf3bwcrEhawkfh34RQ7xIal TBL9fxeCTeIEuun05p1A3RxAN4lL9DQGgYSZBfQkplxtYYSw5SWat85mBrGFgA5qaOpgncAo OAvJvllIWmYhaVnAyLyKUbI4tbg4N93IQC83PbdEL7UoM7m4OD9Przh1EyMwdA9u+W20g/Hk HvtDjNIcLErivNdZa4KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MHq3d93QVrnRdLlG9orX 7clCndJrfwtZSRq+nya7gGudgcb2t/kdP0/7Le9e0nlg2yXeL/NYWZNUd80VzTRTcfKSjQ0y +yA8Y9H+9+LTtVec2fWcQ5VzzcXHBd3c5Trt1fdkGVZfmh+3rkHxdnh1x7Qoo6C/u1XeFTat a3Rg3BmepudY8ehsqBJLcUaioRZzUXEiALbX/IQrAgAA Subject: Re: [rtcweb] New version of use-case draft uploaded X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 12:47:27 -0000 On 2014-02-10 20:09, Parthasarathi R wrote: > Hi Magnus, > > Thanks for proposing a new formulation of the note by the authors. I agree > with you that F2 and F29 are generic WebRTC NAT/Firewall requirements which > does not restrict ICE-TCP as one of the solution. > > The confusion with F31 and F32 requirements is because of the missing of > WebRTC server/gateway requirements. F31 and F32 leads to the assumption of > mandating TURN servers in the WebRTC server/gateway (by some of the WebRTC > gateway Providers) as there is no text in this usecase & requirement > document to clarify. Sorry, I fail to understand which of multiple possible angles you are arguing here. A) That the use case document is missing a whole requirement related to WebRTC Servers. WebRTC server, is something I am uncertain to what you refer to, a Web server or a media plan related server dealing with peer connections? B) That F31 and F32 would lead to an assumption of mandating something, which currently is the only solution described? C) That there needs to be text describing some aspect of the global presence? I have already wrote in the separate mail thread > (http://www.ietf.org/mail-archive/web/rtcweb/current/msg11338.html) to > provide WebRTC server/gateway guidelines document for more clarity. Good, can you leave with the text and Stefan's text proposal for the note? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Tue Feb 11 05:47: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 59C881A031A; Tue, 11 Feb 2014 05:47:17 -0800 (PST) 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 qFPfnBZygbXY; Tue, 11 Feb 2014 05:47:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F221A0302; Tue, 11 Feb 2014 05:47:15 -0800 (PST) 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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140211134715.20073.62978.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2014 05:47:15 -0800 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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: Tue, 11 Feb 2014 13:47: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 : WebRTC Data Channels Authors : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-channel-07.txt Pages : 15 Date : 2014-02-11 Abstract: The Real-Time Communication in WEB-browsers working group is charged to provide 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-channel-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 internet-drafts@ietf.org Tue Feb 11 05:52: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 DBC531A0302; Tue, 11 Feb 2014 05:52:24 -0800 (PST) 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 sBArTiLpG4dI; Tue, 11 Feb 2014 05:52:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E4C1A01F5; Tue, 11 Feb 2014 05:52:22 -0800 (PST) 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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140211135222.19772.47913.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2014 05:52:22 -0800 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-03.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, 11 Feb 2014 13:52:25 -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 Data Channel Establishment Protocol Authors : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-protocol-03.txt Pages : 12 Date : 2014-02-11 Abstract: The Web Real-Time Communication (WebRTC) working group is charged to provide protocols to 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-protocol-03 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 tuexen@fh-muenster.de Tue Feb 11 05:48: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 2942F1A031A for ; Tue, 11 Feb 2014 05:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 bRMcLefx7Xkd for ; Tue, 11 Feb 2014 05:47:59 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 853061A01F5 for ; Tue, 11 Feb 2014 05:47:58 -0800 (PST) Received: from [192.168.1.103] (p508F3BD7.dip0.t-ipconnect.de [80.143.59.215]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C9C781C0E975E; Tue, 11 Feb 2014 14:47:55 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <5280E181.20104@ericsson.com> Date: Tue, 11 Feb 2014 14:47:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9A62A3AC-F990-4358-B2E7-B8DD39A81B03@fh-muenster.de> References: <5280E181.20104@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Tue, 11 Feb 2014 06:09:58 -0800 Cc: "rtcweb@ietf.org" , draft-ietf-rtcweb-data-channel@tools.ietf.org Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 13:48:03 -0000 On Nov 11, 2013, at 2:54 PM, Magnus Westerlund = wrote: > Hi, >=20 > I did review the data channel draft prior to the meeting and thought I > would provide my comments. >=20 > 1. Usage of RTCWeb vs WebRTC when referring to the whole solution. My > recollection was that we agreed to use WebRTC for this. I think we > should try to align this language. Audio, Security and RTP usage uses > WebRTC, while Data channel, overview and Transport uses RTCWeb. OK. Changed to WebRTC. Although the WG uses rtcweb as its acronym... >=20 > 2. Section 3.2: > U-C 6: Renegotiation of the set of media streams in the > PeerConnection. >=20 > What "media streams" are being referred to here. Or is i better to > express this as "Renegotiation of the configuration of the = PeerConnection."? I think the media streams of the PeerConnection are considered... However, you might want to reconfigure the PeerConnection. So, yes, your text makes sense. I changed the use case. >=20 > 3. Section 3.2: > U-C 7: Proxy browsing, where a browser uses data channels of a > PeerConnection to send and receive HTTP/HTTPS requests and data, > for example to avoid local internet filtering or monitoring. >=20 > Yes, this may be something that is possible, but to express it as a = use > cases intended to be supported might not be the best. We are after all > likely talking about circumventing local security policies. I would = also > note that "Internet" is with capital I. Change to Internet. The use case seems important, since there are = already implementations doing this (possibly not using data channels, don't = know). Randell: What do you think? >=20 > 4. Section 4: > Req. 1: Multiple simultaneous data channels MUST be supported. > Note that there may 0 or more media streams in parallel with the > data channels, and the number and state (active/inactive) of the > media streams may change at any time. >=20 > Which "media stream" are you referring to in the above? The PeerConnection can have 0 or more media streams (SRTP on the wire) in addition to data channels. I changed it to: Multiple simultaneous data channels MUST be supported. Note that there may 0 or more media streams in parallel with the data = channels in the same PeerConnection, and the number and state (active/inactive) = of these media streams may change at any time. >=20 > 5. Section 4: > Req. 3: Data channels MUST be congestion controlled; either > individually, as a class, or in conjunction with the media > streams, to ensure that data channels don't cause congestion > problems for the media streams, and that the RTCWeb = PeerConnection > as a whole is fair with competing traffic such as TCP. >=20 > A: What "media stream" are you referring to here? The media streams of the PeerConnection... >=20 > B: "and that the RTCWeb PeerConnection > as a whole is fair with competing traffic such as TCP." >=20 > I don't think it is a MUST requirement. Neither am I convinced that a > PeerConnection needs to be fair with an unspecified number of TCP > traffic. It might be simplest to strike the last part. But if you remove the last part the CC of the data channel only needs to ensure that it doesn't case congestion problems for the media = channels. So if there are no media streams, the CC of the data channels could be much more aggressive than TCP. I don't think this is what we want. So I keep that for now. But I'm open for discussion. Changed to: Data channels of a PeerConnection MUST be congestion controlled; either individually, as a class, or in conjunction with the media = streams of the PeerConnection, to ensure that data channels don't cause = congestion problems for these media streams, and that the WebRTC PeerConnection as a whole is fair with competing traffic such as TCP. >=20 > 6. Section 4: > [ TBD: how this is encoded and what the impact of this is. ] >=20 > Didn't we have some direction decisions on how priority was to be > handled at least locally by the end-point. Please add this to the = draft. I think we decided to have priorities for data channels, which are not = strict priorities. That is all. The W3C document doesn't mention it. > I also hope that the way of representing priorities can get clearer = from > an API perspective. I agree. However, I'm not a member of W3C... >=20 > 7. Section 5: > " o The congestion control is modifiable for integration with media > stream congestion control." >=20 > I think this is an exaggeration, and not supported by current sets of > specifications, if it is supported please provide a reference. I think you can specify an alternate CC for SCTP. This is not done right now, but it is doable. Therefore, I don't think it is a = exaggeration, it is just not done yet... If you have a suggestion for an better = wording, I'm open for suggestions. >=20 > 8. Section 5: > "Using DTLS over UDP in combination with ICE enables NAT traversal in > IPv4 based networks." >=20 > I would like to point out that ICE do provide firewall traversal for > firewalls with certain type of filtering rules like the basic stateful > filtering. These apply to IPv6 equally, not only IPv4. Correct. I changed the wording to Using DTLS over UDP in combination with ICE enables middlebox traversal in IPv4 and IPv6 based networks. >=20 > 9. Section 5: > " Each SCTP user message contains a so called Payload Protocol > Identifier (PPID) that is passed to SCTP by its upper layer and sent > to its peer. This value can be used to multiplex multiple protocols > over a single SCTP association. The sender provides for each > protocol a specific PPID and the receiver can demultiplex the > messages based on the received PPID." >=20 > I have some difficulties in determining the relevance of this in the > context of WebRTC. Can you please provide a clear explanation why PPID > are relevant here. Will not all traffic from an WebRTC endpoint use = the > PPIDs associated with the data protocol, rather than any "native" = PPIDs? We use one PPID for the Data Channel Establishment Protocol, one for UTF-8 encoded user data and one for binary encoded user data. So we use it... I added at the end of the paragraph: The PPID is used to distinguish UTF-8 encoded user data and binary = encoded userdata. The Data Channel Establishment Protocol defined in uses also a specific = PPID to be distinguished from user data. >=20 > 10. Section 5: >=20 > Can you please clarifiy the demultiplexing for WebRTC by discussing > STUN, vs SRTP vs DTLS and secondly that DTLS-SRTP and DTLS frames with > SCTP can co-exist in the same DTLS stack. At least on an level where = you > can point to all the relevant sections in other specifications to > explain that these can coexist given certain constraints. This is = likely > its own sub-section. Not sure...=20 The demultiplexing STUN vs. SRTP vs. DTLS is described in http://tools.ietf.org/html/rfc5764#section-5.1.2 SCTP is the only payload of DTLS. So there is no demultiplexing done. I have added: Please note that the demultiplexing STUN vs. SRTP vs. DTLS is done as described in Section 5.1.2 of and SCTP is the only payload of DTLS. >=20 > 11. Section 5: >=20 > o shares the DTLS connection with the media channels. >=20 > what is "media channels"? ... the media channels of the PeerConnection. >=20 > 12. Section 5: > " Since DTLS is typically implemented in user-land, the SCTP stack = also > needs to be a user-land stack." >=20 > I wonder what the message of this sentence is? The reason is that I That you can't use a kernel SCTP stack, even if available. > wonder what it should be saying if one implements DTLS in a kernel, or I haven't seen this yet. I think you can do the encrypt/decrypt part, but doing the key management stuff in kernel land doesn't seem = appropriate. > similar if one despite a DTLS user-land stack uses a SCTP stack in the > kernel through access to raw sockets. How can the lower layer run in userland when the upper layer runs in kernel land? >=20 > 13. Section 5: > Incoming ICMP or ICMPv6 messages can't be processed by the SCTP > layer, since there is no way to identify the corresponding > association. >=20 > Also here I get a bit confused, I assume what you are after is the = issue > that incoming ICMP messages will be arriving related to the UDP flow, > not in relation to an kernel SCTP association, thus there is a routing > issue for ICMP to reach the above DTLS existing SCTP association. Not > impossible to solve, just not available with existing APIs. No, it is not an API issue. The ICMP message contains the encrypted DTLS packet which contains the SCTP packet. Normally, only part of the = message is returned. I think only 8 bytes of payload is returned. So this is not enough for the DTLS header at all. So you simply might not have enough information. >=20 > 14. Section 5: > "This protocol stack MUST support the usage of multiple SCTP = streams." >=20 > I wonder which layer is affected by this. Isn't this only affecting = SCTP > implementation and the higher layers? Can't you be more specific thus? Yes. Changed to This SCTP stack and its upper layer MUST support the usage of = multiple SCTP streams. >=20 > 15. Section 5: > Using a congestion control > different from the standard one might improve the impact on the > parallel SRTP media streams. Since SCTP does not support the > negotiation of a congestion control algorithm, alternate congestion > controls SHOULD only require a different sender side behavior using > existing information carried in the association. >=20 > A: I wonder if adding a "yet" into the second sentence to make clear > that in the future there might be support for negotiating congestion > control. >=20 > B: Also, what happens if one violate the SHOULD and require receiver > side information and the peer don't support it. That clearly can't be > acceptable? Can this be formulated in some other way that is tighter > without preventing sender side changes? OK. Changed to Since SCTP does not support the negotiation of a congestion control = algorithm yet, alternate congestion controls SHOULD either only require a = different sender side behavior using existing information carried in the = association or need also specify a negotiation of of a congestion control = algorithm. >=20 > 16. Section 6.1: > o The dynamic address reconfiguration extension defined in = [RFC5061] > MUST be used to signal the support of the stream reset extension > defined in [RFC6525], other features of [RFC5061] MUST NOT be > used. >=20 > A question, are theses other features, destructive to the SCTP > association, or simply unnecessary to implement? If it is the first, > then I think MUST NOT be used is fine, but if else, why not simple say > that they are NOT REQUIRED to be implemented? Changed to not REQUIRED, since NOT REQUIRED is not an RFC 2119 term. >=20 >=20 > 17. Section 6.1: > o The partial reliability extension defined in [RFC3758] MUST be > supported. In addition to the timed reliability PR-SCTP policy > defined in [RFC3758], the limited retransmission policy defined = in > [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported. >=20 > So what is the status of this individual document, did it get adopted > into TSVWG? I think this is an important question, as it is one thing > where we can consider going forward without the extension and add it > later when ready? It has been adopted. >=20 > 18. Section 6.2: > " Additionally, > the negotiation SHOULD include some type of congestion control > selection. " >=20 > Okay, this appears very fuzzy. And what name space or specifications = are > you going to use to negotiate what the different options are? Randell? Salvatore? I don't think there is anything specified yet. >=20 > 19. Section 6.3: > It will use the DTLS connection selected via SDP; > typically this will be shared via BUNDLE or equivalent with DTLS > connections used to key the DTLS-SRTP media streams. >=20 > In which way is the DTSL connection "selected" via SDP? I think it should read ICE, not SDP... >=20 > 20. Section 6.2: >=20 > When one side wants to open a channel using external negotiation, it > picks a Stream. This can be based on the DTLS role (the client = picks > even stream identifiers, the server odd stream identifiers) or done > in a different way. However, the application is responsible for > avoiding collisions with existing Streams. If it attempts to re-use > a Stream which is part of an existing Channel, the addition SHOULD > fail. In addition to choosing a Stream, the application SHOULD also > inform the protocol of the options to use for sending messages. The > application MUST ensure in an application-specific manner that the > other side will also inform the protocol that the selected Stream is > to be used, and the parameters for sending data from that side. >=20 > So why is this specified here and not in the Data Protocol? Especially > using RFC 2119 terms, it appears to be colliding or at least = overlapping > specifications? Since the Data Channel Establishment Protocol only covers setting up the data channel via an internal mechanism. The above described the external mechanism. >=20 > 21. Section 6.6 > It is recommended that message size be kept within certain size > bounds (TBD) as applications will not be able to support = arbitrarily- > large single messages. >=20 > I guess this will be resolved by the WG session agreement, or? It will be signalled via SDP... >=20 > 22. >=20 > Section 8: > +---------------------+-----------+-----------+ > | Value | SCTP PPID | Reference | > +---------------------+-----------+-----------+ > | DOMString Last | 51 | [RFCXXXX] | > | Binary Data Partial | 52 | [RFCXXXX] | > | Binary Data Last | 53 | [RFCXXXX] | > | DOMString Partial | 54 | [RFCXXXX] | > +---------------------+-----------+-----------+ >=20 > Where are the definitions of these definitions? In Section 6.6. >=20 > 23. Section 10.2: >=20 > [I-D.tuexen-tsvwg-sctp-prpolicies] > Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, > "Additional Policies for the Partial Delivery Extension = of > the Stream Control Transmission Protocol", draft-tuexen- > tsvwg-sctp-prpolicies-03 (work in progress), October = 2013. >=20 > This is a normative reference. OK. Please note that that ID is targeting for an Informational RFC... Base on the above, I submitted a new revision. Best regards Michael >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 From tim@phonefromhere.com Tue Feb 11 06:54: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 56FAC1A0444 for ; Tue, 11 Feb 2014 06:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=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 IPF7grC8DY-g for ; Tue, 11 Feb 2014 06:54:09 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD9A1A0465 for ; Tue, 11 Feb 2014 06:54:07 -0800 (PST) Received: (qmail 77036 invoked from network); 11 Feb 2014 14:54:05 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 10172 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 11 Feb 2014 14:54:05 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id C227018A0465; Tue, 11 Feb 2014 14:53:57 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7620F18A0407; Tue, 11 Feb 2014 14:53:57 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1695A8@ESESSMB209.ericsson.se> Date: Tue, 11 Feb 2014 14:53:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <03B88F25-D4A7-468F-B9CE-165A1E6E4D10@phonefromhere.com> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> <8991EDBE-71F3-4456-A614-A9F4926F4955@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167CF8@ESESSMB209.ericsson.se> <1FC0C1C7-E5AB-4D4C-ABCC-8371457DCBF0@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167EAC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1695A8@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1827) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 14:54:11 -0000 On 11 Feb 2014, at 10:49, Christer Holmberg = wrote: > Hi, >=20 >>>>>> If however you have a gateway initating a call to a browser, and = it=20 >>>>>> wants to do early media (it's an 800 number gateway for example) = then it sets a=3Dsetup:active in the SDP it sends (or you create on it's = behalf). >>>>>=20 >>>>> There doesn't necessarily have to be a gateway. It may be a = browser-to-browser call, using SIP and SDP O/A on the wire - meaning = that the SDP setup attribute is used to determine the roles. >>>>=20 >>>> But there is no concept of early media on a peer-to-peer webRTC = call, so there isn't any need to manage which side is the DTLS client or = server. >>>=20 >>> Not sure what this has to do with early media. You can have two = browser based applications, using SDP O/A to negotiate the DTLS roles. >>=20 >> You only care about manipulating the DTLS roles if you want the side = that _didn't_ initiate the call to initiate the media flow. The only = instance where that happens is early media.=20 >> Without early media there is no need to manipulate which end is = client/server since the default or initiator is client makes sense - or = am I missing something? >=20 > I don't really have a need to "manipulate" the roles. I just want my = JS App to know what role its browser will take, so it can inform its = peer (using whatever signaling protocol) about the role. well - assuming you leave a=3Dsetup as actpass (the default in the = browser) . If you called createOffer, then you'll be DTLS client.=20 If you called createAnswer you'll be DTLS server. That's assuming no weirdness in the ICE implementation. So your JS can = _deduce_ the role but neither influence it nor _know_ it directly. However, signalling it over your high level signalling protocol is the = wrong way to do it (IMHO). Your peer should deduce the appropriate DTLS = role from the 'signalling'=20 in the ICE packets, by looking at the ICE CONTROLLING flag.=20 >=20 > Regards, >=20 > Christer >=20 >=20 From christer.holmberg@ericsson.com Tue Feb 11 07:04: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 49A181A0545 for ; Tue, 11 Feb 2014 07:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, 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 i1lol3UGbOwh for ; Tue, 11 Feb 2014 07:04:15 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A35E81A050B for ; Tue, 11 Feb 2014 07:04:14 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-e2-52fa3bec2712 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8C.AE.10875.CEB3AF25; Tue, 11 Feb 2014 16:04:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 16:04:12 +0100 From: Christer Holmberg To: Tim Panton Thread-Topic: [rtcweb] How to determine TLS roles? Thread-Index: Ac8mZBiXQux1+cpSRGeFwm+/NhCfyP//88iA///u0BCAABk5gP//7dswgAAbnoCAAC3h+IAAAg0A///I9eAADI1GgP//7kBQ//8EUwD//fBFYP/7rEAA//dGHqs= Date: Tue, 11 Feb 2014 15:04:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D169D3B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> <8991EDBE-71F3-4456-A614-A9F4926F4955@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167CF8@ESESSMB209.ericsson.se> <1FC0C1C7-E5AB-4D4C-ABCC-8371457DCBF0@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167EAC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1695A8@ESESSMB209.ericsson.se>, <03B88F25-D4A7-468F-B9CE-165A1E6E4D10@phonefromhere.com> In-Reply-To: <03B88F25-D4A7-468F-B9CE-165A1E6E4D10@phonefromhere.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje4b619BBjsmmlmseH2O3WLtv3Z2 i4vbbzE6MHssWfKTyWPJpEY2j8mP25gDmKO4bFJSczLLUov07RK4Mm4cnclacEiw4vH1hywN jG95uxg5OSQETCQ2r+9lhrDFJC7cW8/WxcjFISRwiFFize8zjBDOYkaJF4fvA1VxcLAJWEh0 /9MGaRARUJM49+MwWDOzgKvEuZlTmEBsYQFDiaWP5zJB1BhJzF7ayQZhdzFKzOvOBLFZBFQl Jp98ChbnFfCVeLTgNtTiLnaJTR9OgyU4gYbevDuLFcRmBLru+6k1TBDLxCVuPZnPBHG1gMSS PeehPhCVePn4HyuErSix82w71HE6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYxWYhGTsLScss JC2zkLQsYGRZxciem5iZk15uuIkRGDkHt/zW3cF46pzIIUZpDhYlcd4Pb52DhATSE0tSs1NT C1KL4otKc1KLDzEycXBKNTDK3zx+s0pHUspei9FFLjg1X+3gw9zXKfM1639r2tY+Yfr5IW5p 3N7D7dNfsns9ubZla//m0sO1B3RlwrJF6v1Ov8rpYfBfXDP7/YaVOeyM6jOm9k/7pONjq8q/ 9L+j8NYSBrP6aw0TeVsupnwo71vxLeMFp1iDg++kuYoXfTk2B0feOK+YPFWJpTgj0VCLuag4 EQDDevvaagIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 15:04:17 -0000 Hi, >>>>>>> If however you have a gateway initating a call to a browser, and it >>>>>>> wants to do early media (it's an 800 number gateway for example) th= en it sets a=3Dsetup:active in the SDP it sends (or you create on it's beha= lf). >>>>>> >>>>>> There doesn't necessarily have to be a gateway. It may be a browser-= to-browser call, using SIP and SDP O/A on the wire - meaning that the SDP s= etup attribute is used to determine the roles. >>>>> >>>>> But there is no concept of early media on a peer-to-peer webRTC call,= so there isn't any need to manage which side is the DTLS client or server. >>>> >>>> Not sure what this has to do with early media. You can have two browse= r based applications, using SDP O/A to negotiate the DTLS roles. >>> >>> You only care about manipulating the DTLS roles if you want the side th= at _didn't_ initiate the call to initiate the media flow. The only instance= where that happens is early media. >>> Without early media there is no need to manipulate which end is client/= server since the default or initiator is client makes sense - or am I missi= ng something? >> >> I don't really have a need to "manipulate" the roles. I just want my JS = App to know what role its browser will take, so it can inform its peer (usi= ng whatever signaling protocol) about the role. > > well - assuming you leave a=3Dsetup as actpass (the default in the brows= er) . > If you called createOffer, then you'll be DTLS client. > If you called createAnswer you'll be DTLS server. > That's assuming no weirdness in the ICE implementation. So your JS can _d= educe_ the role but neither influence it nor _know_ it directly. > > However, signalling it over your high level signalling protocol is the wr= ong way to do it (IMHO). Your peer should deduce the appropriate DTLS role = from the 'signalling' > in the ICE packets, by looking at the ICE CONTROLLING flag. In SIP/SDP O/A it is done using the setup attribute (red: high level signal= ling protocol), and JSEP is based on SDP O/A, so... If we do NOT want to use the setup attribute to determine the DTLS roles, t= hen I think we need to have a separate discussion about that.=20 Regards, Christer From tim@phonefromhere.com Tue Feb 11 07:26: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 3DA651A0412 for ; Tue, 11 Feb 2014 07:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=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 fTu5_VoL2DHN for ; Tue, 11 Feb 2014 07:26:28 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by ietfa.amsl.com (Postfix) with ESMTP id 24D521A0376 for ; Tue, 11 Feb 2014 07:26:27 -0800 (PST) Received: (qmail 67596 invoked from network); 11 Feb 2014 15:26:26 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 10974 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 11 Feb 2014 15:26:26 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 1575818A034C; Tue, 11 Feb 2014 15:26:26 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id BF60518A033A; Tue, 11 Feb 2014 15:26:25 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D169D3B@ESESSMB209.ericsson.se> Date: Tue, 11 Feb 2014 15:26:16 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <44BD6D91-AF9F-47B1-AC79-6F3E86F016C7@phonefromhere.com> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> <8991EDBE-71F3-4456-A614-A9F4926F4955@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167CF8@ESESSMB209.ericsson.se> <1FC0C1C7-E5AB-4D4C-ABCC-8371457DCBF0@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167EAC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1695A8@ESESSMB209.ericsson.se>, <03B88F25-D4A7-468F-B9CE-165A1E6E4D10@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D169D3B@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1827) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 15:26:30 -0000 On 11 Feb 2014, at 15:04, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>>>>> If however you have a gateway initating a call to a browser, = and it >>>>>>>> wants to do early media (it's an 800 number gateway for = example) then it sets a=3Dsetup:active in the SDP it sends (or you = create on it's behalf). >>>>>>>=20 >>>>>>> There doesn't necessarily have to be a gateway. It may be a = browser-to-browser call, using SIP and SDP O/A on the wire - meaning = that the SDP setup attribute is used to determine the roles. >>>>>>=20 >>>>>> But there is no concept of early media on a peer-to-peer webRTC = call, so there isn't any need to manage which side is the DTLS client or = server. >>>>>=20 >>>>> Not sure what this has to do with early media. You can have two = browser based applications, using SDP O/A to negotiate the DTLS roles. >>>>=20 >>>> You only care about manipulating the DTLS roles if you want the = side that _didn't_ initiate the call to initiate the media flow. The = only instance where that happens is early media. >>>> Without early media there is no need to manipulate which end is = client/server since the default or initiator is client makes sense - or = am I missing something? >>>=20 >>> I don't really have a need to "manipulate" the roles. I just want my = JS App to know what role its browser will take, so it can inform its = peer (using whatever signaling protocol) about the role. >>=20 >> well - assuming you leave a=3Dsetup as actpass (the default in the = browser) . >> If you called createOffer, then you'll be DTLS client. >> If you called createAnswer you'll be DTLS server. >> That's assuming no weirdness in the ICE implementation. So your JS = can _deduce_ the role but neither influence it nor _know_ it directly. >>=20 >> However, signalling it over your high level signalling protocol is = the wrong way to do it (IMHO). Your peer should deduce the appropriate = DTLS role from the 'signalling' >> in the ICE packets, by looking at the ICE CONTROLLING flag. >=20 > In SIP/SDP O/A it is done using the setup attribute (red: high level = signalling protocol), and JSEP is based on SDP O/A, so... >=20 > If we do NOT want to use the setup attribute to determine the DTLS = roles, then I think we need to have a separate discussion about that.=20 we are using the setup attribute in a way. - actpass means we are = saying "we don't care". That leaves it to the lower levels to sort it = out - via the iceControlling flag. So now you see what caused the rant :-) T.= From christer.holmberg@ericsson.com Tue Feb 11 07:56: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 0AA5B1A05D3 for ; Tue, 11 Feb 2014 07:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 O-3dNNp0Y0L9 for ; Tue, 11 Feb 2014 07:56:13 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4ED1A05E0 for ; Tue, 11 Feb 2014 07:56:12 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-8e-52fa481b7e09 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id D8.C2.04853.B184AF25; Tue, 11 Feb 2014 16:56:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 16:56:11 +0100 From: Christer Holmberg To: Tim Panton Thread-Topic: [rtcweb] How to determine TLS roles? Thread-Index: Ac8mZBiXQux1+cpSRGeFwm+/NhCfyP//88iA///u0BCAABk5gP//7dswgAAbnoCAAC3h+IAAAg0A///I9eAADI1GgP//7kBQ//8EUwD//fBFYP/7rEAA//dGHqv/7pWMAP/dEq7V Date: Tue, 11 Feb 2014 15:56:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D169F84@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> <8991EDBE-71F3-4456-A614-A9F4926F4955@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167CF8@ESESSMB209.ericsson.se> <1FC0C1C7-E5AB-4D4C-ABCC-8371457DCBF0@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167EAC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1695A8@ESESSMB209.ericsson.se>, <03B88F25-D4A7-468F-B9CE-165A1E6E4D10@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D169D3B@ESESSMB209.ericsson.se>, <44BD6D91-AF9F-47B1-AC79-6F3E86F016C7@phonefromhere.com> In-Reply-To: <44BD6D91-AF9F-47B1-AC79-6F3E86F016C7@phonefromhere.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+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvja6Mx68ggweLmS1WvD7HbrH2Xzu7 xcXttxgdmD2WLPnJ5LFkUiObx+THbcwBzFFcNimpOZllqUX6dglcGRN+OxX856iYNKWVrYHx P1sXIyeHhICJxLSZz1ghbDGJC/fWA8W5OIQETjBKrP2yAMpZzCix59N9oCoODjYBC4nuf9og DSICahLnfhxmBrGZBVwlzs2cwgRiCwsYSix9PJcJosZIYvbSTrA5IgLTGCW2LD4BtplFQFXi 9IZnLCA2r4CvxJbdaxghlrVzSMza8w7sJE6gqXs3fABrYAQ67/upNUwQ28Qlbj2ZzwRxtoDE kj3nmSFsUYmXj/9BvaMo8fHVPkaIeh2JBbs/sUHY2hLLFr5mhlgsKHFy5hOWCYxis5CMnYWk ZRaSlllIWhYwsqxilCxOLS7OTTcy0MtNzy3RSy3KTC4uzs/TK07dxAiMroNbfhvtYDy5x/4Q ozQHi5I473XWmiAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjI1CLCufcT0s2fN8RdjC+Sby UrtlFbnPPRNaoC3UxjDXQen9Ao+fJ85PL/y5Pls3rHNCybziemW3ObOZNJ4FHrgQrf12RVHg 1TSzyRk9vEq6jnPOTODOuc+8Tvytd4JjTdubh10ebS71XEkNnp84j93v28Wj1hZ9z8H527Rl PP7Xjvh8+DWxV4mlOCPRUIu5qDgRAC/O5K98AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 15:56:15 -0000 Hi, >>> However, signalling it over your high level signalling protocol is the = wrong way to do it (IMHO). Your peer should=20 >>> deduce the appropriate DTLS role from the 'signalling' in the ICE packe= ts, by looking at the ICE CONTROLLING flag. >> >> In SIP/SDP O/A it is done using the setup attribute (red: high level sig= nalling protocol), and JSEP is based on SDP O/A, so... >> >> If we do NOT want to use the setup attribute to determine the DTLS roles= , then I think we need to have a separate discussion about that. > > we are using the setup attribute in a way. - actpass means we are saying= "we don't care".=20 That is NOT what it means in SDP O/A - it means "the other side decides" :) > That leaves it to the lower levels to sort it out - via the iceControllin= g flag. > > So now you see what caused the rant :-) One way would be to add some flag/parameter, to explicitly indicate the usa= ge of the iceControlling flag to determine the roles - if people want to do= that. The advantage is that it would be independent of the signalling prot= ocol used between the peers. Regards, Chrsiter From partha@parthasarathi.co.in Tue Feb 11 08:20: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 9BC731A05E5 for ; Tue, 11 Feb 2014 08:20:23 -0800 (PST) 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_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ZXp_k9ozjGVW for ; Tue, 11 Feb 2014 08:20:19 -0800 (PST) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.14]) by ietfa.amsl.com (Postfix) with ESMTP id B96CC1A0376 for ; Tue, 11 Feb 2014 08:20:19 -0800 (PST) Received: from userPC (unknown [122.172.226.139]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id AA1211908D11; Tue, 11 Feb 2014 16:20:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1392135618; bh=jvvmVPaFgHBITRb/0cz9lFHlVGs6XXigs4Gi4AKoIxI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=d0CN5JBhea7TOcSLgXzAuhMxiOTIU1wpN13zawUSuxnEkZkQZTUK+HIoEGzHcXgzN VHPXSKtetRaE88hfGKNSdLOQ4JM5PXNWtb7sPhwEt0txVF6gcLCcul5+xE+ByrKqqi Xnj3Q8epI5JjKb6ZJdMuhOC3lQRK/vfjjlk9BXtM= From: "Parthasarathi R" To: =?iso-8859-1?Q?'Stefan_H=E5kansson_LK'?= , "'Magnus Westerlund'" , References: <1447FA0C20ED5147A1AA0EF02890A64B1CF4A182@ESESSMB209.ericsson.se> <007601cf2423$2d571210$88053630$@co.in> <1447FA0C20ED5147A1AA0EF02890A64B1CF533B8@ESESSMB209.ericsson.se> <004601cf24ad$f3a1c0c0$dae54240$@co.in> <52F8B1AB.70305@ericsson.com> <1447FA0C20ED5147A1AA0EF02890A64B1CF54AD5@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1CF54AD5@ESESSMB209.ericsson.se> Date: Tue, 11 Feb 2014 21:50:06 +0530 Message-ID: <013501cf2745$24e02610$6ea07230$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8jKZAtHwyyT87MQ3ivvr7TXBW1mAEGx53Q Content-Language: en-us X-CTCH-RefID: str=0001.0A020202.52FA4DC2.01D0, 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 70.87.28.138 Subject: Re: [rtcweb] New version of use-case draft uploaded X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 16:20:23 -0000 Hi Stefan, > "Note that ICE support being mandatory does not preclude a = WebRTC > endpoint from supporting more traversal mechanisms than ICE using STUN > and TURN." >=20 > OK? OK for me. Thanks Partha > -----Original Message----- > From: Stefan H=E5kansson LK [mailto:stefan.lk.hakansson@ericsson.com] > Sent: Tuesday, February 11, 2014 3:46 PM > To: Magnus Westerlund; Parthasarathi R; rtcweb@ietf.org > Subject: Re: [rtcweb] New version of use-case draft uploaded >=20 > On 2014-02-10 12:02, Magnus Westerlund wrote: > > Hi Partha, > > > > See inline > > > > On 2014-02-08 10:12, Parthasarathi R wrote: > >> Hi Stefan, > >> > >> > >>> Yes, I did that change (TURN -> ICE). My understanding was that = ICE > is > >>> what is used/mandated (and it in turn makes use of STUN and TURN). > >>> > >> > >> > >> ICE is mandated in RTCWeb but I disagree to your assumption that = ICE > in turn > >> makes use of TURN. My concern is that The requirement document is > misleading > >> about TURN requirements. ICE-TCP avoids TURN server as the middle- > box in the > >> network. ICE-TCP is host candidate whereas TURN is relay candidate > and as > >> per ICE candidate selection, host candidate is preferred over relay > >> candidates. > > > > I will agree that the note as currently worded is not completely > > accurate and clear. Based on the text in the preceding section, it > makes > > sense to note that ICE using STUN and TURN is not the only solution > > including additional ICE modes or relay services. I request the > authors > > propose a new formulation of the note. >=20 > Proposal: >=20 > "Note that ICE support being mandatory does not preclude a WebRTC > endpoint from supporting more traversal mechanisms than ICE using STUN > and TURN." >=20 > OK? >=20 > =3D From partha@parthasarathi.co.in Tue Feb 11 09:18: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 712EF1A0694 for ; Tue, 11 Feb 2014 09:18:30 -0800 (PST) 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_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mFC3FwIogzzY for ; Tue, 11 Feb 2014 09:18:28 -0800 (PST) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.21]) by ietfa.amsl.com (Postfix) with ESMTP id 03CD01A068E for ; Tue, 11 Feb 2014 09:18:27 -0800 (PST) Received: from userPC (unknown [122.172.226.139]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 0E5FA639791; Tue, 11 Feb 2014 17:18:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1392139106; bh=A9jBC7RSOtjl7mJt2ks+dqPAtrWmh4yf0KVH+k8hPv0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Q0M2TJauBrAxNB+hpkQeFYyodhOmBdyaI6El2yHu+LUqhWp1wSDJgB8wT/5yMmfK5 HaIrR6FnU5fR679MZF9alN5i7onYI6xndiPGP/kSzbcPiOhSusChRChJpjg2JHPu1i Nrgtrf9QR2R+8s+AQzjN+9FbUKxHzHxAsV2wZdB8= From: "Parthasarathi R" To: "'Magnus Westerlund'" , =?iso-8859-1?Q?'Stefan_H=E5kansson_LK'?= , References: <1447FA0C20ED5147A1AA0EF02890A64B1CF4A182@ESESSMB209.ericsson.se> <007601cf2423$2d571210$88053630$@co.in> <1447FA0C20ED5147A1AA0EF02890A64B1CF533B8@ESESSMB209.ericsson.se> <004601cf24ad$f3a1c0c0$dae54240$@co.in> <52F8B1AB.70305@ericsson.com> <013901cf2693$97c1eb30$c745c190$@co.in> <52FA1BDB.5010709@ericsson.com> In-Reply-To: <52FA1BDB.5010709@ericsson.com> Date: Tue, 11 Feb 2014 22:48:16 +0530 Message-ID: <016901cf274d$44332000$cc996000$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8nJ2nX3bAnyabxQS+Yw7g5f9uNsQAHbkzA Content-Language: en-us X-CTCH-RefID: str=0001.0A020209.52FA5B63.0059, 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 70.87.28.142 Subject: Re: [rtcweb] New version of use-case draft uploaded X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 17:18:30 -0000 Hi Magnus, Please read inline. Thanks Partha > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, February 11, 2014 6:17 PM > To: Parthasarathi R; 'Stefan H=E5kansson LK'; rtcweb@ietf.org > Subject: Re: [rtcweb] New version of use-case draft uploaded >=20 > On 2014-02-10 20:09, Parthasarathi R wrote: > > Hi Magnus, > > > > Thanks for proposing a new formulation of the note by the authors. I > agree > > with you that F2 and F29 are generic WebRTC NAT/Firewall = requirements > which > > does not restrict ICE-TCP as one of the solution. > > > > The confusion with F31 and F32 requirements is because of the = missing > of > > WebRTC server/gateway requirements. F31 and F32 leads to the > assumption of > > mandating TURN servers in the WebRTC server/gateway (by some of the > WebRTC > > gateway Providers) as there is no text in this usecase & requirement > > document to clarify. >=20 > Sorry, I fail to understand which of multiple possible angles you are > arguing here. >=20 > A) That the use case document is missing a whole requirement related = to > WebRTC Servers. WebRTC server, is something I am uncertain to what you > refer to, a Web server or a media plan related server dealing with = peer > connections? >=20 WebRTC server/gateway is a server which is a combination of Web Server which handles WebRTC signaling and Media Plane server which deals with peer-connection. Sec 3.4 of draft-ietf-rtcweb-use-cases-and-requirements-13 describes 3 usecases for = the same. Unfortunately, draft-ietf-rtcweb-use-cases-and-requirements-13 is missing NAT/Firewall traversal requirement related to WebRTC = server/gateway. > B) That F31 and F32 would lead to an assumption of mandating = something, > which currently is the only solution described? >=20 =20 IMO, WebRTC server/gateway does not require TURN server and ICE-TCP = serve the purpose (Maximum of single WebRTC endpoint behind the firewall = scenario in a two party WebRTC session). As F31 and F32 mandates for TURN and = there is no NAT/Firewall explicit requirement for WebRTC server/gateway, it = leads to the conclusion of TURN server as an only solution by some of WebRTC gateway providers. Hope this clarifies. > C) That there needs to be text describing some aspect of the global > presence? >=20 It is good to have the text which describe NAT/firewall = traversal for WebRTC server/gatway perspective as well. I could not understand why = you are not allowing the changing F31 and F32 or adding the text about = WebRTC server NAT/firewall traversal in sec 3.4. Could you please clarify. >=20 > I have already wrote in the separate mail thread > > (http://www.ietf.org/mail-archive/web/rtcweb/current/msg11338.html) > to > > provide WebRTC server/gateway guidelines document for more clarity. >=20 > Good, can you leave with the text and Stefan's text proposal for the > note? >=20 I agree for Stefan's proposal in the separate mail thread as it = is related to WebRTC endpoints requirement. > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From partha@parthasarathi.co.in Tue Feb 11 09:28: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 825651A05CD for ; Tue, 11 Feb 2014 09:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=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 zjOEWAZZenfv for ; Tue, 11 Feb 2014 09:28:40 -0800 (PST) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.19]) by ietfa.amsl.com (Postfix) with ESMTP id 371711A063F for ; Tue, 11 Feb 2014 09:28:40 -0800 (PST) Received: from userPC (unknown [122.172.226.139]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id AEBF2638C68; Tue, 11 Feb 2014 17:28:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1392139719; bh=DfOgxAdP18paLTHN7BAoL93wTzTHTBwiu7Y1uG8ZiEY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=T9wofR+vXFKguL6/RCn8aiVybMe8/VbTl63iYMUtkyRgSo2TIBPAwBST6AK141V6A vvPurJpFsnr+JqNUlMORg97ZKI48nRC8MINdm0jtEoPLM0ZRxXWkIcIYKimF3siOPo CPKwXbaJWp1Fv5e5LDUcfL4bR4JaWtsKd84c10Pc= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Tim Panton'" References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> <8991EDBE-71F3-4456-A614-A9F4926F4955@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167CF8@ESESSMB209.ericsson.se> <1FC0C1C7-E5AB-4D4C-ABCC-8371457DCBF0@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167EAC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1695A8@ESESSMB209.ericsson.se>, <03B88F25-D4A7-468F-B9CE-165A1E6E4D10@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D169D3B@ESESSMB209.ericsson.se>, <44BD6D91-AF9F-47B1-AC79-6F3E86F016C 7@phonefromhere.com> < 7594FB04B1934943A5C02806D1A2204B1D169F84@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D169F84@ESESSMB209.ericsson.se> Date: Tue, 11 Feb 2014 22:58:29 +0530 Message-ID: <016b01cf274e$b15a6f20$140f4d60$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8mZBiXQux1+cpSRGeFwm+/NhCfyP//88iA///u0BCAABk5gP//7dswgAAbnoCAAC3h+IAAAg0A///I9eAADI1GgP//7kBQ//8EUwD//fBFYP/7rEAA//dGHqv/7pWMAP/dEq7V/7oM0wA= Content-Language: en-us X-CTCH-RefID: str=0001.0A020205.52FA5DC7.019A, 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 70.87.28.142 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] How to determine TLS roles? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 17:28:42 -0000 Hi Christer, I agree with you that SDP setup attribute has to be used to determine the TLS role as it is not required that the remote side is also WebRTC endpoint. Thanks Partha > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: Tuesday, February 11, 2014 9:26 PM > To: Tim Panton > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] How to determine TLS roles? > > > Hi, > > >>> However, signalling it over your high level signalling protocol is > the wrong way to do it (IMHO). Your peer should > >>> deduce the appropriate DTLS role from the 'signalling' in the ICE > packets, by looking at the ICE CONTROLLING flag. > >> > >> In SIP/SDP O/A it is done using the setup attribute (red: high level > signalling protocol), and JSEP is based on SDP O/A, so... > >> > >> If we do NOT want to use the setup attribute to determine the DTLS > roles, then I think we need to have a separate discussion about that. > > > > we are using the setup attribute in a way. - actpass means we are > saying "we don't care". > > That is NOT what it means in SDP O/A - it means "the other side > decides" :) > > > That leaves it to the lower levels to sort it out - via the > iceControlling flag. > > > > So now you see what caused the rant :-) > > One way would be to add some flag/parameter, to explicitly indicate the > usage of the iceControlling flag to determine the roles - if people > want to do that. The advantage is that it would be independent of the > signalling protocol used between the peers. > > Regards, > > Chrsiter > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Tue Feb 11 09:50: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 A618E1A0689 for ; Tue, 11 Feb 2014 09:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 G7FLOawMgUkL for ; Tue, 11 Feb 2014 09:50:40 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E9B481A0691 for ; Tue, 11 Feb 2014 09:50:39 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-d1-52fa62ee6287 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B5.E8.23809.EE26AF25; Tue, 11 Feb 2014 18:50:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 18:50:38 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: RTCWEB Data Channel Protocol: Label vs Protocol glare Thread-Index: Ac8nUY8MdmECwmXERwuUTRwOK9mRzA== Date: Tue, 11 Feb 2014 17:50:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16D248@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.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D16D248ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvje67pF9BBntnWlus/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ1PtzAWfFSsOHO5nbmBcZZsFyMnh4SAiUTn5v/sELaYxIV7 69m6GLk4hAQOMUqc3XiWFcJZzCixv+M7UBUHB5uAhUT3P22QBhEBdYnLDy+ANQsL2ElMWP2G CSLuLPH2z1IoW09i/ZszjCA2i4CqxM2p88HivAK+Eh27P4DFGYEWfz+1BizOLCAucesJRI2E gIDEkj3nmSFsUYmXj/+xQthKEj82XGKBqM+XmHV8JjPETEGJkzOfsExgFJqFZNQsJGWzkJRB xHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYzsuYmZOenlRpsYgWF/cMtv1R2Md86JHGKU 5mBREuf98NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjiv6nC17XHPGyFd/YzcciK3wu ySvBJvHJp5rOhzIm/bfXnMsSWHX7zIW8P7lXUqOMDac1aUm9265V2GM2I/fB5l8ncq9NnpZ8 gtHrTrbg8v2BSR+uZe48pM/Z/Njgy5psfYkF9//Nakp7tq6+NMXjs8tUlz9/V2zqPLFc0yX9 +PV/F8syPTf+V2Ipzkg01GIuKk4EADhD74xJAgAA Subject: [rtcweb] RTCWEB Data Channel Protocol: Label vs Protocol glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 17:50:42 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D16D248ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The draft says: "Note: There is no attempt to resolve label glare; if both sides open a Channel labeled "x" at the same time, there will be two C= hannels labeled "x" - one on an even Stream pair, one on an odd pai= r." I think the text shall be extended to also cover the Protocol, i.e. both en= ds can try to open a channel for protocol X at the same time. Also, even if there is a label glare, it doesn't have to be for the same pr= otocol. As far as I know, endpoints can choose whatever label value they wa= nt, and they don't even need to be for the same protcol (unless specific pr= otocols define what label value(s) must be used for channels associated wit= h that protocol). Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D16D248ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The draft says:

 

“Note: There is no = attempt to resolve label glare; if both sides open

         &nb= sp;      a Channel labeled "x" at the sa= me time, there will be two Channels

         &nb= sp;      labeled "x" - one on an even St= ream pair, one on an odd pair.”

 

I think the text shall be extended to also cover the= Protocol, i.e. both ends can try to open a channel for protocol X at the s= ame time.

 

Also, even if there is a label glare, it doesn’= ;t have to be for the same protocol. As far as I know, endpoints can choose= whatever label value they want, and they don’t even need to be for t= he same protcol (unless specific protocols define what label value(s) must be used for channels associated with that protoco= l).

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D16D248ESESSMB209erics_-- From pthatcher@google.com Tue Feb 11 10:06: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 8DDD01A0678 for ; Tue, 11 Feb 2014 10:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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, RP_MATCHES_RCVD=-0.548, 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 k6EvyvZ497ay for ; Tue, 11 Feb 2014 10:06:47 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 87A211A0665 for ; Tue, 11 Feb 2014 10:06:46 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id x10so7742193pdj.8 for ; Tue, 11 Feb 2014 10:06:46 -0800 (PST) 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=oxil+HKPkoWKz8DQVJtu9vCbIVWTg0Rb8W2TKqyG8QM=; b=nFTc2P/ZVUCi6IByKjDNqQPWfDMwGgILk3gu7m8NhqACJtx1WnZqfXcX+Up//aT88S 5ceg5MVQU9PqoAuCNGfsJ0mqH4uX3NlIoBh8Ef7FyGYQxhZy6v/G9Fu8TFFSHatxBNCU zwsa/QctBXZRXUXLcuNPvHDVusb1Hd/tLR8dls2O0vuRXsy+2r/KC4K1HIRTinKFoG/O Eaw1hmvWumPi9tcBRCfGe3UAOtu3SiyWDAfaEBmcezlqouRxEtDvS7IBVqpEUn70GCWw IQJorwIhugVNpB2FBxq6J5Rhnjcx3DB1/kHB/E2N2yUPjWpewi6IKUfREUkw5LZ403ys 2dHg== 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=oxil+HKPkoWKz8DQVJtu9vCbIVWTg0Rb8W2TKqyG8QM=; b=cyKhQAJpLIEa6usUtBZer97zgE+hXBQCE3jcjPqs3NmSFRnKkA91fppPIRuoAYGd8t 448B7GywU7+7OFWvxLxge6Q6DDq5arPoRbkJdaLYPFfCe3ljAhbKU4uVjgRnMP6OoCwb LNXQpFk+TVQI+xNBc2Ye6VUt0e+unKdps495AIxutKriQq9df6FG0SN+y3xFTiJX5yeQ 9iuBq/c6/420rhpO8ISSrn+q7GiLxQAL0B1snisC6DelqmJ+tfM1un7+OZ/+kS+lBOJB JqsFvXkpZdNeusovf/065MMeapmqUhFv9zIx7XegBEmhXXyhwcASq40zDA2HYbmxwu4o 5n0w== X-Gm-Message-State: ALoCoQmI97rEZxWcXOlYtZ+oe+BZTBl7JGndWvonP176QuyJgRhC9BSYVnWXopEZYkvEZ0/C8Z0tikWNY+h/NNLZRF5pV+MTpt18+0u2DiQoAFn5tRHFYBmLKFthfvS+x3LgJSe4yRHgtMVdSV6TLrTu46XKV4zhD40BPZFnRZXSLfU3BF2GRJAB2FA5vZLW2FCWbPrbM1Oz X-Received: by 10.68.226.200 with SMTP id ru8mr46233078pbc.77.1392142005923; Tue, 11 Feb 2014 10:06:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.163.234 with HTTP; Tue, 11 Feb 2014 10:06:05 -0800 (PST) In-Reply-To: <52F9786F.60809@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se> <4616BFFA-F461-4CE8-9D85-211B86D4BE93@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166D7B@ESESSMB209.ericsson.se> <71288EED-3C82-44A7-950B-EFEFA62616E6@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166F8C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167A2E@ESESSMB209.ericsson.se> <52F9786F.60809@alum.mit.edu> From: Peter Thatcher Date: Tue, 11 Feb 2014 10:06:05 -0800 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=e89a8ffba0e3bd8c1704f2255158 Cc: "" Subject: Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 18:06:50 -0000 --e89a8ffba0e3bd8c1704f2255158 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe the API already gives you all the tools you need for this use case. Here's one way to create a data channel where both ends call createDataChannel() at the same time, with no "middle": 1. Both sides call createDataChannel() with the same label. 2. If an endpoint ends up with two data channels with the same label, close the one with the higher .id, and keep the one with the lower .id. Now both sides will use the same channel, and you can pretend like the other never existed. If you're worried about data sent before this process completes, either accept data on both channels for a while, or don't send data until the process completes. Is there any reason this would not work? On Mon, Feb 10, 2014 at 5:10 PM, Paul Kyzivat wrote= : > You two guys are talking past one another. > > Christer's point is that the *application" distributed between the two > endpoints, needs a *single* instance of a channel for a particular > application specific purpose. But the two ends are generally symmetric. > There is no obvious choice of which side should create the channel. So ho= w > do we use the mechanism to achieve this result? > > I think I can predict what Michael is going to say: it isn't a protocol > issue - the two ends should negotiate this some other way. (In the normal > rtcweb scenario, a *single* app in the middle can arrange for one side to > do the open.) > > This is a problem with a sip app - there is no middle, just two ends. > > > Previously Christer said: > > Couldn=E2=80=99t we e.g. say that, by default, the DTLS client is respon= sible for >> sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it >> could even use both an even or odd stream id value. >> > > That is a bad thing for data channel in general. But I suppose the app ca= n > choose to follow this rule if it wants for particular channels. > > Thanks, > Paul > > > > > > > On 2/10/14 12:29 PM, Christer Holmberg wrote: > >> >> Hi, >> >> As is defined in the data channel protocol, an entity can send data >>>>>>>> once DATA_CHANNEL_OPEN has been sent, before the associated >>>>>>>> DATA_CHANNEL_ACK is received. >>>>>>>> >>>>>>>> The draft also says that, if both endpoints send DATA_CHANNEL_OPEN >>>>>>>> at the same time, using different stream id values, the result may= be TWO >>>>>>>> data channels, with data sent on both. >>>>>>>> >>>>>>>> However, as is also indicated, the draft does not provide a >>>>>>>> mechanism to prevent/handle such glare situation. >>>>>>>> >>>>>>>> I personally think there shall be a way to prevent such situation, >>>>>>>> or otherwise I'm sure we are going to end up with interoperability= problems. >>>>>>>> >>>>>>>> Couldn't we e.g. say that, by default, the DTLS client is >>>>>>>> responsible for sending the DATA_CHANNEL_OPEN? Then there is no ri= sk for >>>>>>>> glare, and it could even use both an even or odd stream id value. >>>>>>>> >>>>>>> Section 4 reads: >>>>>>> >>>>>>> To avoid glare in opening Channels, each side MUST use either even >>>>>>> or odd Streams when sending a DATA_CHANNEL_OPEN message. The meth= od >>>>>>> used to determine which side uses odd or even is based on the >>>>>>> underlying DTLS connection role when used in WebRTC, with the side >>>>>>> acting as the DTLS client using even stream identifiers. >>>>>>> >>>>>>> So there is no problem in setting up data channels. >>>>>>> >>>>>>> This should not be confused by both sides setting up a data channel >>>>>>> with the same Label. This ends up in two data channels with the sam= e label. >>>>>>> You can even create more data channels with the same label. >>>>>>> >>>>>> >>>>>> My point is that I don't want to end up with more than one channel. >>>>>> >>>>> And you won't, see above. >>>>> >>>> >>>> I am not sure I understand. What text do you refer to? >>>> >>> To avoid glare in opening Channels, each side MUST use either even >>> or odd Streams when sending a DATA_CHANNEL_OPEN message. The method >>> used to determine which side uses odd or even is based on the >>> underlying DTLS connection role when used in WebRTC, with the side >>> acting as the DTLS client using even stream identifiers. >>> >> >> That part I understand. >> >> But, this means that both endpoints may send DATA_CHANNEL_OPEN, for the >> same protocol, and THAT is what I would like to avoid. I don't want to h= ave >> two bi-directional data channels for the same thing. >> >> For that reason I suggested that we could also specify which endpoint is >> responsisble for sending DATA_CHANNEL_OPEN. >> >> >> However, there is no mechanism to ensure uniqueness for labels. The >>>>> WebRTC API already allows one side to create n data channels with the= same >>>>> label. >>>>> >>>> >>>> I am not saying it should be forbidden to do so. But, for protocol X, = I >>>> want to end up with ONE data channel between my peers. >>>> Then only one side should create a data channel. >>>> >>>> If I end up with two data channels for protocol X, can I send data on >>>> whichever I want to? >>>> >>> Sure. These would be two independent bidirectional data channels. >>> >> >> Possible for the same protocol - and that is what I would want to avoid. >> I want to send my protocol X messages on one data channel, and I would l= ike >> to receive the protocol X messages from my peer on the same data channel= . >> >> Now, one can of course solve this by reseting one of the data channels, >> but then the question is which endpoint should reset :) >> >> 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 > --e89a8ffba0e3bd8c1704f2255158 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe the API already gives you all the tools you need for = this use case. =C2=A0Here's one way to create a data channel where both= ends call createDataChannel() at the same time, with no "middle"= :

<= /div>
= 1. =C2=A0Both sides call createDataChannel() with the same label.
=
2. =C2=A0If an endpoint ends up with two data channels with the same label,= close the one with the higher .id, and keep the one with the lower .id.
Now b= oth sides will use the same channel, and you can pretend like the other nev= er existed. =C2=A0 If you're worried about data sent before this proces= s completes, either accept data on both channels for a while, or don't = send data until the process completes.

<= /div>
= Is there any reason this would not work?

On Mon, Feb 10, 2014 at 5:10 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
You two guys are talking past one another.

Christer's point is that the *application" distributed between the= two endpoints, needs a *single* instance of a channel for a particular app= lication specific purpose. But the two ends are generally symmetric. There = is no obvious choice of which side should create the channel. So how do we = use the mechanism to achieve this result?

I think I can predict what Michael is going to say: it isn't a protocol= issue - the two ends should negotiate this some other way. (In the normal = rtcweb scenario, a *single* app in the middle can arrange for one side to d= o the open.)

This is a problem with a sip app - there is no middle, just two ends.


Previously Christer said:

Couldn=E2=80=99t we e.g. say that, by default, the DTLS client is responsib= le for sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and = it could even use both an even or odd stream id value.

That is a bad thing for data channel in general. But I suppose the app can = choose to follow this rule if it wants for particular channels.

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





On 2/10/14 12:29 PM, Christer Holmberg wrote:

Hi,

As is defined in the data channel protocol, an entity can send data once DA= TA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK is re= ceived.

The draft also says that, if both endpoints send DATA_CHANNEL_OPEN at the s= ame time, using different stream id values, the result may be TWO data chan= nels, with data sent on both.

However, as is also indicated, the draft does not provide a mechanism to pr= event/handle such glare situation.

I personally think there shall be a way to prevent such situation, or other= wise I'm sure we are going to end up with interoperability problems.
Couldn't we e.g. say that, by default, the DTLS client is responsible f= or sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it c= ould even use both an even or odd stream id value.
Section 4 reads:

To avoid glare in opening Channels, each side MUST use either even
or =C2=A0odd Streams when sending a DATA_CHANNEL_OPEN message. =C2=A0The me= thod
used to determine which side uses odd or even is based on the
underlying DTLS connection role when used in WebRTC, with the side
acting as the DTLS client using even stream identifiers.

So there is no problem in setting up data channels.

This should not be confused by both sides setting up a data channel with th= e same Label. This ends up in two data channels with the same label.
You can even create more data channels with the same label.

My point is that I don't want to end up with more than one channel.
And you won't, see above.

I am not sure I understand. What text do you refer to?
To avoid glare in opening Channels, each side MUST use either even
or =C2=A0odd Streams when sending a DATA_CHANNEL_OPEN message. =C2=A0The me= thod
used to determine which side uses odd or even is based on the
underlying DTLS connection role when used in WebRTC, with the side
acting as the DTLS client using even stream identifiers.

That part I understand.

But, this means that both endpoints may send DATA_CHANNEL_OPEN, for the sam= e protocol, and THAT is what I would like to avoid. I don't want to hav= e two bi-directional data channels for the same thing.

For that reason I suggested that we could also specify which endpoint is re= sponsisble for sending DATA_CHANNEL_OPEN.


However, there is no mechanism to ensure uniqueness for labels. The WebRTC = API already allows one side to create n data channels with the same label.<= br>

I am not saying it should be forbidden to do so. But, for protocol X, I wan= t to end up with ONE data channel between my peers.
Then only one side should create a data channel.

If I end up with two data channels for protocol X, can I send data on which= ever I want to?
Sure. These would be two independent bidirectional data channels.

Possible for the same protocol - and that is what I would want to avoid. I = want to send my protocol X messages on one data channel, and I would like t= o receive the protocol X messages from my peer on the same data channel.
Now, one can of course solve this by reseting one of the data channels, but= then the question is which endpoint should reset :)

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

--e89a8ffba0e3bd8c1704f2255158-- From christer.holmberg@ericsson.com Tue Feb 11 10:12: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 40FB81A0696 for ; Tue, 11 Feb 2014 10:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 u-R0oUludGqM for ; Tue, 11 Feb 2014 10:12:43 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2661A0694 for ; Tue, 11 Feb 2014 10:12:42 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-42-52fa68188d6b Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 5F.2F.04853.8186AF25; Tue, 11 Feb 2014 19:12:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 19:12:40 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Some editorial comments on section 5 Thread-Index: Ac8nU+WsE4W5K/avTLyRu1AtQ1+x3g== Date: Tue, 11 Feb 2014 18:12:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16D2A3@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.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyM+Jvja5kxq8gg5mz+S3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuIflxgLFvNWLJ6xlqmBsZOri5GTQ0LAROLywc/MELaYxIV7 69m6GLk4hAROMEpMOrGRGcJZzChx810rSxcjBwebgIVE9z9tkAYRAXWJyw8vsIPYwgIFEivv fmAHKRERKJR4MjsQokRPom3CSiYQm0VAVWJVywUWEJtXwFdiyeLtrCA2I9De76fWgNUwC4hL 3HoynwniHgGJJXvOQ90mKvHy8T9WCFtJ4seGSywQ9ToSC3Z/YoOwtSWWLXzNDDFfUOLkzCcs ExiFZyEZOwtJyywkLbOQtCxgZFnFKFmcWlycm25koJebnluil1qUmVxcnJ+nV5y6iREY6Ae3 /DbawXhyj/0hRmkOFiVx3uusNUFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGAVlTPU9Zu1e te/uhTLLWJZ+x57p4l/855/7vFPlVKeE/slzadlWpw5f5V6j6fh6fklZgaVM2vOVLIoLglUt d1vM8nKfrsLT5HPfvuxfbnBK5stf9nY31sSwHfYQVzvIe7v57PEFmepqNY4OYiwJ5ZI7Cw3X /9l5PeZcQ8TU5CcLvP0cEj25lViKMxINtZiLihMB8/uUhEICAAA= Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Some editorial comments on section 5 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 18:12:44 -0000 Hi, Some editorial comments: Q1: Section 5 says: "SCTP as specified in [RFC4960] MUST be used in combination with the extension defined in [RFC3758] and provides the following interesting features for transporting non-media data between browsers:" I suggest to say: "The SCTP extension defined in [RFC3758] MUST be supported, and provides the following features: Q2: Section 5 says: "Each SCTP user message contains a so called Payload Protocol Identifier (PPID) that is passed..." I suggest to remove "so called". Q3: Section 5 says: "This value can be used to multiplex multiple protocols over a single SCTP association. The sender provides for each protocol a specific PPID and the receiver can demultiplex the messages based on the received PPID." I think we discussed this earlier. The PPID value CAN NOT (at least not as = used by WebRTC) be used to multiplex multiple protocols over a single SCTP = association. If you create multiple channels, for multiple protocols, the s= ame PPID values may be used for each protocol. The PPID CAN, however, be used within a data channel, e.g. to demultiplex = the DCP from channel data. Q4: Section 5 says: "When using DTLS as the lower layer, only single homed SCTP associations MUST be used, since DTLS does not expose any address management to its upper layer." I suggest to change "MUST be used" to "are supported". Q5: Sometimes you say "SCTP" and sometimes "SCTP as defined in [RFC4960]". I suggest to e.g. use the reference on the first occurrence, and then only = use "SCTP". Regards, Christer From christer.holmberg@ericsson.com Tue Feb 11 10:15: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 936EB1A066C for ; Tue, 11 Feb 2014 10:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 gbcklWyXTB45 for ; Tue, 11 Feb 2014 10:15:34 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 93A971A0689 for ; Tue, 11 Feb 2014 10:15:34 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-20-52fa68c598b6 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BB.DA.23809.5C86AF25; Tue, 11 Feb 2014 19:15:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 19:15:33 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Comment on section 6 title Thread-Index: Ac8nVPFNLUjUgV0jQBWV6hVVCkMWSA== Date: Tue, 11 Feb 2014 18:15:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16D2BA@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.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvje7RjF9BBu1v1SzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqEDM9gLPjJVTF+5na2BcS5TFyMnh4SAicS06RugbDGJC/fW s3UxcnEICRxilFjZ84YJwlnMKHHsxwOgDAcHm4CFRPc/bZAGEQF1icsPL7CD2MICaRJPrmxl hYinSzS8XAll60n0df9gBWllEVCV+H0mAiTMK+Ar8fTKMrC9jEB7v59aA2YzC4hL3HoyH+oe AYkle84zQ9iiEi8f/2OFsJUkfmy4xAJRryOxYPcnNghbW2LZwtfMEPMFJU7OfMIygVF4FpKx s5C0zELSMgtJywJGllWM7LmJmTnp5UabGIFBfHDLb9UdjHfOiRxilOZgURLn/fDWOUhIID2x JDU7NbUgtSi+qDQntfgQIxMHp1QDo+CdZ3dvPr/Cs0y855SNx/H0YxfPyK2uufs1J8f+XGG3 9eSyYp5VwtcDVaXXXGotjSosinvm5N/2O0MtbELmFiWpFc5Hlif8mvSw76/h/S6Jdha/1FaZ 3SxTBF5uWsX507LL8KhHWKru72d9h7MSGL5XWR0wPpJZe5xd9U30n+N6W27ff1x1QomlOCPR UIu5qDgRAJrxZbUwAgAA Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Comment on section 6 title X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 18:15:36 -0000 Hi, Section 6 describes the characteristics of the data channel. However, the section name is "The Usage of SCTP in the WebRTC Context". I think we should rename that to something like "The Usage of SCTP for the = WebRTC Data Channel". Because, the definition of the channel is the same no matter in which conte= xt it is used :) Regards, Christer From christer.holmberg@ericsson.com Tue Feb 11 10:22: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 6509E1A06DC for ; Tue, 11 Feb 2014 10:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 g40z_C6ZGc2n for ; Tue, 11 Feb 2014 10:22:55 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id AEC281A06D5 for ; Tue, 11 Feb 2014 10:22:54 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-da-52fa6a7d7aad Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id D8.EF.04853.D7A6AF25; Tue, 11 Feb 2014 19:22:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 19:22:53 +0100 From: Christer Holmberg To: 'Peter Thatcher' , Paul Kyzivat Thread-Topic: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare Thread-Index: Ac8mR2/m3LFj8oi+SFKLxbYiytu9PP//8tkA///uSjCAABcpAP//4ZBAgACIq4CAABjmc4AAcPCAgAEb3ID//+u2AA== Date: Tue, 11 Feb 2014 18:22:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16D2F3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se> <4616BFFA-F461-4CE8-9D85-211B86D4BE93@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166D7B@ESESSMB209.ericsson.se> <71288EED-3C82-44A7-950B-EFEFA62616E6@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166F8C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167A2E@ESESSMB209.ericsson.se> <52F9786F.60809@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+JvjW5t1q8gg7nPtCxWbDjAanFt+WtW i7X/2tkdmD3+vv/A5LFgU6nHkiU/mQKYo7hsUlJzMstSi/TtErgyZt86zVjwy77ixZGpjA2M K+y6GDk5JARMJH4vW8sOYYtJXLi3nq2LkYtDSOAEo8S0ph+MEM5iRomzUx8DZTg42AQsJLr/ aYM0iAgES0xb+IkNxGYW0JSYsGwXmC0s4COx7MA+ZogaX4lrl+axQdhZEhv+TmcBsVkEVCXm /VoOtpgXqOZ251MmiF0bWSRuXTzICpLgFAiUWNHwkRHEZgS67vupNUwQy8Qlbj2ZzwRxtYDE kj3nmSFsUYmXj/+xQthKEj82XGIBuRnkuPW79CFaFSWmdD+E2isocXLmE5YJjGKzkEydhdAx C0nHLCQdCxhZVjFKFqcWF+emGxno5abnluilFmUmFxfn5+kVp25iBMbVwS2/jXYwntxjf4hR moNFSZz3OmtNkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGZSfuM3vfb4xTNQ8x/G+14czs i6/mRkddfvLjT7PZ0YP7TH5pmTT1v6vfmDCr4dK717qb3jMf63i54v7m1tgDbX8Zecp5/TrU r+xZoFsa0BrM1iRV487uLHjT6cjpH2Lv5bk6K+LO2zoHunyL3uf4cfLPJexfpCOypYverX+2 buVV4w3Kn6xXKbEUZyQaajEXFScCAAIFm6N5AgAA Cc: "" Subject: Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 18:22:57 -0000 SGkgUGV0ZXIsDQoNCj4gSSBiZWxpZXZlIHRoZSBBUEkgYWxyZWFkeSBnaXZlcyB5b3UgYWxsIHRo ZSB0b29scyB5b3UgbmVlZCBmb3IgdGhpcyB1c2UgY2FzZS4gwqBIZXJlJ3Mgb25lIHdheSB0byBj cmVhdGUgYSBkYXRhIGNoYW5uZWwgd2hlcmUgYm90aCBlbmRzIGNhbGwgY3JlYXRlRGF0YUNoYW5u ZWwoKSBhdCB0aGUgc2FtZSB0aW1lLCB3aXRoIG5vICJtaWRkbGUiOg0KPg0KPiAxLiDCoEJvdGgg c2lkZXMgY2FsbCBjcmVhdGVEYXRhQ2hhbm5lbCgpIHdpdGggdGhlIHNhbWUgbGFiZWwuDQoNCk9y LCB3aXRoIHRoZSBzYW1lIFByb3RvY29sLg0KDQpJdCBpcyBhIGxpdHRsZSB1bmNsZWFyIHRvIG1l IHdoYXQgImxhYmVsIiByZWFsbHkgaXMuIFRoZSBkYXRhIGNoYW5uZWwgZHJhZnQgc2F5cyBpdCdz IGEgIm5hbWUgb2YgdGhlIGNoYW5uZWwiLi4uDQoNCj4gMi4gwqBJZiBhbiBlbmRwb2ludCBlbmRz IHVwIHdpdGggdHdvIGRhdGEgY2hhbm5lbHMgd2l0aCB0aGUgc2FtZSBsYWJlbCwgY2xvc2UgdGhl IG9uZSB3aXRoIHRoZSBoaWdoZXIgLmlkLCBhbmQga2VlcCB0aGUgb25lIHdpdGggdGhlIGxvd2Vy IC5pZC4NCg0KV2hhdCBpcyAiLmlkIj8gSXMgaXQgc29tZXRoaW5nIEFQSSBzcGVjaWZpYz8gS2Vl cCBpbiBtaW5kIHRoYXQgbm9uLVdlYlJUQyBjbGllbnRzIG1heSBhbHNvIHVzZSB0aGUgZGF0YSBj aGFubmVsLg0KDQo+IE5vdyBib3RoIHNpZGVzIHdpbGwgdXNlIHRoZSBzYW1lIGNoYW5uZWwsIGFu ZCB5b3UgY2FuIHByZXRlbmQgbGlrZSB0aGUgb3RoZXIgbmV2ZXIgZXhpc3RlZC4gwqAgSWYgeW91 J3JlIHdvcnJpZWQgYWJvdXQgZGF0YSBzZW50IGJlZm9yZSB0aGlzIHByb2Nlc3MgY29tcGxldGVz LCBlaXRoZXIgYWNjZXB0IGRhdGEgb24gYm90aCBjaGFubmVscyBmb3IgYSB3aGlsZSwgb3IgZG9u J3Qgc2VuZCBkYXRhIHVudGlsIHRoZSBwcm9jZXNzIGNvbXBsZXRlcy4NCj4NCj4gSXMgdGhlcmUg YW55IHJlYXNvbiB0aGlzIHdvdWxkIG5vdCB3b3JrPw0KDQpBc3N1bWluZyBpdCdzIGdlbmVyaWMs IGFuZCBub3QgQVBJIHNwZWNpZmljLCBJIGd1ZXNzIGl0IGNvdWxkIHdvcmsuIA0KDQpBbHNvLCBh cyBoYXMgYmVlbiBpbmRpY2F0ZWQsIHNwZWNpZmljIHByb3RvY29scyBjYW4gc3BlY2lmeSBydWxl cyByZWdhcmRpbmcgd2hvIG9wZW5zIHRoZSBjaGFubmVsLg0KDQpJIHRoaW5rIGl0IHdvdWxkIGJl IGdvb2QgdG8gaGF2ZSBzb21lIGluZm9ybWF0aXZlIGd1aWRhbmNlIHRleHQgYWJvdXQgdGhpcyBz b21ld2hlcmUsIGUuZy4gaW4gdGhlIERhdGEgQ2hhbm5lbCBkcmFmdC4NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KDQoNCg0KDQoNCk9uIE1vbiwgRmViIDEwLCAyMDE0IGF0IDU6MTAgUE0sIFBh dWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PiB3cm90ZToNCllvdSB0d28gZ3V5cyBh cmUgdGFsa2luZyBwYXN0IG9uZSBhbm90aGVyLg0KDQpDaHJpc3RlcidzIHBvaW50IGlzIHRoYXQg dGhlICphcHBsaWNhdGlvbiIgZGlzdHJpYnV0ZWQgYmV0d2VlbiB0aGUgdHdvIGVuZHBvaW50cywg bmVlZHMgYSAqc2luZ2xlKiBpbnN0YW5jZSBvZiBhIGNoYW5uZWwgZm9yIGEgcGFydGljdWxhciBh cHBsaWNhdGlvbiBzcGVjaWZpYyBwdXJwb3NlLiBCdXQgdGhlIHR3byBlbmRzIGFyZSBnZW5lcmFs bHkgc3ltbWV0cmljLiBUaGVyZSBpcyBubyBvYnZpb3VzIGNob2ljZSBvZiB3aGljaCBzaWRlIHNo b3VsZCBjcmVhdGUgdGhlIGNoYW5uZWwuIFNvIGhvdyBkbyB3ZSB1c2UgdGhlIG1lY2hhbmlzbSB0 byBhY2hpZXZlIHRoaXMgcmVzdWx0Pw0KDQpJIHRoaW5rIEkgY2FuIHByZWRpY3Qgd2hhdCBNaWNo YWVsIGlzIGdvaW5nIHRvIHNheTogaXQgaXNuJ3QgYSBwcm90b2NvbCBpc3N1ZSAtIHRoZSB0d28g ZW5kcyBzaG91bGQgbmVnb3RpYXRlIHRoaXMgc29tZSBvdGhlciB3YXkuIChJbiB0aGUgbm9ybWFs IHJ0Y3dlYiBzY2VuYXJpbywgYSAqc2luZ2xlKiBhcHAgaW4gdGhlIG1pZGRsZSBjYW4gYXJyYW5n ZSBmb3Igb25lIHNpZGUgdG8gZG8gdGhlIG9wZW4uKQ0KDQpUaGlzIGlzIGEgcHJvYmxlbSB3aXRo IGEgc2lwIGFwcCAtIHRoZXJlIGlzIG5vIG1pZGRsZSwganVzdCB0d28gZW5kcy4NCg0KDQpQcmV2 aW91c2x5IENocmlzdGVyIHNhaWQ6DQpDb3VsZG7igJl0IHdlIGUuZy4gc2F5IHRoYXQsIGJ5IGRl ZmF1bHQsIHRoZSBEVExTIGNsaWVudCBpcyByZXNwb25zaWJsZSBmb3Igc2VuZGluZyB0aGUgREFU QV9DSEFOTkVMX09QRU4/IFRoZW4gdGhlcmUgaXMgbm8gcmlzayBmb3IgZ2xhcmUsIGFuZCBpdCBj b3VsZCBldmVuIHVzZSBib3RoIGFuIGV2ZW4gb3Igb2RkIHN0cmVhbSBpZCB2YWx1ZS4NCg0KVGhh dCBpcyBhIGJhZCB0aGluZyBmb3IgZGF0YSBjaGFubmVsIGluIGdlbmVyYWwuIEJ1dCBJIHN1cHBv c2UgdGhlIGFwcCBjYW4gY2hvb3NlIHRvIGZvbGxvdyB0aGlzIHJ1bGUgaWYgaXQgd2FudHMgZm9y IHBhcnRpY3VsYXIgY2hhbm5lbHMuDQoNCsKgIMKgIMKgIMKgIFRoYW5rcywNCsKgIMKgIMKgIMKg IFBhdWwNCg0KDQoNCg0KDQoNCk9uIDIvMTAvMTQgMTI6MjkgUE0sIENocmlzdGVyIEhvbG1iZXJn IHdyb3RlOg0KDQpIaSwNCkFzIGlzIGRlZmluZWQgaW4gdGhlIGRhdGEgY2hhbm5lbCBwcm90b2Nv bCwgYW4gZW50aXR5IGNhbiBzZW5kIGRhdGEgb25jZSBEQVRBX0NIQU5ORUxfT1BFTiBoYXMgYmVl biBzZW50LCBiZWZvcmUgdGhlIGFzc29jaWF0ZWQgREFUQV9DSEFOTkVMX0FDSyBpcyByZWNlaXZl ZC4NCg0KVGhlIGRyYWZ0IGFsc28gc2F5cyB0aGF0LCBpZiBib3RoIGVuZHBvaW50cyBzZW5kIERB VEFfQ0hBTk5FTF9PUEVOIGF0IHRoZSBzYW1lIHRpbWUsIHVzaW5nIGRpZmZlcmVudCBzdHJlYW0g aWQgdmFsdWVzLCB0aGUgcmVzdWx0IG1heSBiZSBUV08gZGF0YSBjaGFubmVscywgd2l0aCBkYXRh IHNlbnQgb24gYm90aC4NCg0KSG93ZXZlciwgYXMgaXMgYWxzbyBpbmRpY2F0ZWQsIHRoZSBkcmFm dCBkb2VzIG5vdCBwcm92aWRlIGEgbWVjaGFuaXNtIHRvIHByZXZlbnQvaGFuZGxlIHN1Y2ggZ2xh cmUgc2l0dWF0aW9uLg0KDQpJIHBlcnNvbmFsbHkgdGhpbmsgdGhlcmUgc2hhbGwgYmUgYSB3YXkg dG8gcHJldmVudCBzdWNoIHNpdHVhdGlvbiwgb3Igb3RoZXJ3aXNlIEknbSBzdXJlIHdlIGFyZSBn b2luZyB0byBlbmQgdXAgd2l0aCBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLg0KDQpDb3VsZG4n dCB3ZSBlLmcuIHNheSB0aGF0LCBieSBkZWZhdWx0LCB0aGUgRFRMUyBjbGllbnQgaXMgcmVzcG9u c2libGUgZm9yIHNlbmRpbmcgdGhlIERBVEFfQ0hBTk5FTF9PUEVOPyBUaGVuIHRoZXJlIGlzIG5v IHJpc2sgZm9yIGdsYXJlLCBhbmQgaXQgY291bGQgZXZlbiB1c2UgYm90aCBhbiBldmVuIG9yIG9k ZCBzdHJlYW0gaWQgdmFsdWUuDQpTZWN0aW9uIDQgcmVhZHM6DQoNClRvIGF2b2lkIGdsYXJlIGlu IG9wZW5pbmcgQ2hhbm5lbHMsIGVhY2ggc2lkZSBNVVNUIHVzZSBlaXRoZXIgZXZlbg0Kb3IgwqBv ZGQgU3RyZWFtcyB3aGVuIHNlbmRpbmcgYSBEQVRBX0NIQU5ORUxfT1BFTiBtZXNzYWdlLiDCoFRo ZSBtZXRob2QNCnVzZWQgdG8gZGV0ZXJtaW5lIHdoaWNoIHNpZGUgdXNlcyBvZGQgb3IgZXZlbiBp cyBiYXNlZCBvbiB0aGUNCnVuZGVybHlpbmcgRFRMUyBjb25uZWN0aW9uIHJvbGUgd2hlbiB1c2Vk IGluIFdlYlJUQywgd2l0aCB0aGUgc2lkZQ0KYWN0aW5nIGFzIHRoZSBEVExTIGNsaWVudCB1c2lu ZyBldmVuIHN0cmVhbSBpZGVudGlmaWVycy4NCg0KU28gdGhlcmUgaXMgbm8gcHJvYmxlbSBpbiBz ZXR0aW5nIHVwIGRhdGEgY2hhbm5lbHMuDQoNClRoaXMgc2hvdWxkIG5vdCBiZSBjb25mdXNlZCBi eSBib3RoIHNpZGVzIHNldHRpbmcgdXAgYSBkYXRhIGNoYW5uZWwgd2l0aCB0aGUgc2FtZSBMYWJl bC4gVGhpcyBlbmRzIHVwIGluIHR3byBkYXRhIGNoYW5uZWxzIHdpdGggdGhlIHNhbWUgbGFiZWwu DQpZb3UgY2FuIGV2ZW4gY3JlYXRlIG1vcmUgZGF0YSBjaGFubmVscyB3aXRoIHRoZSBzYW1lIGxh YmVsLg0KDQpNeSBwb2ludCBpcyB0aGF0IEkgZG9uJ3Qgd2FudCB0byBlbmQgdXAgd2l0aCBtb3Jl IHRoYW4gb25lIGNoYW5uZWwuDQpBbmQgeW91IHdvbid0LCBzZWUgYWJvdmUuDQoNCkkgYW0gbm90 IHN1cmUgSSB1bmRlcnN0YW5kLiBXaGF0IHRleHQgZG8geW91IHJlZmVyIHRvPw0KVG8gYXZvaWQg Z2xhcmUgaW4gb3BlbmluZyBDaGFubmVscywgZWFjaCBzaWRlIE1VU1QgdXNlIGVpdGhlciBldmVu DQpvciDCoG9kZCBTdHJlYW1zIHdoZW4gc2VuZGluZyBhIERBVEFfQ0hBTk5FTF9PUEVOIG1lc3Nh Z2UuIMKgVGhlIG1ldGhvZA0KdXNlZCB0byBkZXRlcm1pbmUgd2hpY2ggc2lkZSB1c2VzIG9kZCBv ciBldmVuIGlzIGJhc2VkIG9uIHRoZQ0KdW5kZXJseWluZyBEVExTIGNvbm5lY3Rpb24gcm9sZSB3 aGVuIHVzZWQgaW4gV2ViUlRDLCB3aXRoIHRoZSBzaWRlDQphY3RpbmcgYXMgdGhlIERUTFMgY2xp ZW50IHVzaW5nIGV2ZW4gc3RyZWFtIGlkZW50aWZpZXJzLg0KDQpUaGF0IHBhcnQgSSB1bmRlcnN0 YW5kLg0KDQpCdXQsIHRoaXMgbWVhbnMgdGhhdCBib3RoIGVuZHBvaW50cyBtYXkgc2VuZCBEQVRB X0NIQU5ORUxfT1BFTiwgZm9yIHRoZSBzYW1lIHByb3RvY29sLCBhbmQgVEhBVCBpcyB3aGF0IEkg d291bGQgbGlrZSB0byBhdm9pZC4gSSBkb24ndCB3YW50IHRvIGhhdmUgdHdvIGJpLWRpcmVjdGlv bmFsIGRhdGEgY2hhbm5lbHMgZm9yIHRoZSBzYW1lIHRoaW5nLg0KDQpGb3IgdGhhdCByZWFzb24g SSBzdWdnZXN0ZWQgdGhhdCB3ZSBjb3VsZCBhbHNvIHNwZWNpZnkgd2hpY2ggZW5kcG9pbnQgaXMg cmVzcG9uc2lzYmxlIGZvciBzZW5kaW5nIERBVEFfQ0hBTk5FTF9PUEVOLg0KDQpIb3dldmVyLCB0 aGVyZSBpcyBubyBtZWNoYW5pc20gdG8gZW5zdXJlIHVuaXF1ZW5lc3MgZm9yIGxhYmVscy4gVGhl IFdlYlJUQyBBUEkgYWxyZWFkeSBhbGxvd3Mgb25lIHNpZGUgdG8gY3JlYXRlIG4gZGF0YSBjaGFu bmVscyB3aXRoIHRoZSBzYW1lIGxhYmVsLg0KDQpJIGFtIG5vdCBzYXlpbmcgaXQgc2hvdWxkIGJl IGZvcmJpZGRlbiB0byBkbyBzby4gQnV0LCBmb3IgcHJvdG9jb2wgWCwgSSB3YW50IHRvIGVuZCB1 cCB3aXRoIE9ORSBkYXRhIGNoYW5uZWwgYmV0d2VlbiBteSBwZWVycy4NClRoZW4gb25seSBvbmUg c2lkZSBzaG91bGQgY3JlYXRlIGEgZGF0YSBjaGFubmVsLg0KDQpJZiBJIGVuZCB1cCB3aXRoIHR3 byBkYXRhIGNoYW5uZWxzIGZvciBwcm90b2NvbCBYLCBjYW4gSSBzZW5kIGRhdGEgb24gd2hpY2hl dmVyIEkgd2FudCB0bz8NClN1cmUuIFRoZXNlIHdvdWxkIGJlIHR3byBpbmRlcGVuZGVudCBiaWRp cmVjdGlvbmFsIGRhdGEgY2hhbm5lbHMuDQoNClBvc3NpYmxlIGZvciB0aGUgc2FtZSBwcm90b2Nv bCAtIGFuZCB0aGF0IGlzIHdoYXQgSSB3b3VsZCB3YW50IHRvIGF2b2lkLiBJIHdhbnQgdG8gc2Vu ZCBteSBwcm90b2NvbCBYIG1lc3NhZ2VzIG9uIG9uZSBkYXRhIGNoYW5uZWwsIGFuZCBJIHdvdWxk IGxpa2UgdG8gcmVjZWl2ZSB0aGUgcHJvdG9jb2wgWCBtZXNzYWdlcyBmcm9tIG15IHBlZXIgb24g dGhlIHNhbWUgZGF0YSBjaGFubmVsLg0KDQpOb3csIG9uZSBjYW4gb2YgY291cnNlIHNvbHZlIHRo aXMgYnkgcmVzZXRpbmcgb25lIG9mIHRoZSBkYXRhIGNoYW5uZWxzLCBidXQgdGhlbiB0aGUgcXVl c3Rpb24gaXMgd2hpY2ggZW5kcG9pbnQgc2hvdWxkIHJlc2V0IDopDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== From pthatcher@google.com Tue Feb 11 10:33: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 A104B1A06E0 for ; Tue, 11 Feb 2014 10:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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, RP_MATCHES_RCVD=-0.548, 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 RO2VAgDV5oKb for ; Tue, 11 Feb 2014 10:33:22 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 19D471A06F2 for ; Tue, 11 Feb 2014 10:33:22 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id lj1so7982249pab.26 for ; Tue, 11 Feb 2014 10:33:21 -0800 (PST) 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=2KFnnASy5wCtVHyIwBKmrBLg+sMnr5SfpcKip9evhyg=; b=k19ur++HmJMwT50Octp4l94t+TjopE3RC8DBiEY0TXSIMRC9hb+1UVe+FJwMjhGWtF k2yT+sz4siap47zn1TmUJYzKz7Es7dscPwylaFDDElkw8+Xm1tG/ZNwBcCKa2VHvzz0/ nKmQ+bolvJJkh1yaJs/g7baxUl+Zg7AADmwOBkmSkDZf65wmlvBXP1evZCng+pRCWiLP 0z5K8dle7UUgPE8tHw3YQzEYV7kjxKrsYTDCe/ZR6lrvX9XxwF4U8aWgKgDgZLHKrk9o T6pPwwMKWqBbqGamjc76IQ0YQZ5CxX6k4+Q5pq+mDMyxlms0oKaxKufcJYVAuAMqD3GT 7d+w== 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=2KFnnASy5wCtVHyIwBKmrBLg+sMnr5SfpcKip9evhyg=; b=O/IG11sQJZ1wk35vCzGNZnB5YiGQCu9lbjlYbSY0jycNQotgX502P8rvRqJO0p9OX0 m4lyJtogpXYSOdRKL++HhXNq+uoI7zzrp8cIv5m4l2JjrPa5o7o47EzrNlAfDNktd3qN V9BtT2IFmEnwd47rP/jH5iNovMMxb3IlD4Kev2gB/VhRefc304orVC/r1mR6B0qSTroA mWvSN3VshCl/vpO8KheTMOVCCXDPyy1dSr8e8l3UA1E/YKFq4lsWg9Tazni1avzniRiv hvqgzNhrR65ZFf7Bqq1MKNtZzOI/pRuWTgs+LdkemF4D67x4T/UClKOgvvGfyMJHGybG RjTg== X-Gm-Message-State: ALoCoQk6ZFJt0iXpD6JMY1wgaksy8EdjeM17t8Gp/lGadFRb4KnhOEKU7L0HW5KFv+dSiYk1Uk8hmmxbKP1EcPA/vGEfRSTfuQsPZDep2iV3qCHmTPPOb18htD2nUkIiU7WiOuObWje6vdZaLpwbXY/w1waT/oMDGjZHAT78KkVQeIwOxw0ivgvt6UizQ82G3Stg8fS1Cm9t X-Received: by 10.68.203.225 with SMTP id kt1mr41688470pbc.130.1392143601505; Tue, 11 Feb 2014 10:33:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.163.234 with HTTP; Tue, 11 Feb 2014 10:32:41 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D16D2F3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se> <4616BFFA-F461-4CE8-9D85-211B86D4BE93@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166D7B@ESESSMB209.ericsson.se> <71288EED-3C82-44A7-950B-EFEFA62616E6@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166F8C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167A2E@ESESSMB209.ericsson.se> <52F9786F.60809@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D16D2F3@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Tue, 11 Feb 2014 10:32:41 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b15a811d840f204f225b0a7 Cc: "" Subject: Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 18:33:26 -0000 --047d7b15a811d840f204f225b0a7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 11, 2014 at 10:22 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Peter, > > > I believe the API already gives you all the tools you need for this use > case. Here's one way to create a data channel where both ends call > createDataChannel() at the same time, with no "middle": > > > > 1. Both sides call createDataChannel() with the same label. > > Or, with the same Protocol. > > It is a little unclear to me what "label" really is. The data channel > draft says it's a "name of the channel"... > =E2=80=8BLabel is whatever the JS or native app chooses it to be.=E2=80=8B= You can give it whatever semantics you want. > > > 2. If an endpoint ends up with two data channels with the same label, > close the one with the higher .id, and keep the one with the lower .id. > > What is ".id"? Is it something API specific? Keep in mind that non-WebRTC > clients may also use the data channel. > > In=E2=80=8B =E2=80=8B =E2=80=8B JS, it's this: http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCDataChannel-id =E2=80=8BOn the wire, it's the SCTP SID.=E2=80=8B =E2=80=8B > Now both sides will use the same channel, and you can pretend like the other never existed. If you're worried about data sent before this process completes, either accept data on both channels for a while, or don't send data until the process completes. > > > > Is there any reason this would not work? > > Assuming it's generic, and not API specific, I guess it could work. > > =E2=80=8B=E2=80=8B =E2=80=8BYes, it's generic. The logic is basically, "if you end up with tw= o SIDs with the same label, close the channel with the higher SID". Applies to any endpoint.=E2=80=8B > Also, as has been indicated, specific protocols can specify rules > regarding who opens the channel. > > I think it would be good to have some informative guidance text about thi= s > somewhere, e.g. in the Data Channel draft. > > Regards, > > Christer > > > > > > > On Mon, Feb 10, 2014 at 5:10 PM, Paul Kyzivat > wrote: > You two guys are talking past one another. > > Christer's point is that the *application" distributed between the two > endpoints, needs a *single* instance of a channel for a particular > application specific purpose. But the two ends are generally symmetric. > There is no obvious choice of which side should create the channel. So ho= w > do we use the mechanism to achieve this result? > > I think I can predict what Michael is going to say: it isn't a protocol > issue - the two ends should negotiate this some other way. (In the normal > rtcweb scenario, a *single* app in the middle can arrange for one side to > do the open.) > > This is a problem with a sip app - there is no middle, just two ends. > > > Previously Christer said: > Couldn=E2=80=99t we e.g. say that, by default, the DTLS client is respons= ible for > sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it > could even use both an even or odd stream id value. > > That is a bad thing for data channel in general. But I suppose the app ca= n > choose to follow this rule if it wants for particular channels. > > Thanks, > Paul > > > > > > > On 2/10/14 12:29 PM, Christer Holmberg wrote: > > Hi, > As is defined in the data channel protocol, an entity can send data once > DATA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK i= s > received. > > The draft also says that, if both endpoints send DATA_CHANNEL_OPEN at the > same time, using different stream id values, the result may be TWO data > channels, with data sent on both. > > However, as is also indicated, the draft does not provide a mechanism to > prevent/handle such glare situation. > > I personally think there shall be a way to prevent such situation, or > otherwise I'm sure we are going to end up with interoperability problems. > > Couldn't we e.g. say that, by default, the DTLS client is responsible for > sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it > could even use both an even or odd stream id value. > Section 4 reads: > > To avoid glare in opening Channels, each side MUST use either even > or odd Streams when sending a DATA_CHANNEL_OPEN message. The method > used to determine which side uses odd or even is based on the > underlying DTLS connection role when used in WebRTC, with the side > acting as the DTLS client using even stream identifiers. > > So there is no problem in setting up data channels. > > This should not be confused by both sides setting up a data channel with > the same Label. This ends up in two data channels with the same label. > You can even create more data channels with the same label. > > My point is that I don't want to end up with more than one channel. > And you won't, see above. > > I am not sure I understand. What text do you refer to? > To avoid glare in opening Channels, each side MUST use either even > or odd Streams when sending a DATA_CHANNEL_OPEN message. The method > used to determine which side uses odd or even is based on the > underlying DTLS connection role when used in WebRTC, with the side > acting as the DTLS client using even stream identifiers. > > That part I understand. > > But, this means that both endpoints may send DATA_CHANNEL_OPEN, for the > same protocol, and THAT is what I would like to avoid. I don't want to ha= ve > two bi-directional data channels for the same thing. > > For that reason I suggested that we could also specify which endpoint is > responsisble for sending DATA_CHANNEL_OPEN. > > However, there is no mechanism to ensure uniqueness for labels. The WebRT= C > API already allows one side to create n data channels with the same label= . > > I am not saying it should be forbidden to do so. But, for protocol X, I > want to end up with ONE data channel between my peers. > Then only one side should create a data channel. > > If I end up with two data channels for protocol X, can I send data on > whichever I want to? > Sure. These would be two independent bidirectional data channels. > > Possible for the same protocol - and that is what I would want to avoid. = I > want to send my protocol X messages on one data channel, and I would like > to receive the protocol X messages from my peer on the same data channel. > > Now, one can of course solve this by reseting one of the data channels, > but then the question is which endpoint should reset :) > > 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 > > --047d7b15a811d840f204f225b0a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Feb 11, 2014 at 10:22 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi Peter,

> I believe the API already gives you all the tools you need for this us= e case. =C2=A0Here's one way to create a data channel where both ends c= all createDataChannel() at the same time, with no "middle":
>
> 1. =C2=A0Both sides call createDataChannel() with the same label.

Or, with the same Protocol.

It is a little unclear to me what "label" really is. The data cha= nnel draft says it's a "name of the channel"...

=E2=80=8BLabel is whatever the JS =C2=A0or native app chooses it to be.=E2= =80=8B =C2=A0You can give it whatever semantics you want.
= =C2=A0

> 2. =C2=A0If an endpoint ends up with two data channels with the same l= abel, close the one with the higher .id, and keep the one with the lower .i= d.

What is ".id"? Is it something API specific? Keep in mind t= hat non-WebRTC clients may also use the data channel.


=
In=E2=80=8B
=E2=80=8B=E2=80=8B JS, it's this:=C2=A0
http://dev.w3.org/2011/webrtc/editor/webrtc.html#wi= dl-RTCDataChannel-id

<= span style=3D"font-family:verdana,sans-serif">
=E2=80=8BOn the wir= e, it's the SCTP SID.=E2=80=8B
=E2=80=8B

=C2=A0> Now both sides will us= e the same channel, and you can pretend like the other never existed. =C2= =A0 If you're worried about data sent before this process completes, ei= ther accept data on both channels for a while, or don't send data until= the process completes.
>
> Is there any reason this would not work?

Assuming it's generic, and not API specific, I guess it could wor= k.


=E2=80=8B=E2=80=8B
=E2=80=8BYes, it's gener= ic. =C2=A0The logic is basically, "if you end up with two SIDs with th= e same label, close the channel with the higher SID". =C2=A0Applies to= any endpoint.=E2=80=8B

=C2=A0
Also, as has been indicated, sp= ecific protocols can specify rules regarding who opens the channel.

I think it would be good to have some informative guidance text about this = somewhere, e.g. in the Data Channel draft.

Regards,

Christer






On Mon, Feb 10, 2014 at 5:10 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
You two guys are talking past one another.

Christer's point is that the *application" distributed between the= two endpoints, needs a *single* instance of a channel for a particular app= lication specific purpose. But the two ends are generally symmetric. There = is no obvious choice of which side should create the channel. So how do we = use the mechanism to achieve this result?

I think I can predict what Michael is going to say: it isn't a protocol= issue - the two ends should negotiate this some other way. (In the normal = rtcweb scenario, a *single* app in the middle can arrange for one side to d= o the open.)

This is a problem with a sip app - there is no middle, just two ends.


Previously Christer said:
Couldn=E2=80=99t we e.g. say that, by default, the DTLS client is responsib= le for sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and = it could even use both an even or odd stream id value.

That is a bad thing for data channel in general. But I suppose the app can = choose to follow this rule if it wants for particular channels.

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






On 2/10/14 12:29 PM, Christer Holmberg wrote:

Hi,
As is defined in the data channel protocol, an entity can send data once DA= TA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK is re= ceived.

The draft also says that, if both endpoints send DATA_CHANNEL_OPEN at the s= ame time, using different stream id values, the result may be TWO data chan= nels, with data sent on both.

However, as is also indicated, the draft does not provide a mechanism to pr= event/handle such glare situation.

I personally think there shall be a way to prevent such situation, or other= wise I'm sure we are going to end up with interoperability problems.
Couldn't we e.g. say that, by default, the DTLS client is responsible f= or sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it c= ould even use both an even or odd stream id value.
Section 4 reads:

To avoid glare in opening Channels, each side MUST use either even
or =C2=A0odd Streams when sending a DATA_CHANNEL_OPEN message. =C2=A0The me= thod
used to determine which side uses odd or even is based on the
underlying DTLS connection role when used in WebRTC, with the side
acting as the DTLS client using even stream identifiers.

So there is no problem in setting up data channels.

This should not be confused by both sides setting up a data channel with th= e same Label. This ends up in two data channels with the same label.
You can even create more data channels with the same label.

My point is that I don't want to end up with more than one channel.
And you won't, see above.

I am not sure I understand. What text do you refer to?
To avoid glare in opening Channels, each side MUST use either even
or =C2=A0odd Streams when sending a DATA_CHANNEL_OPEN message. =C2=A0The me= thod
used to determine which side uses odd or even is based on the
underlying DTLS connection role when used in WebRTC, with the side
acting as the DTLS client using even stream identifiers.

That part I understand.

But, this means that both endpoints may send DATA_CHANNEL_OPEN, for the sam= e protocol, and THAT is what I would like to avoid. I don't want to hav= e two bi-directional data channels for the same thing.

For that reason I suggested that we could also specify which endpoint is re= sponsisble for sending DATA_CHANNEL_OPEN.

However, there is no mechanism to ensure uniqueness for labels. The WebRTC = API already allows one side to create n data channels with the same label.<= br>
I am not saying it should be forbidden to do so. But, for protocol X, I wan= t to end up with ONE data channel between my peers.
Then only one side should create a data channel.

If I end up with two data channels for protocol X, can I send data on which= ever I want to?
Sure. These would be two independent bidirectional data channels.

Possible for the same protocol - and that is what I would want to avoid. I = want to send my protocol X messages on one data channel, and I would like t= o receive the protocol X messages from my peer on the same data channel.
Now, one can of course solve this by reseting one of the data channels, but= then the question is which endpoint should reset :)

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


--047d7b15a811d840f204f225b0a7-- From christer.holmberg@ericsson.com Tue Feb 11 11:00: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 959CD1A06E1 for ; Tue, 11 Feb 2014 11:00:57 -0800 (PST) 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, 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 Cnokazo3HpFM for ; Tue, 11 Feb 2014 11:00:53 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 89AA41A067E for ; Tue, 11 Feb 2014 11:00:52 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-78-52fa7362cb45 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 8A.65.04249.2637AF25; Tue, 11 Feb 2014 20:00:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 20:00:50 +0100 From: Christer Holmberg To: 'Peter Thatcher' Thread-Topic: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare Thread-Index: Ac8mR2/m3LFj8oi+SFKLxbYiytu9PP//8tkA///uSjCAABcpAP//4ZBAgACIq4CAABjmc4AAcPCAgAEb3ID//+u2AAADdxiA///no4A= Date: Tue, 11 Feb 2014 19:00:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16D3C2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se> <4616BFFA-F461-4CE8-9D85-211B86D4BE93@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166D7B@ESESSMB209.ericsson.se> <71288EED-3C82-44A7-950B-EFEFA62616E6@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166F8C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167A2E@ESESSMB209.ericsson.se> <52F9786F.60809@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D16D2F3@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_7594FB04B1934943A5C02806D1A2204B1D16D3C2ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW5y8a8gg+eLeSxWbDjAanFt+WtW i7X/2tkdmD3+vv/A5LFgU6nHkiU/mQKYo7hsUlJzMstSi/TtErgyOq57Fzz7yVixb/sslgbG OZ8Zuxg5OSQETCS2nutlhrDFJC7cW8/WxcjFISRwhFFi9dtp7BDOYkaJxs5nQB0cHGwCFhLd /7RBGkQEtCUurpvIDmIzCwRKfDo2B8wWFvCRWHZgHzNEja/EtUvz2EBaRQTKJOb+lAcJswio Slyc1MQCYvMClbz985kVYtUeVokpjw+AreIEmrllN1gNI9Bt30+tYYJYJS5x68l8JoibBSSW 7DkPdb+oxMvH/1ghbCWJHxsusUDU50vsfHCXEWKXoMTJmU9YJjCKzkIyahaSsllIymYBXcEs oCmxfpc+RImixJTuh+wQtoZE65y57MjiCxjZVzFyFKcWJ+WmGxlsYgRG2cEtvy12MF7+a3OI UZqDRUmc9+Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjEsVl8yfFTyH7Xp2dXTG8X2C dSYzzvlus9K6FKFkOTPq4FKuN2+6JmkuSzl7ca6fhotf/Nw3tVs27K6b4fluTfp/D93Pa5VC NhTYJ2j9YOba6XH6VQ3nVPEH67au2rfqf1sJ74OoM7ERJRK9h2dbTjoif+b6gfP3Ol9/mfOs /DW/wVTlev8lD+uVWIozEg21mIuKEwGu2pmkgAIAAA== Cc: "" Subject: Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 19:00:57 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D16D3C2ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGV0ZXIsDQoNClRoYW5rcyBmb3IgeW91ciBpbnB1dC4gSSB3YXMgdXNlZnVsIOKYug0KDQpB bmQsICBhZ2FpbiwgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGFkZCBzb21lIGd1aWRhbmNl IHRvIHRoZSBkYXRhIGNoYW5uZWwgZHJhZnQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZy b206IFBldGVyIFRoYXRjaGVyIFttYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb21dDQpTZW50OiBU dWVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNCA3OjMzIFBNDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcN CkNjOiBQYXVsIEt5eml2YXQ7IDxydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dl Yl0gRGF0YSBDaGFubmVsIFByb3RvY29sOiBQcmV2ZW50IERBVEFfQ0hBTk5FTF9PUEVOIGdsYXJl DQoNCg0KDQpPbiBUdWUsIEZlYiAxMSwgMjAxNCBhdCAxMDoyMiBBTSwgQ2hyaXN0ZXIgSG9sbWJl cmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSBQZXRlciwNCg0KPiBJIGJlbGlldmUgdGhlIEFQ SSBhbHJlYWR5IGdpdmVzIHlvdSBhbGwgdGhlIHRvb2xzIHlvdSBuZWVkIGZvciB0aGlzIHVzZSBj YXNlLiAgSGVyZSdzIG9uZSB3YXkgdG8gY3JlYXRlIGEgZGF0YSBjaGFubmVsIHdoZXJlIGJvdGgg ZW5kcyBjYWxsIGNyZWF0ZURhdGFDaGFubmVsKCkgYXQgdGhlIHNhbWUgdGltZSwgd2l0aCBubyAi bWlkZGxlIjoNCj4NCj4gMS4gIEJvdGggc2lkZXMgY2FsbCBjcmVhdGVEYXRhQ2hhbm5lbCgpIHdp dGggdGhlIHNhbWUgbGFiZWwuDQpPciwgd2l0aCB0aGUgc2FtZSBQcm90b2NvbC4NCg0KSXQgaXMg YSBsaXR0bGUgdW5jbGVhciB0byBtZSB3aGF0ICJsYWJlbCIgcmVhbGx5IGlzLiBUaGUgZGF0YSBj aGFubmVsIGRyYWZ0IHNheXMgaXQncyBhICJuYW1lIG9mIHRoZSBjaGFubmVsIi4uLg0KDQrigItM YWJlbCBpcyB3aGF0ZXZlciB0aGUgSlMgIG9yIG5hdGl2ZSBhcHAgY2hvb3NlcyBpdCB0byBiZS7i gIsgIFlvdSBjYW4gZ2l2ZSBpdCB3aGF0ZXZlciBzZW1hbnRpY3MgeW91IHdhbnQuDQoNCg0KPiAy LiAgSWYgYW4gZW5kcG9pbnQgZW5kcyB1cCB3aXRoIHR3byBkYXRhIGNoYW5uZWxzIHdpdGggdGhl IHNhbWUgbGFiZWwsIGNsb3NlIHRoZSBvbmUgd2l0aCB0aGUgaGlnaGVyIC5pZCwgYW5kIGtlZXAg dGhlIG9uZSB3aXRoIHRoZSBsb3dlciAuaWQuDQpXaGF0IGlzICIuaWQiPyBJcyBpdCBzb21ldGhp bmcgQVBJIHNwZWNpZmljPyBLZWVwIGluIG1pbmQgdGhhdCBub24tV2ViUlRDIGNsaWVudHMgbWF5 IGFsc28gdXNlIHRoZSBkYXRhIGNoYW5uZWwuDQoNCg0KSW7igIsNCuKAiw0K4oCLIEpTLCBpdCdz IHRoaXM6DQpodHRwOi8vZGV2LnczLm9yZy8yMDExL3dlYnJ0Yy9lZGl0b3Ivd2VicnRjLmh0bWwj d2lkbC1SVENEYXRhQ2hhbm5lbC1pZA0KDQrigItPbiB0aGUgd2lyZSwgaXQncyB0aGUgU0NUUCBT SUQu4oCLDQrigIsNCg0KID4gTm93IGJvdGggc2lkZXMgd2lsbCB1c2UgdGhlIHNhbWUgY2hhbm5l bCwgYW5kIHlvdSBjYW4gcHJldGVuZCBsaWtlIHRoZSBvdGhlciBuZXZlciBleGlzdGVkLiAgIElm IHlvdSdyZSB3b3JyaWVkIGFib3V0IGRhdGEgc2VudCBiZWZvcmUgdGhpcyBwcm9jZXNzIGNvbXBs ZXRlcywgZWl0aGVyIGFjY2VwdCBkYXRhIG9uIGJvdGggY2hhbm5lbHMgZm9yIGEgd2hpbGUsIG9y IGRvbid0IHNlbmQgZGF0YSB1bnRpbCB0aGUgcHJvY2VzcyBjb21wbGV0ZXMuDQo+DQo+IElzIHRo ZXJlIGFueSByZWFzb24gdGhpcyB3b3VsZCBub3Qgd29yaz8NCkFzc3VtaW5nIGl0J3MgZ2VuZXJp YywgYW5kIG5vdCBBUEkgc3BlY2lmaWMsIEkgZ3Vlc3MgaXQgY291bGQgd29yay4NCg0K4oCL4oCL DQrigItZZXMsIGl0J3MgZ2VuZXJpYy4gIFRoZSBsb2dpYyBpcyBiYXNpY2FsbHksICJpZiB5b3Ug ZW5kIHVwIHdpdGggdHdvIFNJRHMgd2l0aCB0aGUgc2FtZSBsYWJlbCwgY2xvc2UgdGhlIGNoYW5u ZWwgd2l0aCB0aGUgaGlnaGVyIFNJRCIuICBBcHBsaWVzIHRvIGFueSBlbmRwb2ludC7igIsNCg0K DQpBbHNvLCBhcyBoYXMgYmVlbiBpbmRpY2F0ZWQsIHNwZWNpZmljIHByb3RvY29scyBjYW4gc3Bl Y2lmeSBydWxlcyByZWdhcmRpbmcgd2hvIG9wZW5zIHRoZSBjaGFubmVsLg0KDQpJIHRoaW5rIGl0 IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBzb21lIGluZm9ybWF0aXZlIGd1aWRhbmNlIHRleHQgYWJv dXQgdGhpcyBzb21ld2hlcmUsIGUuZy4gaW4gdGhlIERhdGEgQ2hhbm5lbCBkcmFmdC4NClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0KDQpPbiBNb24sIEZlYiAxMCwgMjAxNCBhdCA1OjEw IFBNLCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdTxtYWlsdG86cGt5eml2YXRA YWx1bS5taXQuZWR1Pj4gd3JvdGU6DQpZb3UgdHdvIGd1eXMgYXJlIHRhbGtpbmcgcGFzdCBvbmUg YW5vdGhlci4NCg0KQ2hyaXN0ZXIncyBwb2ludCBpcyB0aGF0IHRoZSAqYXBwbGljYXRpb24iIGRp c3RyaWJ1dGVkIGJldHdlZW4gdGhlIHR3byBlbmRwb2ludHMsIG5lZWRzIGEgKnNpbmdsZSogaW5z dGFuY2Ugb2YgYSBjaGFubmVsIGZvciBhIHBhcnRpY3VsYXIgYXBwbGljYXRpb24gc3BlY2lmaWMg cHVycG9zZS4gQnV0IHRoZSB0d28gZW5kcyBhcmUgZ2VuZXJhbGx5IHN5bW1ldHJpYy4gVGhlcmUg aXMgbm8gb2J2aW91cyBjaG9pY2Ugb2Ygd2hpY2ggc2lkZSBzaG91bGQgY3JlYXRlIHRoZSBjaGFu bmVsLiBTbyBob3cgZG8gd2UgdXNlIHRoZSBtZWNoYW5pc20gdG8gYWNoaWV2ZSB0aGlzIHJlc3Vs dD8NCg0KSSB0aGluayBJIGNhbiBwcmVkaWN0IHdoYXQgTWljaGFlbCBpcyBnb2luZyB0byBzYXk6 IGl0IGlzbid0IGEgcHJvdG9jb2wgaXNzdWUgLSB0aGUgdHdvIGVuZHMgc2hvdWxkIG5lZ290aWF0 ZSB0aGlzIHNvbWUgb3RoZXIgd2F5LiAoSW4gdGhlIG5vcm1hbCBydGN3ZWIgc2NlbmFyaW8sIGEg KnNpbmdsZSogYXBwIGluIHRoZSBtaWRkbGUgY2FuIGFycmFuZ2UgZm9yIG9uZSBzaWRlIHRvIGRv IHRoZSBvcGVuLikNCg0KVGhpcyBpcyBhIHByb2JsZW0gd2l0aCBhIHNpcCBhcHAgLSB0aGVyZSBp cyBubyBtaWRkbGUsIGp1c3QgdHdvIGVuZHMuDQoNCg0KUHJldmlvdXNseSBDaHJpc3RlciBzYWlk Og0KQ291bGRu4oCZdCB3ZSBlLmcuIHNheSB0aGF0LCBieSBkZWZhdWx0LCB0aGUgRFRMUyBjbGll bnQgaXMgcmVzcG9uc2libGUgZm9yIHNlbmRpbmcgdGhlIERBVEFfQ0hBTk5FTF9PUEVOPyBUaGVu IHRoZXJlIGlzIG5vIHJpc2sgZm9yIGdsYXJlLCBhbmQgaXQgY291bGQgZXZlbiB1c2UgYm90aCBh biBldmVuIG9yIG9kZCBzdHJlYW0gaWQgdmFsdWUuDQoNClRoYXQgaXMgYSBiYWQgdGhpbmcgZm9y IGRhdGEgY2hhbm5lbCBpbiBnZW5lcmFsLiBCdXQgSSBzdXBwb3NlIHRoZSBhcHAgY2FuIGNob29z ZSB0byBmb2xsb3cgdGhpcyBydWxlIGlmIGl0IHdhbnRzIGZvciBwYXJ0aWN1bGFyIGNoYW5uZWxz Lg0KDQogICAgICAgIFRoYW5rcywNCiAgICAgICAgUGF1bA0KDQoNCg0KDQoNCg0KT24gMi8xMC8x NCAxMjoyOSBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQoNCkhpLA0KQXMgaXMgZGVmaW5l ZCBpbiB0aGUgZGF0YSBjaGFubmVsIHByb3RvY29sLCBhbiBlbnRpdHkgY2FuIHNlbmQgZGF0YSBv bmNlIERBVEFfQ0hBTk5FTF9PUEVOIGhhcyBiZWVuIHNlbnQsIGJlZm9yZSB0aGUgYXNzb2NpYXRl ZCBEQVRBX0NIQU5ORUxfQUNLIGlzIHJlY2VpdmVkLg0KDQpUaGUgZHJhZnQgYWxzbyBzYXlzIHRo YXQsIGlmIGJvdGggZW5kcG9pbnRzIHNlbmQgREFUQV9DSEFOTkVMX09QRU4gYXQgdGhlIHNhbWUg dGltZSwgdXNpbmcgZGlmZmVyZW50IHN0cmVhbSBpZCB2YWx1ZXMsIHRoZSByZXN1bHQgbWF5IGJl IFRXTyBkYXRhIGNoYW5uZWxzLCB3aXRoIGRhdGEgc2VudCBvbiBib3RoLg0KDQpIb3dldmVyLCBh cyBpcyBhbHNvIGluZGljYXRlZCwgdGhlIGRyYWZ0IGRvZXMgbm90IHByb3ZpZGUgYSBtZWNoYW5p c20gdG8gcHJldmVudC9oYW5kbGUgc3VjaCBnbGFyZSBzaXR1YXRpb24uDQoNCkkgcGVyc29uYWxs eSB0aGluayB0aGVyZSBzaGFsbCBiZSBhIHdheSB0byBwcmV2ZW50IHN1Y2ggc2l0dWF0aW9uLCBv ciBvdGhlcndpc2UgSSdtIHN1cmUgd2UgYXJlIGdvaW5nIHRvIGVuZCB1cCB3aXRoIGludGVyb3Bl cmFiaWxpdHkgcHJvYmxlbXMuDQoNCkNvdWxkbid0IHdlIGUuZy4gc2F5IHRoYXQsIGJ5IGRlZmF1 bHQsIHRoZSBEVExTIGNsaWVudCBpcyByZXNwb25zaWJsZSBmb3Igc2VuZGluZyB0aGUgREFUQV9D SEFOTkVMX09QRU4/IFRoZW4gdGhlcmUgaXMgbm8gcmlzayBmb3IgZ2xhcmUsIGFuZCBpdCBjb3Vs ZCBldmVuIHVzZSBib3RoIGFuIGV2ZW4gb3Igb2RkIHN0cmVhbSBpZCB2YWx1ZS4NClNlY3Rpb24g NCByZWFkczoNCg0KVG8gYXZvaWQgZ2xhcmUgaW4gb3BlbmluZyBDaGFubmVscywgZWFjaCBzaWRl IE1VU1QgdXNlIGVpdGhlciBldmVuDQpvciAgb2RkIFN0cmVhbXMgd2hlbiBzZW5kaW5nIGEgREFU QV9DSEFOTkVMX09QRU4gbWVzc2FnZS4gIFRoZSBtZXRob2QNCnVzZWQgdG8gZGV0ZXJtaW5lIHdo aWNoIHNpZGUgdXNlcyBvZGQgb3IgZXZlbiBpcyBiYXNlZCBvbiB0aGUNCnVuZGVybHlpbmcgRFRM UyBjb25uZWN0aW9uIHJvbGUgd2hlbiB1c2VkIGluIFdlYlJUQywgd2l0aCB0aGUgc2lkZQ0KYWN0 aW5nIGFzIHRoZSBEVExTIGNsaWVudCB1c2luZyBldmVuIHN0cmVhbSBpZGVudGlmaWVycy4NCg0K U28gdGhlcmUgaXMgbm8gcHJvYmxlbSBpbiBzZXR0aW5nIHVwIGRhdGEgY2hhbm5lbHMuDQoNClRo aXMgc2hvdWxkIG5vdCBiZSBjb25mdXNlZCBieSBib3RoIHNpZGVzIHNldHRpbmcgdXAgYSBkYXRh IGNoYW5uZWwgd2l0aCB0aGUgc2FtZSBMYWJlbC4gVGhpcyBlbmRzIHVwIGluIHR3byBkYXRhIGNo YW5uZWxzIHdpdGggdGhlIHNhbWUgbGFiZWwuDQpZb3UgY2FuIGV2ZW4gY3JlYXRlIG1vcmUgZGF0 YSBjaGFubmVscyB3aXRoIHRoZSBzYW1lIGxhYmVsLg0KDQpNeSBwb2ludCBpcyB0aGF0IEkgZG9u J3Qgd2FudCB0byBlbmQgdXAgd2l0aCBtb3JlIHRoYW4gb25lIGNoYW5uZWwuDQpBbmQgeW91IHdv bid0LCBzZWUgYWJvdmUuDQoNCkkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kLiBXaGF0IHRleHQg ZG8geW91IHJlZmVyIHRvPw0KVG8gYXZvaWQgZ2xhcmUgaW4gb3BlbmluZyBDaGFubmVscywgZWFj aCBzaWRlIE1VU1QgdXNlIGVpdGhlciBldmVuDQpvciAgb2RkIFN0cmVhbXMgd2hlbiBzZW5kaW5n IGEgREFUQV9DSEFOTkVMX09QRU4gbWVzc2FnZS4gIFRoZSBtZXRob2QNCnVzZWQgdG8gZGV0ZXJt aW5lIHdoaWNoIHNpZGUgdXNlcyBvZGQgb3IgZXZlbiBpcyBiYXNlZCBvbiB0aGUNCnVuZGVybHlp bmcgRFRMUyBjb25uZWN0aW9uIHJvbGUgd2hlbiB1c2VkIGluIFdlYlJUQywgd2l0aCB0aGUgc2lk ZQ0KYWN0aW5nIGFzIHRoZSBEVExTIGNsaWVudCB1c2luZyBldmVuIHN0cmVhbSBpZGVudGlmaWVy cy4NCg0KVGhhdCBwYXJ0IEkgdW5kZXJzdGFuZC4NCg0KQnV0LCB0aGlzIG1lYW5zIHRoYXQgYm90 aCBlbmRwb2ludHMgbWF5IHNlbmQgREFUQV9DSEFOTkVMX09QRU4sIGZvciB0aGUgc2FtZSBwcm90 b2NvbCwgYW5kIFRIQVQgaXMgd2hhdCBJIHdvdWxkIGxpa2UgdG8gYXZvaWQuIEkgZG9uJ3Qgd2Fu dCB0byBoYXZlIHR3byBiaS1kaXJlY3Rpb25hbCBkYXRhIGNoYW5uZWxzIGZvciB0aGUgc2FtZSB0 aGluZy4NCg0KRm9yIHRoYXQgcmVhc29uIEkgc3VnZ2VzdGVkIHRoYXQgd2UgY291bGQgYWxzbyBz cGVjaWZ5IHdoaWNoIGVuZHBvaW50IGlzIHJlc3BvbnNpc2JsZSBmb3Igc2VuZGluZyBEQVRBX0NI QU5ORUxfT1BFTi4NCg0KSG93ZXZlciwgdGhlcmUgaXMgbm8gbWVjaGFuaXNtIHRvIGVuc3VyZSB1 bmlxdWVuZXNzIGZvciBsYWJlbHMuIFRoZSBXZWJSVEMgQVBJIGFscmVhZHkgYWxsb3dzIG9uZSBz aWRlIHRvIGNyZWF0ZSBuIGRhdGEgY2hhbm5lbHMgd2l0aCB0aGUgc2FtZSBsYWJlbC4NCg0KSSBh bSBub3Qgc2F5aW5nIGl0IHNob3VsZCBiZSBmb3JiaWRkZW4gdG8gZG8gc28uIEJ1dCwgZm9yIHBy b3RvY29sIFgsIEkgd2FudCB0byBlbmQgdXAgd2l0aCBPTkUgZGF0YSBjaGFubmVsIGJldHdlZW4g bXkgcGVlcnMuDQpUaGVuIG9ubHkgb25lIHNpZGUgc2hvdWxkIGNyZWF0ZSBhIGRhdGEgY2hhbm5l bC4NCg0KSWYgSSBlbmQgdXAgd2l0aCB0d28gZGF0YSBjaGFubmVscyBmb3IgcHJvdG9jb2wgWCwg Y2FuIEkgc2VuZCBkYXRhIG9uIHdoaWNoZXZlciBJIHdhbnQgdG8/DQpTdXJlLiBUaGVzZSB3b3Vs ZCBiZSB0d28gaW5kZXBlbmRlbnQgYmlkaXJlY3Rpb25hbCBkYXRhIGNoYW5uZWxzLg0KDQpQb3Nz aWJsZSBmb3IgdGhlIHNhbWUgcHJvdG9jb2wgLSBhbmQgdGhhdCBpcyB3aGF0IEkgd291bGQgd2Fu dCB0byBhdm9pZC4gSSB3YW50IHRvIHNlbmQgbXkgcHJvdG9jb2wgWCBtZXNzYWdlcyBvbiBvbmUg ZGF0YSBjaGFubmVsLCBhbmQgSSB3b3VsZCBsaWtlIHRvIHJlY2VpdmUgdGhlIHByb3RvY29sIFgg bWVzc2FnZXMgZnJvbSBteSBwZWVyIG9uIHRoZSBzYW1lIGRhdGEgY2hhbm5lbC4NCg0KTm93LCBv bmUgY2FuIG9mIGNvdXJzZSBzb2x2ZSB0aGlzIGJ5IHJlc2V0aW5nIG9uZSBvZiB0aGUgZGF0YSBj aGFubmVscywgYnV0IHRoZW4gdGhlIHF1ZXN0aW9uIGlzIHdoaWNoIGVuZHBvaW50IHNob3VsZCBy ZXNldCA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGll dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0 bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3J0Y3dlYg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B1D16D3C2ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJk YW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBQZXRlciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3Ig eW91ciBpbnB1dC4gSSB3YXMgdXNlZnVsDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5kLCZuYnNw OyBhZ2FpbiwgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGFkZCBzb21lIGd1aWRhbmNlIHRv IHRoZSBkYXRhIGNoYW5uZWwgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hy aXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBldGVyIFRo YXRjaGVyIFttYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g VHVlc2RheSwgRmVicnVhcnkgMTEsIDIwMTQgNzozMyBQTTxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0 ZXIgSG9sbWJlcmc8YnI+DQo8Yj5DYzo8L2I+IFBhdWwgS3l6aXZhdDsgJmx0O3J0Y3dlYkBpZXRm Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIERhdGEgQ2hhbm5lbCBQ cm90b2NvbDogUHJldmVudCBEQVRBX0NIQU5ORUxfT1BFTiBnbGFyZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmViIDExLCAyMDE0IGF0IDEwOjIyIEFNLCBDaHJpc3Rl ciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUGV0ZXIs PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQomZ3Q7IEkgYmVsaWV2ZSB0aGUgQVBJIGFscmVhZHkgZ2l2 ZXMgeW91IGFsbCB0aGUgdG9vbHMgeW91IG5lZWQgZm9yIHRoaXMgdXNlIGNhc2UuICZuYnNwO0hl cmUncyBvbmUgd2F5IHRvIGNyZWF0ZSBhIGRhdGEgY2hhbm5lbCB3aGVyZSBib3RoIGVuZHMgY2Fs bCBjcmVhdGVEYXRhQ2hhbm5lbCgpIGF0IHRoZSBzYW1lIHRpbWUsIHdpdGggbm8gJnF1b3Q7bWlk ZGxlJnF1b3Q7Ojxicj4NCiZndDs8YnI+DQomZ3Q7IDEuICZuYnNwO0JvdGggc2lkZXMgY2FsbCBj cmVhdGVEYXRhQ2hhbm5lbCgpIHdpdGggdGhlIHNhbWUgbGFiZWwuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9yLCB3aXRoIHRoZSBzYW1lIFByb3RvY29sLjxi cj4NCjxicj4NCkl0IGlzIGEgbGl0dGxlIHVuY2xlYXIgdG8gbWUgd2hhdCAmcXVvdDtsYWJlbCZx dW90OyByZWFsbHkgaXMuIFRoZSBkYXRhIGNoYW5uZWwgZHJhZnQgc2F5cyBpdCdzIGEgJnF1b3Q7 bmFtZSBvZiB0aGUgY2hhbm5lbCZxdW90Oy4uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igIs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ TGFiZWwgaXMgd2hhdGV2ZXIgdGhlIEpTICZuYnNwO29yIG5hdGl2ZSBhcHAgY2hvb3NlcyBpdCB0 byBiZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAizwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiAmbmJzcDtZb3Ug Y2FuIGdpdmUgaXQgd2hhdGV2ZXIgc2VtYW50aWNzIHlvdSB3YW50LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQomZ3Q7IDIuICZuYnNw O0lmIGFuIGVuZHBvaW50IGVuZHMgdXAgd2l0aCB0d28gZGF0YSBjaGFubmVscyB3aXRoIHRoZSBz YW1lIGxhYmVsLCBjbG9zZSB0aGUgb25lIHdpdGggdGhlIGhpZ2hlciAuaWQsIGFuZCBrZWVwIHRo ZSBvbmUgd2l0aCB0aGUgbG93ZXIgLmlkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XaGF0IGlzICZxdW90Oy5pZCZxdW90Oz8gSXMgaXQgc29tZXRoaW5nIEFQ SSBzcGVjaWZpYz8gS2VlcCBpbiBtaW5kIHRoYXQgbm9uLVdlYlJUQyBjbGllbnRzIG1heSBhbHNv IHVzZSB0aGUgZGF0YSBjaGFubmVsLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkluPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igIs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+4oCLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCLPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBKUywgaXQncyB0aGlzOiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL2Rldi53 My5vcmcvMjAxMS93ZWJydGMvZWRpdG9yL3dlYnJ0Yy5odG1sI3dpZGwtUlRDRGF0YUNoYW5uZWwt aWQiPmh0dHA6Ly9kZXYudzMub3JnLzIwMTEvd2VicnRjL2VkaXRvci93ZWJydGMuaHRtbCN3aWRs LVJUQ0RhdGFDaGFubmVsLWlkPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igIs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+T24gdGhlIHdpcmUsIGl0J3MgdGhlIFNDVFAgU0lELjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ 4oCLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAizwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jmd0OyBOb3cgYm90aCBz aWRlcyB3aWxsIHVzZSB0aGUgc2FtZSBjaGFubmVsLCBhbmQgeW91IGNhbiBwcmV0ZW5kIGxpa2Ug dGhlIG90aGVyIG5ldmVyIGV4aXN0ZWQuICZuYnNwOyBJZiB5b3UncmUgd29ycmllZCBhYm91dCBk YXRhIHNlbnQgYmVmb3JlIHRoaXMgcHJvY2VzcyBjb21wbGV0ZXMsIGVpdGhlciBhY2NlcHQgZGF0 YSBvbiBib3RoIGNoYW5uZWxzIGZvciBhIHdoaWxlLCBvciBkb24ndCBzZW5kIGRhdGEgdW50aWwN CiB0aGUgcHJvY2VzcyBjb21wbGV0ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij4mZ3Q7PGJyPg0KJmd0OyBJcyB0aGVyZSBhbnkgcmVhc29uIHRoaXMgd291bGQgbm90IHdv cms/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+QXNzdW1pbmcgaXQncyBnZW5lcmljLCBhbmQgbm90IEFQSSBz cGVjaWZpYywgSSBndWVzcyBpdCBjb3VsZCB3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igIvi gIs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAizwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Z ZXMsIGl0J3MgZ2VuZXJpYy4gJm5ic3A7VGhlIGxvZ2ljIGlzIGJhc2ljYWxseSwgJnF1b3Q7aWYg eW91IGVuZCB1cCB3aXRoIHR3byBTSURzIHdpdGggdGhlIHNhbWUgbGFiZWwsIGNsb3NlIHRoZSBj aGFubmVsIHdpdGggdGhlIGhpZ2hlciBTSUQmcXVvdDsuDQogJm5ic3A7QXBwbGllcyB0byBhbnkg ZW5kcG9pbnQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igIs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BbHNvLCBhcyBoYXMgYmVlbiBpbmRpY2F0ZWQsIHNw ZWNpZmljIHByb3RvY29scyBjYW4gc3BlY2lmeSBydWxlcyByZWdhcmRpbmcgd2hvIG9wZW5zIHRo ZSBjaGFubmVsLjxicj4NCjxicj4NCkkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIHNv bWUgaW5mb3JtYXRpdmUgZ3VpZGFuY2UgdGV4dCBhYm91dCB0aGlzIHNvbWV3aGVyZSwgZS5nLiBp biB0aGUgRGF0YSBDaGFubmVsIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hy aXN0ZXI8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQpPbiBNb24sIEZlYiAxMCwgMjAxNCBhdCA1OjEwIFBNLCBQYXVsIEt5eml2YXQgJmx0 OzxhIGhyZWY9Im1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHUiPnBreXppdmF0QGFsdW0ubWl0 LmVkdTwvYT4mZ3Q7IHdyb3RlOjxicj4NCllvdSB0d28gZ3V5cyBhcmUgdGFsa2luZyBwYXN0IG9u ZSBhbm90aGVyLjxicj4NCjxicj4NCkNocmlzdGVyJ3MgcG9pbnQgaXMgdGhhdCB0aGUgKmFwcGxp Y2F0aW9uJnF1b3Q7IGRpc3RyaWJ1dGVkIGJldHdlZW4gdGhlIHR3byBlbmRwb2ludHMsIG5lZWRz IGEgKnNpbmdsZSogaW5zdGFuY2Ugb2YgYSBjaGFubmVsIGZvciBhIHBhcnRpY3VsYXIgYXBwbGlj YXRpb24gc3BlY2lmaWMgcHVycG9zZS4gQnV0IHRoZSB0d28gZW5kcyBhcmUgZ2VuZXJhbGx5IHN5 bW1ldHJpYy4gVGhlcmUgaXMgbm8gb2J2aW91cyBjaG9pY2Ugb2Ygd2hpY2ggc2lkZSBzaG91bGQN CiBjcmVhdGUgdGhlIGNoYW5uZWwuIFNvIGhvdyBkbyB3ZSB1c2UgdGhlIG1lY2hhbmlzbSB0byBh Y2hpZXZlIHRoaXMgcmVzdWx0Pzxicj4NCjxicj4NCkkgdGhpbmsgSSBjYW4gcHJlZGljdCB3aGF0 IE1pY2hhZWwgaXMgZ29pbmcgdG8gc2F5OiBpdCBpc24ndCBhIHByb3RvY29sIGlzc3VlIC0gdGhl IHR3byBlbmRzIHNob3VsZCBuZWdvdGlhdGUgdGhpcyBzb21lIG90aGVyIHdheS4gKEluIHRoZSBu b3JtYWwgcnRjd2ViIHNjZW5hcmlvLCBhICpzaW5nbGUqIGFwcCBpbiB0aGUgbWlkZGxlIGNhbiBh cnJhbmdlIGZvciBvbmUgc2lkZSB0byBkbyB0aGUgb3Blbi4pPGJyPg0KPGJyPg0KVGhpcyBpcyBh IHByb2JsZW0gd2l0aCBhIHNpcCBhcHAgLSB0aGVyZSBpcyBubyBtaWRkbGUsIGp1c3QgdHdvIGVu ZHMuPGJyPg0KPGJyPg0KPGJyPg0KUHJldmlvdXNseSBDaHJpc3RlciBzYWlkOjxicj4NCkNvdWxk buKAmXQgd2UgZS5nLiBzYXkgdGhhdCwgYnkgZGVmYXVsdCwgdGhlIERUTFMgY2xpZW50IGlzIHJl c3BvbnNpYmxlIGZvciBzZW5kaW5nIHRoZSBEQVRBX0NIQU5ORUxfT1BFTj8gVGhlbiB0aGVyZSBp cyBubyByaXNrIGZvciBnbGFyZSwgYW5kIGl0IGNvdWxkIGV2ZW4gdXNlIGJvdGggYW4gZXZlbiBv ciBvZGQgc3RyZWFtIGlkIHZhbHVlLjxicj4NCjxicj4NClRoYXQgaXMgYSBiYWQgdGhpbmcgZm9y IGRhdGEgY2hhbm5lbCBpbiBnZW5lcmFsLiBCdXQgSSBzdXBwb3NlIHRoZSBhcHAgY2FuIGNob29z ZSB0byBmb2xsb3cgdGhpcyBydWxlIGlmIGl0IHdhbnRzIGZvciBwYXJ0aWN1bGFyIGNoYW5uZWxz Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGFua3MsPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBhdWw8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQpPbiAyLzEwLzE0IDEyOjI5IFBNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90 ZTo8YnI+DQo8YnI+DQpIaSw8YnI+DQpBcyBpcyBkZWZpbmVkIGluIHRoZSBkYXRhIGNoYW5uZWwg cHJvdG9jb2wsIGFuIGVudGl0eSBjYW4gc2VuZCBkYXRhIG9uY2UgREFUQV9DSEFOTkVMX09QRU4g aGFzIGJlZW4gc2VudCwgYmVmb3JlIHRoZSBhc3NvY2lhdGVkIERBVEFfQ0hBTk5FTF9BQ0sgaXMg cmVjZWl2ZWQuPGJyPg0KPGJyPg0KVGhlIGRyYWZ0IGFsc28gc2F5cyB0aGF0LCBpZiBib3RoIGVu ZHBvaW50cyBzZW5kIERBVEFfQ0hBTk5FTF9PUEVOIGF0IHRoZSBzYW1lIHRpbWUsIHVzaW5nIGRp ZmZlcmVudCBzdHJlYW0gaWQgdmFsdWVzLCB0aGUgcmVzdWx0IG1heSBiZSBUV08gZGF0YSBjaGFu bmVscywgd2l0aCBkYXRhIHNlbnQgb24gYm90aC48YnI+DQo8YnI+DQpIb3dldmVyLCBhcyBpcyBh bHNvIGluZGljYXRlZCwgdGhlIGRyYWZ0IGRvZXMgbm90IHByb3ZpZGUgYSBtZWNoYW5pc20gdG8g cHJldmVudC9oYW5kbGUgc3VjaCBnbGFyZSBzaXR1YXRpb24uPGJyPg0KPGJyPg0KSSBwZXJzb25h bGx5IHRoaW5rIHRoZXJlIHNoYWxsIGJlIGEgd2F5IHRvIHByZXZlbnQgc3VjaCBzaXR1YXRpb24s IG9yIG90aGVyd2lzZSBJJ20gc3VyZSB3ZSBhcmUgZ29pbmcgdG8gZW5kIHVwIHdpdGggaW50ZXJv cGVyYWJpbGl0eSBwcm9ibGVtcy48YnI+DQo8YnI+DQpDb3VsZG4ndCB3ZSBlLmcuIHNheSB0aGF0 LCBieSBkZWZhdWx0LCB0aGUgRFRMUyBjbGllbnQgaXMgcmVzcG9uc2libGUgZm9yIHNlbmRpbmcg dGhlIERBVEFfQ0hBTk5FTF9PUEVOPyBUaGVuIHRoZXJlIGlzIG5vIHJpc2sgZm9yIGdsYXJlLCBh bmQgaXQgY291bGQgZXZlbiB1c2UgYm90aCBhbiBldmVuIG9yIG9kZCBzdHJlYW0gaWQgdmFsdWUu PGJyPg0KU2VjdGlvbiA0IHJlYWRzOjxicj4NCjxicj4NClRvIGF2b2lkIGdsYXJlIGluIG9wZW5p bmcgQ2hhbm5lbHMsIGVhY2ggc2lkZSBNVVNUIHVzZSBlaXRoZXIgZXZlbjxicj4NCm9yICZuYnNw O29kZCBTdHJlYW1zIHdoZW4gc2VuZGluZyBhIERBVEFfQ0hBTk5FTF9PUEVOIG1lc3NhZ2UuICZu YnNwO1RoZSBtZXRob2Q8YnI+DQp1c2VkIHRvIGRldGVybWluZSB3aGljaCBzaWRlIHVzZXMgb2Rk IG9yIGV2ZW4gaXMgYmFzZWQgb24gdGhlPGJyPg0KdW5kZXJseWluZyBEVExTIGNvbm5lY3Rpb24g cm9sZSB3aGVuIHVzZWQgaW4gV2ViUlRDLCB3aXRoIHRoZSBzaWRlPGJyPg0KYWN0aW5nIGFzIHRo ZSBEVExTIGNsaWVudCB1c2luZyBldmVuIHN0cmVhbSBpZGVudGlmaWVycy48YnI+DQo8YnI+DQpT byB0aGVyZSBpcyBubyBwcm9ibGVtIGluIHNldHRpbmcgdXAgZGF0YSBjaGFubmVscy48YnI+DQo8 YnI+DQpUaGlzIHNob3VsZCBub3QgYmUgY29uZnVzZWQgYnkgYm90aCBzaWRlcyBzZXR0aW5nIHVw IGEgZGF0YSBjaGFubmVsIHdpdGggdGhlIHNhbWUgTGFiZWwuIFRoaXMgZW5kcyB1cCBpbiB0d28g ZGF0YSBjaGFubmVscyB3aXRoIHRoZSBzYW1lIGxhYmVsLjxicj4NCllvdSBjYW4gZXZlbiBjcmVh dGUgbW9yZSBkYXRhIGNoYW5uZWxzIHdpdGggdGhlIHNhbWUgbGFiZWwuPGJyPg0KPGJyPg0KTXkg cG9pbnQgaXMgdGhhdCBJIGRvbid0IHdhbnQgdG8gZW5kIHVwIHdpdGggbW9yZSB0aGFuIG9uZSBj aGFubmVsLjxicj4NCkFuZCB5b3Ugd29uJ3QsIHNlZSBhYm92ZS48YnI+DQo8YnI+DQpJIGFtIG5v dCBzdXJlIEkgdW5kZXJzdGFuZC4gV2hhdCB0ZXh0IGRvIHlvdSByZWZlciB0bz88YnI+DQpUbyBh dm9pZCBnbGFyZSBpbiBvcGVuaW5nIENoYW5uZWxzLCBlYWNoIHNpZGUgTVVTVCB1c2UgZWl0aGVy IGV2ZW48YnI+DQpvciAmbmJzcDtvZGQgU3RyZWFtcyB3aGVuIHNlbmRpbmcgYSBEQVRBX0NIQU5O RUxfT1BFTiBtZXNzYWdlLiAmbmJzcDtUaGUgbWV0aG9kPGJyPg0KdXNlZCB0byBkZXRlcm1pbmUg d2hpY2ggc2lkZSB1c2VzIG9kZCBvciBldmVuIGlzIGJhc2VkIG9uIHRoZTxicj4NCnVuZGVybHlp bmcgRFRMUyBjb25uZWN0aW9uIHJvbGUgd2hlbiB1c2VkIGluIFdlYlJUQywgd2l0aCB0aGUgc2lk ZTxicj4NCmFjdGluZyBhcyB0aGUgRFRMUyBjbGllbnQgdXNpbmcgZXZlbiBzdHJlYW0gaWRlbnRp ZmllcnMuPGJyPg0KPGJyPg0KVGhhdCBwYXJ0IEkgdW5kZXJzdGFuZC48YnI+DQo8YnI+DQpCdXQs IHRoaXMgbWVhbnMgdGhhdCBib3RoIGVuZHBvaW50cyBtYXkgc2VuZCBEQVRBX0NIQU5ORUxfT1BF TiwgZm9yIHRoZSBzYW1lIHByb3RvY29sLCBhbmQgVEhBVCBpcyB3aGF0IEkgd291bGQgbGlrZSB0 byBhdm9pZC4gSSBkb24ndCB3YW50IHRvIGhhdmUgdHdvIGJpLWRpcmVjdGlvbmFsIGRhdGEgY2hh bm5lbHMgZm9yIHRoZSBzYW1lIHRoaW5nLjxicj4NCjxicj4NCkZvciB0aGF0IHJlYXNvbiBJIHN1 Z2dlc3RlZCB0aGF0IHdlIGNvdWxkIGFsc28gc3BlY2lmeSB3aGljaCBlbmRwb2ludCBpcyByZXNw b25zaXNibGUgZm9yIHNlbmRpbmcgREFUQV9DSEFOTkVMX09QRU4uPGJyPg0KPGJyPg0KSG93ZXZl ciwgdGhlcmUgaXMgbm8gbWVjaGFuaXNtIHRvIGVuc3VyZSB1bmlxdWVuZXNzIGZvciBsYWJlbHMu IFRoZSBXZWJSVEMgQVBJIGFscmVhZHkgYWxsb3dzIG9uZSBzaWRlIHRvIGNyZWF0ZSBuIGRhdGEg Y2hhbm5lbHMgd2l0aCB0aGUgc2FtZSBsYWJlbC48YnI+DQo8YnI+DQpJIGFtIG5vdCBzYXlpbmcg aXQgc2hvdWxkIGJlIGZvcmJpZGRlbiB0byBkbyBzby4gQnV0LCBmb3IgcHJvdG9jb2wgWCwgSSB3 YW50IHRvIGVuZCB1cCB3aXRoIE9ORSBkYXRhIGNoYW5uZWwgYmV0d2VlbiBteSBwZWVycy48YnI+ DQpUaGVuIG9ubHkgb25lIHNpZGUgc2hvdWxkIGNyZWF0ZSBhIGRhdGEgY2hhbm5lbC48YnI+DQo8 YnI+DQpJZiBJIGVuZCB1cCB3aXRoIHR3byBkYXRhIGNoYW5uZWxzIGZvciBwcm90b2NvbCBYLCBj YW4gSSBzZW5kIGRhdGEgb24gd2hpY2hldmVyIEkgd2FudCB0bz88YnI+DQpTdXJlLiBUaGVzZSB3 b3VsZCBiZSB0d28gaW5kZXBlbmRlbnQgYmlkaXJlY3Rpb25hbCBkYXRhIGNoYW5uZWxzLjxicj4N Cjxicj4NClBvc3NpYmxlIGZvciB0aGUgc2FtZSBwcm90b2NvbCAtIGFuZCB0aGF0IGlzIHdoYXQg SSB3b3VsZCB3YW50IHRvIGF2b2lkLiBJIHdhbnQgdG8gc2VuZCBteSBwcm90b2NvbCBYIG1lc3Nh Z2VzIG9uIG9uZSBkYXRhIGNoYW5uZWwsIGFuZCBJIHdvdWxkIGxpa2UgdG8gcmVjZWl2ZSB0aGUg cHJvdG9jb2wgWCBtZXNzYWdlcyBmcm9tIG15IHBlZXIgb24gdGhlIHNhbWUgZGF0YSBjaGFubmVs Ljxicj4NCjxicj4NCk5vdywgb25lIGNhbiBvZiBjb3Vyc2Ugc29sdmUgdGhpcyBieSByZXNldGlu ZyBvbmUgb2YgdGhlIGRhdGEgY2hhbm5lbHMsIGJ1dCB0aGVuIHRoZSBxdWVzdGlvbiBpcyB3aGlj aCBlbmRwb2ludCBzaG91bGQgcmVzZXQgOik8YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4N CkNocmlzdGVyPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpy dGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+ cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_7594FB04B1934943A5C02806D1A2204B1D16D3C2ESESSMB209erics_-- From richard.ejzak@gmail.com Tue Feb 11 12:05: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 0D3211A0737 for ; Tue, 11 Feb 2014 12:05:11 -0800 (PST) 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 KOHzJxniCeC2 for ; Tue, 11 Feb 2014 12:05:08 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EBDDD1A0747 for ; Tue, 11 Feb 2014 12:05:07 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id s7so4854008lbd.32 for ; Tue, 11 Feb 2014 12:05:06 -0800 (PST) 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=zGX+ZKg4LenXyq7c1hFRY0BAv3K5ZPk7TA96cUjZOrA=; b=APfLM3c3XSXt/+sQgRLPp8HO1XwLRgpUJlFNnuZpotmVARtcBRVITAT8X3+o9101vD lDaW9bIYuoKJKQESLY1OJP4UCV1Yw0GEMxd2Kkme8Dex7/Qju9tmfM1AVDMCcWxPBJPc 69LBLf71QHai2p67EMcnz4B3brvd+JxQo+8NdKCt5rVG4Md2AeoePMxlUlsKbu7BsBDP BlD1iOtGNvwJ7I0J+3+ZkRwO7Ht3q3N/ZC6GuSc+RBVWUYMlfLWWKZy2PVXn5CdGp2tf r3Ira/wzsafsap+Vj/9001vkd3l7pAOtFAi+7t8aPvBcj52H9Kl6LBUvzxExtZYnbu/D Zklw== MIME-Version: 1.0 X-Received: by 10.112.160.200 with SMTP id xm8mr26515800lbb.24.1392149106675; Tue, 11 Feb 2014 12:05:06 -0800 (PST) Received: by 10.112.98.162 with HTTP; Tue, 11 Feb 2014 12:05:06 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15F1AC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15F1AC@ESESSMB209.ericsson.se> Date: Tue, 11 Feb 2014 14:05:06 -0600 Message-ID: From: Richard Ejzak To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c24896fa557504f226f8db Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data channel: JavaScript usage of data channel without the Data Channel Protocol? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Feb 2014 20:05:11 -0000 --001a11c24896fa557504f226f8db Content-Type: text/plain; charset=ISO-8859-1 Hi Christer, I didn't see any other response to your question, but please excuse me if I missed it. My understanding of this case is that if DCEP is not used, the "open" event is triggered once the browser finishes creating the protocol machinery for the data channel being created. This is the only mechanism available to acknowledge to the JS app that the data channel has been set up since, as you say, the browser will neither send nor receive an open/ack message. I don't see any other reasonable alternative to this without API changes. There is a slight problem with this since the peer may not have established the protocol machinery necessary to actually communicate on the created data channel. Some external mechanism is necessary to verify that both peers have "opened" the same data channel before either party sends data. See my draft on SDP for external negotiation of data channels for a description of one way to do this. Richard On Thu, Feb 6, 2014 at 5:15 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > As was indicated earlier, the usage of the Data Channel Protocol (DCP) is > optional with the Data Channel. > > > > However, if I understand the API correctly, only the DCP "open"/"ack" > messages will trigger a JavaScript "open" event. > > > > If so, how will my JS App be able to use the data channel if I do NOT use > the Data Channel Protocol? Can I use it without the "open" event, and/or is > there something else that will trigger it? > > > > Regards, > > > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c24896fa557504f226f8db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Christer,
I didn't see any other response to yo= ur question, but please excuse me if I missed it.

= My understanding of this case is that if DCEP is not used, the "open&q= uot; event is triggered once the browser finishes creating the protocol mac= hinery for the data channel being created.  This is the only mechanism= available to acknowledge to the JS app that the data channel has been set = up since, as you say, the browser will neither send nor receive an open/ack= message.  I don't see any other reasonable alternative to this wi= thout API changes.

There is a slight problem with this since the peer may = not have established the protocol machinery necessary to actually communica= te on the created data channel.  Some external mechanism is necessary = to verify that both peers have "opened" the same data channel bef= ore either party sends data.  See my draft on SDP for external negotia= tion of data channels for a description of one way to do this.

Richard


<= div class=3D"gmail_quote">On Thu, Feb 6, 2014 at 5:15 AM, Christer Holmberg= <christer.holmberg@ericsson.com> wrote:

Hi,

 

As was indicated earlier, the usage of the Data Chan= nel Protocol (DCP) is optional with the Data Channel.

 

However, if I understand the API correctly, only the= DCP "open"/"ack" messages will trigger a JavaScript &q= uot;open" event.

 

If so, how will my JS App be able to use the data ch= annel if I do NOT use the Data Channel Protocol? Can I use it without the &= ldquo;open” event, and/or is there something else that will trigger i= t?

 

Regards,

 

Christer


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


--001a11c24896fa557504f226f8db-- From randell-ietf@jesup.org Tue Feb 11 16:46: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 95E931A0791 for ; Tue, 11 Feb 2014 16:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] 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 K39RU5pUWZV6 for ; Tue, 11 Feb 2014 16:46:52 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8971A0767 for ; Tue, 11 Feb 2014 16:46:52 -0800 (PST) Received: from corp-240.mv.mozilla.com ([63.245.220.240]:54608 helo=[10.250.6.245]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDNyV-000F15-OB for rtcweb@ietf.org; Tue, 11 Feb 2014 18:46:51 -0600 Message-ID: <52FAC47B.5090809@jesup.org> Date: Tue, 11 Feb 2014 16:46:51 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D166D41@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050701000107060605030103" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Subject: Re: [rtcweb] Data Channel Protocol: Data before DATA_CHANNEL_ACK X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Feb 2014 00:46:54 -0000 This is a multi-part message in MIME format. --------------050701000107060605030103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/10/2014 10:20 AM, Peter Thatcher wrote: > If you have to wait for the ACK, it's one more RTT you have to wait > before you can send data. We've already got many RTTs form ICE and > DTLS and what's built into SCTP. We originally didn't have an ACK > message at all, in large part because we didn't want more RTTs. The > ACK was put in to handle the edge case of unordered data arriving > before the OPEN message. But we added it in a way that it doesn't add > more RTTs. Exactly. Especially at call-start. > > > On Mon, Feb 10, 2014 at 2:20 AM, Christer Holmberg > > wrote: > > Hi, > > As is defined in the data channel protocol, an entity can send > data once DATA_CHANNEL_OPEN has been sent, before the associated > DATA_CHANNEL_ACK is received. > > What is the reason for allowing data to be sent before > DATA_CHANNEL_ACK? The sender may not even know (depends on > whatever external negotiation mechanisms are used) whether the > remote peer supports the protocol to begin with. > > It think it would be good to allow the remote peer to accept > (DATA_CHANNEL_ACK) or reject (stream reset) the DATA_CHANNEL_OPEN > before data is sent. > "Rejection" of a channel can be done be either ignoring it (drop the channel reference on the floor), or actively closing it (channel.close(), then drop it on the floor). This was agreed on a long time ago. -- Randell Jesup randell-ietf@jesup.org --------------050701000107060605030103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
On 2/10/2014 10:20 AM, Peter Thatcher wrote:
If you have to wait for the ACK, it's one more RTT you have to wait before you can send data.  We've already got many RTTs form ICE and DTLS and what's built into SCTP.  We originally didn't have an ACK message at all, in large part because we didn't want more RTTs.  The ACK was put in to handle the edge case of unordered data arriving before the OPEN message.  But we added it in a way that it doesn't add more RTTs.

Exactly.   Especially at call-start.



On Mon, Feb 10, 2014 at 2:20 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

As is defined in the data channel protocol, an entity can send data once DATA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK is received.

What is the reason for allowing data to be sent before DATA_CHANNEL_ACK? The sender may not even know (depends on whatever external negotiation mechanisms are used) whether the remote peer supports the protocol to begin with.

It think it would be good to allow the remote peer to accept (DATA_CHANNEL_ACK) or reject (stream reset) the DATA_CHANNEL_OPEN before data is sent.

"Rejection" of a channel can be done be either ignoring it (drop the channel reference on the floor), or actively closing it (channel.close(), then drop it on the floor).  This was agreed on a long time ago.

-- 
Randell Jesup
randell-ietf@jesup.org
--------------050701000107060605030103-- From randell-ietf@jesup.org Tue Feb 11 18:05: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 09F921A07C3 for ; Tue, 11 Feb 2014 18:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] 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 gy5Pc_GA2lr8 for ; Tue, 11 Feb 2014 18:05:35 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4A31A07BD for ; Tue, 11 Feb 2014 18:05:35 -0800 (PST) Received: from corp-240.mv.mozilla.com ([63.245.220.240]:57728 helo=[10.250.6.245]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDPCg-0007Dw-4W for rtcweb@ietf.org; Tue, 11 Feb 2014 20:05:34 -0600 Message-ID: <52FAD6EE.3070807@jesup.org> Date: Tue, 11 Feb 2014 18:05:34 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5280E181.20104@ericsson.com> <9A62A3AC-F990-4358-B2E7-B8DD39A81B03@fh-muenster.de> In-Reply-To: <9A62A3AC-F990-4358-B2E7-B8DD39A81B03@fh-muenster.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Feb 2014 02:05:37 -0000 On 2/11/2014 5:47 AM, Michael Tuexen wrote: > On Nov 11, 2013, at 2:54 PM, Magnus Westerlund wrote: > > >> 3. Section 3.2: >> U-C 7: Proxy browsing, where a browser uses data channels of a >> PeerConnection to send and receive HTTP/HTTPS requests and data, >> for example to avoid local internet filtering or monitoring. >> >> Yes, this may be something that is possible, but to express it as a use >> cases intended to be supported might not be the best. We are after all >> likely talking about circumventing local security policies. I would also >> note that "Internet" is with capital I. > Change to Internet. The use case seems important, since there are already > implementations doing this (possibly not using data channels, don't know). > Randell: What do you think? There are people actively planning to use it for this usecase in high-profile applications (using datachannels), or so I am told. > >> 6. Section 4: >> [ TBD: how this is encoded and what the impact of this is. ] >> >> Didn't we have some direction decisions on how priority was to be >> handled at least locally by the end-point. Please add this to the draft. > I think we decided to have priorities for data channels, which are not strict > priorities. That is all. The W3C document doesn't mention it. We haven't discussed it yet at the W3 level. >> I also hope that the way of representing priorities can get clearer from >> an API perspective. > I agree. However, I'm not a member of W3C... Anyone can take part in the W3 discussions on this. Please feel free to propose something. >> 12. Section 5: >> " Since DTLS is typically implemented in user-land, the SCTP stack also >> needs to be a user-land stack." >> >> I wonder what the message of this sentence is? The reason is that I > That you can't use a kernel SCTP stack, even if available. >> wonder what it should be saying if one implements DTLS in a kernel, or > I haven't seen this yet. I think you can do the encrypt/decrypt part, > but doing the key management stuff in kernel land doesn't seem appropriate. >> similar if one despite a DTLS user-land stack uses a SCTP stack in the >> kernel through access to raw sockets. > How can the lower layer run in userland when the upper layer runs in > kernel land? It can in theory, but likely not in any of the OS's we're concerned with currently. >> 15. Section 5: >> Using a congestion control >> different from the standard one might improve the impact on the >> parallel SRTP media streams. Since SCTP does not support the >> negotiation of a congestion control algorithm, alternate congestion >> controls SHOULD only require a different sender side behavior using >> existing information carried in the association. >> >> A: I wonder if adding a "yet" into the second sentence to make clear >> that in the future there might be support for negotiating congestion >> control. >> >> B: Also, what happens if one violate the SHOULD and require receiver >> side information and the peer don't support it. That clearly can't be >> acceptable? Can this be formulated in some other way that is tighter >> without preventing sender side changes? > OK. Changed to > Since SCTP does not support the negotiation of a congestion control algorithm > yet, alternate congestion controls SHOULD either only require a different > sender side behavior using existing information carried in the association or > need also specify a negotiation of of a congestion control algorithm. Sounds good. >> 18. Section 6.2: >> " Additionally, >> the negotiation SHOULD include some type of congestion control >> selection. " >> >> Okay, this appears very fuzzy. And what name space or specifications are >> you going to use to negotiate what the different options are? > Randell? Salvatore? I don't think there is anything specified yet. There is not thus far -- Randell Jesup randell-ietf@jesup.org From pkyzivat@alum.mit.edu Tue Feb 11 19:51: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 CADF41A07A9 for ; Tue, 11 Feb 2014 19:51:42 -0800 (PST) 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 c8jr7bZyHcMR for ; Tue, 11 Feb 2014 19:51:40 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 21D751A033A for ; Tue, 11 Feb 2014 19:51:40 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta13.westchester.pa.mail.comcast.net with comcast id RFkQ1n0091HzFnQ5DFrfbm; Wed, 12 Feb 2014 03:51:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id RFre1n00m3ZTu2S3aFrfXw; Wed, 12 Feb 2014 03:51:39 +0000 Message-ID: <52FAEFCA.6070902@alum.mit.edu> Date: Tue, 11 Feb 2014 22:51:38 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Peter Thatcher References: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se> <4616BFFA-F461-4CE8-9D85-211B86D4BE93@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166D7B@ESESSMB209.ericsson.se> <71288EED-3C82-44A7-950B-EFEFA62616E6@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166F8C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167A2E@ESESSMB209.ericsson.se> <52F9786F.60809@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392177099; bh=fzvJyytQo5mToq3Ga7X1/JtFlHUfy5z3jVPmXckDTUU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dspqHnstV3XvLxDCGf2JlNPGZyWqa/9ezVBWanPs7oisSoZFAC/nquFd1UxUT0D+e qfmHUgXKKbdabUHPuanjz1LBHJRQQR391spOKICSSU0t/x/PvAyXWA7rM8ndTX+6+T h5CgBIDQ8Jhrmm0hp3yYEuSpzkKr+QZDP/ijcIkf5iUWn7nRY588d5N7aZhXOwtO/U +Od+yXXPwjVweVp9zV+7iKqogy4BpsN3NNbWxv5Iwn3yP+auI40rbu0sS8J7U49p4O 799K9s/skqJqNgzXPj0GleUiiG89Dlv+T5xbg0RpDH95XUp60fkBZb8Kz9Poqc0CBi cjDE5M75Ep4og== Cc: "" Subject: Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Feb 2014 03:51:43 -0000 On 2/11/14 1:06 PM, Peter Thatcher wrote: > I believe the API already gives you all the tools you need for this use > case. Here's one way to create a data channel where both ends call > createDataChannel() at the same time, with no "middle": > > 1. Both sides call createDataChannel() with the same label. > 2. If an endpoint ends up with two data channels with the same label, > close the one with the higher .id, and keep the one with the lower .id. > > Now both sides will use the same channel, and you can pretend like the > other never existed. If you're worried about data sent before this > process completes, either accept data on both channels for a while, or > don't send data until the process completes. > > Is there any reason this would not work? This seems reasonable to me. Thanks, Paul > On Mon, Feb 10, 2014 at 5:10 PM, Paul Kyzivat > wrote: > > You two guys are talking past one another. > > Christer's point is that the *application" distributed between the > two endpoints, needs a *single* instance of a channel for a > particular application specific purpose. But the two ends are > generally symmetric. There is no obvious choice of which side should > create the channel. So how do we use the mechanism to achieve this > result? > > I think I can predict what Michael is going to say: it isn't a > protocol issue - the two ends should negotiate this some other way. > (In the normal rtcweb scenario, a *single* app in the middle can > arrange for one side to do the open.) > > This is a problem with a sip app - there is no middle, just two ends. > > > Previously Christer said: > > Couldn’t we e.g. say that, by default, the DTLS client is > responsible for sending the DATA_CHANNEL_OPEN? Then there is no > risk for glare, and it could even use both an even or odd stream > id value. > > > That is a bad thing for data channel in general. But I suppose the > app can choose to follow this rule if it wants for particular channels. > > Thanks, > Paul > > > > > > > On 2/10/14 12:29 PM, Christer Holmberg wrote: > > > Hi, > > As is defined in the data channel > protocol, an entity can send data once > DATA_CHANNEL_OPEN has been sent, before > the associated DATA_CHANNEL_ACK is received. > > The draft also says that, if both > endpoints send DATA_CHANNEL_OPEN at the > same time, using different stream id > values, the result may be TWO data > channels, with data sent on both. > > However, as is also indicated, the draft > does not provide a mechanism to > prevent/handle such glare situation. > > I personally think there shall be a way > to prevent such situation, or otherwise > I'm sure we are going to end up with > interoperability problems. > > Couldn't we e.g. say that, by default, > the DTLS client is responsible for > sending the DATA_CHANNEL_OPEN? Then > there is no risk for glare, and it could > even use both an even or odd stream id > value. > > Section 4 reads: > > To avoid glare in opening Channels, each > side MUST use either even > or odd Streams when sending a > DATA_CHANNEL_OPEN message. The method > used to determine which side uses odd or > even is based on the > underlying DTLS connection role when used in > WebRTC, with the side > acting as the DTLS client using even stream > identifiers. > > So there is no problem in setting up data > channels. > > This should not be confused by both sides > setting up a data channel with the same > Label. This ends up in two data channels > with the same label. > You can even create more data channels with > the same label. > > > My point is that I don't want to end up with > more than one channel. > > And you won't, see above. > > > I am not sure I understand. What text do you refer to? > > To avoid glare in opening Channels, each side MUST use > either even > or odd Streams when sending a DATA_CHANNEL_OPEN message. > The method > used to determine which side uses odd or even is based on the > underlying DTLS connection role when used in WebRTC, with > the side > acting as the DTLS client using even stream identifiers. > > > That part I understand. > > But, this means that both endpoints may send DATA_CHANNEL_OPEN, > for the same protocol, and THAT is what I would like to avoid. I > don't want to have two bi-directional data channels for the same > thing. > > For that reason I suggested that we could also specify which > endpoint is responsisble for sending DATA_CHANNEL_OPEN. > > > However, there is no mechanism to ensure uniqueness > for labels. The WebRTC API already allows one side > to create n data channels with the same label. > > > I am not saying it should be forbidden to do so. But, > for protocol X, I want to end up with ONE data channel > between my peers. > Then only one side should create a data channel. > > If I end up with two data channels for protocol X, can I > send data on whichever I want to? > > Sure. These would be two independent bidirectional data > channels. > > > Possible for the same protocol - and that is what I would want > to avoid. I want to send my protocol X messages on one data > channel, and I would like to receive the protocol X messages > from my peer on the same data channel. > > Now, one can of course solve this by reseting one of the data > channels, but then the question is which endpoint should reset :) > > 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 pkyzivat@alum.mit.edu Tue Feb 11 19: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 4387C1A0814 for ; Tue, 11 Feb 2014 19:56:12 -0800 (PST) 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 ZaMieHUvxLjn for ; Tue, 11 Feb 2014 19:56:11 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id CF5641A0806 for ; Tue, 11 Feb 2014 19:56:10 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta06.westchester.pa.mail.comcast.net with comcast id RFVe1n0020EZKEL56Fw9TR; Wed, 12 Feb 2014 03:56:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id RFw91n00V3ZTu2S3MFw9Fn; Wed, 12 Feb 2014 03:56:09 +0000 Message-ID: <52FAF0D9.6040703@alum.mit.edu> Date: Tue, 11 Feb 2014 22:56:09 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D16D248@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D16D248@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=q20121106; t=1392177369; bh=LO4l1ynSGHGm50fTr1x2mdhmI3VvReXpYUj2wXH92u8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XL4ZtfIhMrWiVQNnIxuzA8SyZ9LWl0yGKvjaqd1/jPc++uMw/j/+Vkk3DEBdV+RaH UV4W9MTLQJHySkgYdm+mNI8f0WrwdeMk7XefIKs//W9DU51M28mG8XvmsM0TDOJoq3 urHEbXZWkeaDdUDM5yxgxLKGi1w15BW/JcRGsv7Dzow6QY89BVzCOo1MQ3on37lsdg PvXgXMlSGtLw4Nr4IeNiHwalnOlgDPEOpjy2pdjNdYl0S1Mlwys4z1HElqEcX7IF7t ctgfSGXlH4ITKyucxV2VD671Io72nIwx+zxmgRXC0E0RpEMctyKyllGEB4H5JZyVhj S/+WcAJiYlyIw== Subject: Re: [rtcweb] RTCWEB Data Channel Protocol: Label vs Protocol glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Feb 2014 03:56:12 -0000 On 2/11/14 12:50 PM, Christer Holmberg wrote: > Hi, > > The draft says: > > “Note: There is no attempt to resolve label glare; if both sides open > > a Channel labeled "x" at the same time, there will be > two Channels > > labeled "x" - one on an even Stream pair, one on an odd > pair.” > > I think the text shall be extended to also cover the Protocol, i.e. both > ends can try to open a channel for protocol X at the same time. And that should be fine. Having two channels with the same protocol is analogous to having two audio rtp m-lines. > Also, even if there is a label glare, it doesn’t have to be for the same > protocol. As far as I know, endpoints can choose whatever label value > they want, and they don’t even need to be for the same protcol (unless > specific protocols define what label value(s) must be used for channels > associated with that protocol). IIUC the point is for applications to manage the label namespace as they wish. Thanks, Paul > Regards, > > Christer > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From pkyzivat@alum.mit.edu Tue Feb 11 20:03: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 6062D1A081F for ; Tue, 11 Feb 2014 20:03:56 -0800 (PST) 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 FkVYIL7eUFNq for ; Tue, 11 Feb 2014 20:03:55 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id B71FA1A081B for ; Tue, 11 Feb 2014 20:03:54 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta03.westchester.pa.mail.comcast.net with comcast id RDCL1n0041HzFnQ53G3tC0; Wed, 12 Feb 2014 04:03:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id RG3t1n00N3ZTu2S3aG3t9n; Wed, 12 Feb 2014 04:03:53 +0000 Message-ID: <52FAF2A9.9070507@alum.mit.edu> Date: Tue, 11 Feb 2014 23:03:53 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D16D2BA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D16D2BA@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392177833; bh=jWG6AQm+wPcl3kMm8DfV0uGtka9qJgTPwK3vXLjRsNk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ftjmxRgkxU3e8BWsCUjhDpg/sKULS2uUfwHOnhhiymvpEuCYl/iAuxRdLHVMhesIQ WSPtYnYsNOwSin+xjsKzmx+rsKiOLkp9jssA7cipkKkgjyB04t1CO7DwlNbDNZz/oq o1CgJD+1CqIAMzhtsdPez7yHgWkjYvY2aTefuPlL0fGCaW1PB7cJWY61PrGeGPHXyt wH1MTN8zIy+fzEXPBrfJSWythXIx3bAOQmmXb/MBbcxfqfXiQpmbhlsWDz/m1FwXgV jIGDzT2lPiknWG707lQPIk7GmtYSvK05wk3w8aaWbgLwjUwweCzPE57NbdHzpSxa84 p6CFnFcjzw0Og== Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Comment on section 6 title X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Feb 2014 04:03:56 -0000 I suggest that this just be called "Data Channel", not "WebRTC Data Channel". (Or pick some other neutral name - perhaps SCTP Data Channel.) This won't be used solely for WebRTC. (It seems weird for two sip-based implementations of CLUE to be using a *WebRTC* Data Channel to talk to one another.) (But it would still make sense for the JS API to have a WebRTC-specific name.) Thanks, Paul On 2/11/14 1:15 PM, Christer Holmberg wrote: > Hi, > > Section 6 describes the characteristics of the data channel. > > However, the section name is "The Usage of SCTP in the WebRTC Context". > > I think we should rename that to something like "The Usage of SCTP for the WebRTC Data Channel". > > Because, the definition of the channel is the same no matter in which context it is used :) > > Regards, > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From magnus.westerlund@ericsson.com Wed Feb 12 00:16: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 02B3A1A08B3 for ; Wed, 12 Feb 2014 00:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 ZqwwzqI-oXvy for ; Wed, 12 Feb 2014 00:16:56 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id ECE041A0886 for ; Wed, 12 Feb 2014 00:16:55 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-eb-52fb2df6a011 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C2.22.10875.6FD2BF25; Wed, 12 Feb 2014 09:16:54 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.347.0; Wed, 12 Feb 2014 09:16:53 +0100 Message-ID: <52FB2DF5.5030201@ericsson.com> Date: Wed, 12 Feb 2014 09:16:53 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Parthasarathi R , =?ISO-8859-1?Q?=27Stefa?= =?ISO-8859-1?Q?n_H=E5kansson_LK=27?= , References: <1447FA0C20ED5147A1AA0EF02890A64B1CF4A182@ESESSMB209.ericsson.se> <007601cf2423$2d571210$88053630$@co.in> <1447FA0C20ED5147A1AA0EF02890A64B1CF533B8@ESESSMB209.ericsson.se> <004601cf24ad$f3a1c0c0$dae54240$@co.in> <52F8B1AB.70305@ericsson.com> <013901cf2693$97c1eb30$c745c190$@co.in> <52FA1BDB.5010709@ericsson.com> <016901cf274d$44332000$cc996000$@co.in> In-Reply-To: <016901cf274d$44332000$cc996000$@co.in> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGfG3Rveb7u8gg0sH5Cwmf+pjtVj7r53d gcljyZKfTB4f5n9hD2CK4rJJSc3JLEst0rdL4Mo49GgBY8F/mYo5t7ezNTBeFe9i5OSQEDCR OHx7PguELSZx4d56ti5GLg4hgUOMEj8XHYJyljNK/JrXA+RwcPAKaEv82moO0sAioCrx5/pa NhCbTcBC4uaPRjBbVCBYYueB34wgNq+AoMTJmU9YQOaICKxilLi8fztYkbCAjcS/C6fYIRa8 ZZLY8qSVFSTBCXTSo+fTmUGWSQiIS/Q0BoGEmQX0JKZcbWGEsOUlmrfOZgaxhYDuaWjqYJ3A KDgLyb5ZSFpmIWlZwMi8ipE9NzEzJ73ccBMjMCgPbvmtu4Px1DmRQ4zSHCxK4rwf3joHCQmk J5akZqemFqQWxReV5qQWH2Jk4uCUamCc8eSc/eOouLO1MutuLRSrWbCgcgPvXKt/XNOqvp+V 2599VbN9OWvov2CPH6/8rRXzQ/xflTM5PWb8c8h5Vtn8+Mtet567uk+6t/K5hV2b6tepN5av +GxXlH7D6oqVzM2zHiHPmXZs5Jyw223rPofpRTH1Ex+8UOp+ldfM9m3y+33BmgUZBnvWKLEU ZyQaajEXFScCAHzBfQ4YAgAA Subject: Re: [rtcweb] New version of use-case draft uploaded X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Feb 2014 08:16:59 -0000 See inline On 2014-02-11 18:18, Parthasarathi R wrote: >> >> Sorry, I fail to understand which of multiple possible angles you are >> arguing here. >> >> A) That the use case document is missing a whole requirement related to >> WebRTC Servers. WebRTC server, is something I am uncertain to what you >> refer to, a Web server or a media plan related server dealing with peer >> connections? >> > WebRTC server/gateway is a server which is a combination of Web > Server which handles WebRTC signaling and Media Plane server which deals > with peer-connection. Sec 3.4 of > draft-ietf-rtcweb-use-cases-and-requirements-13 describes 3 usecases for the > same. Unfortunately, draft-ietf-rtcweb-use-cases-and-requirements-13 is > missing NAT/Firewall traversal requirement related to WebRTC server/gateway. > Well, the Media plane functions are logically separate from the Web Server providing the JS and providing the signalling protocol functionality. Thus, I think this is unnecessary bunching together functionality. When it comes to NAT/FW requirements we have them on the whole solution. Why aren't these sufficient? > >> B) That F31 and F32 would lead to an assumption of mandating something, >> which currently is the only solution described? >> > > IMO, WebRTC server/gateway does not require TURN server and ICE-TCP serve > the purpose (Maximum of single WebRTC endpoint behind the firewall scenario > in a two party WebRTC session). As F31 and F32 mandates for TURN and there > is no NAT/Firewall explicit requirement for WebRTC server/gateway, it leads > to the conclusion of TURN server as an only solution by some of WebRTC > gateway providers. Hope this clarifies. > If we look at the media functionality side, as the Webserver NAT/FW traversal is basic requirement to even get the signaling to establish a peer connection working. Then we have general requirements. We have requirements that NAT/FW traversal is required. We have F31 and F32 which are requirement that was created after we taken a decision on at least requiring ICE with STUN and TURN support for WebRTC endpoints. Thus, F31 and F32 applies assuming that you will use these. I would prefer a requirements formulation that isn't technology specific. But you edits doesn't resole that concern. > >> C) That there needs to be text describing some aspect of the global >> presence? >> > It is good to have the text which describe NAT/firewall traversal > for WebRTC server/gatway perspective as well. I could not understand why you > are not allowing the changing F31 and F32 or adding the text about WebRTC > server NAT/firewall traversal in sec 3.4. Could you please clarify. > First of all, I do believe we have requirements on the functionality you discuss. Secondly, your proposal to change does not appear to achieve any consensus. My personal view, which I just count as one view here is that your proposal for change does not improve the situation, it only confuses it more. If you had a proposal which there appear to exist consensus around then I would request the authors to change the document. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From christer.holmberg@ericsson.com Wed Feb 12 02:23: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 BFEED1A092B for ; Wed, 12 Feb 2014 02:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 NXYSjcDmDEWU for ; Wed, 12 Feb 2014 02:23:47 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id CA7821A092A for ; Wed, 12 Feb 2014 02:23:46 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-bc-52fb4bb1d921 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 2C.21.04853.1BB4BF25; Wed, 12 Feb 2014 11:23:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 11:23:44 +0100 From: Christer Holmberg To: Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Comment on section 6 title Thread-Index: Ac8nVPFNLUjUgV0jQBWV6hVVCkMWSAASh4uAAA9Dh5A= Date: Wed, 12 Feb 2014 10:23:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16E5F0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D16D2BA@ESESSMB209.ericsson.se> <52FAF2A9.9070507@alum.mit.edu> In-Reply-To: <52FAF2A9.9070507@alum.mit.edu> 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+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvje5G799BBu17pS1WbDjAarH2Xzu7 A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVx5cNy5oLfnBXLljawNzD+ZO9i5OSQEDCR aHl8kBnCFpO4cG89WxcjF4eQwAlGiVk7GpggnMWMEp3/L7N2MXJwsAlYSHT/0wZpEBHwlei9 fI4RxBYWSJN4cmUrK0Q8XaLh5Uoo20riz88jYDaLgKrEmXkrwGxeoN5Jl44ygdhCAvkSy3+c B4tzCuhIHNvXDHYcI9BB30+tAathFhCXuPVkPhPEoQISS/achzpaVOLl439gp0kIKEos75eD KNeRWLD7ExuErS2xbOFrZoi1ghInZz5hmcAoOgvJ1FlIWmYhaZmFpGUBI8sqRsni1OLi3HQj A73c9NwSvdSizOTi4vw8veLUTYzAaDm45bfRDsaTe+wPMUpzsCiJ815nrQkSEkhPLEnNTk0t SC2KLyrNSS0+xMjEwSnVwLj9WQhPjuf+9Q+urpJV+GOvKz6ha2Yhd8LyW4/WTz6rKStX1yJR 8nLJ7eDXSbOVyxgr9hjJnpZcmOMWJ2tZEf0qdofrjQ7/vuXVC7rZ2V94FizxELd7fyVze9v7 L5a/Sh8u/5e4km3aVPdmzs0sD2JmXWc7fdCvo8Nt5fH4E8HOE1K+NyU8eaDEUpyRaKjFXFSc CACQCOJZZAIAAA== Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Comment on section 6 title X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Feb 2014 10:23:50 -0000 Hi, > I suggest that this just be called "Data Channel", not "WebRTC Data Chann= el". (Or pick some other neutral name - perhaps SCTP Data Channel.) Agree. A more generic name would be useful. "Simple Data Channel" "Simple SCTP Data Channel" Etc... > This won't be used solely for WebRTC. (It seems weird for two sip-based i= mplementations of CLUE to be using a *WebRTC* Data Channel to talk to one a= nother.) > > (But it would still make sense for the JS API to have a WebRTC-specific n= ame.) Agree. Regards Christer On 2/11/14 1:15 PM, Christer Holmberg wrote: > Hi, > > Section 6 describes the characteristics of the data channel. > > However, the section name is "The Usage of SCTP in the WebRTC Context". > > I think we should rename that to something like "The Usage of SCTP for th= e WebRTC Data Channel". > > Because, the definition of the channel is the same no matter in which=20 > context it is used :) > > 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 christer.holmberg@ericsson.com Wed Feb 12 02:28: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 90E2A1A091B for ; Wed, 12 Feb 2014 02:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 wDP4phqdAMYh for ; Wed, 12 Feb 2014 02:28:16 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEA11A0928 for ; Wed, 12 Feb 2014 02:28:14 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-96-52fb4cbc3e52 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2B.5E.23809.CBC4BF25; Wed, 12 Feb 2014 11:28:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 11:28:12 +0100 From: Christer Holmberg To: Richard Ejzak Thread-Topic: [rtcweb] Data channel: JavaScript usage of data channel without the Data Channel Protocol? Thread-Index: Ac8jLH45tofIO7FIT8mB4CIU+axUagEL66gAACAtcJA= Date: Wed, 12 Feb 2014 10:28:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16E732@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15F1AC@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.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D16E732ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvje5en99BBm8fcFs8621gtVj7r53d gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mq48uYQW8GpgIreLwvYGhi/uHUxcnJICJhI 7DjaygZhi0lcuLceyObiEBI4xCjx5cB5VghnMaPEw+sPgRwODjYBC4nuf9ogDSIC2hLbXj5g AbGZBdQl7iw+xw5iCwtkSqxZ38oIUZMl8XjGL3YI20rixsUJYHEWAVWJ83dugNm8Ar4Sj/fc ZoHYNYVR4unhJrChnAKBEqcaNrKC2IxA130/tYYJYpm4xK0n85kgrhaQWLLnPDOELSrx8vE/ sDslBBQllvfLQZTnS/yb1sUCsUtQ4uTMJywTGEVnIZk0C0nZLCRlEHEdiQW7P7FB2NoSyxa+ Zoaxzxx4zIQsvoCRfRUje25iZk56udEmRmBMHdzyW3UH451zIocYpTlYlMR5P7x1DhISSE8s Sc1OTS1ILYovKs1JLT7EyMTBKdXAWJ/5XudmzCKOpKcrf8+edd47glct/GGh/ub2mfVVPHOb r2fMtPu9+O/jsHxZf7YT9yU69FMznjfKepmJN+6/7Ni3Z0uTWPLC7o3Xu/jeH9qV+arOwu2J 0ps5a+ZNZT3XJHRlWqj/nSLFoIdivgffeX54rioxzWjxw6Zvfbtje+9YJiQevKu7WomlOCPR UIu5qDgRACvJ+yl3AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data channel: JavaScript usage of data channel without the Data Channel Protocol? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Feb 2014 10:28:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D16E732ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Richard, Specific applications can decide who opens the data channel, when to start = sending data, etc. Regards, Christer From: Richard Ejzak [mailto:richard.ejzak@gmail.com] Sent: 11. helmikuuta 2014 22:05 To: Christer Holmberg Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Data channel: JavaScript usage of data channel withou= t the Data Channel Protocol? Hi Christer, I didn't see any other response to your question, but please excuse me if I= missed it. My understanding of this case is that if DCEP is not used, the "open" event= is triggered once the browser finishes creating the protocol machinery for= the data channel being created. This is the only mechanism available to a= cknowledge to the JS app that the data channel has been set up since, as yo= u say, the browser will neither send nor receive an open/ack message. I do= n't see any other reasonable alternative to this without API changes. There is a slight problem with this since the peer may not have established= the protocol machinery necessary to actually communicate on the created da= ta channel. Some external mechanism is necessary to verify that both peers= have "opened" the same data channel before either party sends data. See m= y draft on SDP for external negotiation of data channels for a description = of one way to do this. Richard On Thu, Feb 6, 2014 at 5:15 AM, Christer Holmberg > wrote: Hi, As was indicated earlier, the usage of the Data Channel Protocol (DCP) is o= ptional with the Data Channel. However, if I understand the API correctly, only the DCP "open"/"ack" messa= ges will trigger a JavaScript "open" event. If so, how will my JS App be able to use the data channel if I do NOT use t= he Data Channel Protocol? Can I use it without the "open" event, and/or is = there something else that will trigger it? Regards, Christer _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1D16E732ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Richard,

 <= /p>

Specific applications can= decide who opens the data channel, when to start sending data, etc.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

 <= /p>

From: Richard = Ejzak [mailto:richard.ejzak@gmail.com]
Sent: 11. helmikuuta 2014 22:05
To: Christer Holmberg
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Data channel: JavaScript usage of data channel= without the Data Channel Protocol?

 

Hi Christer,

I didn't see any other response to your question, bu= t please excuse me if I missed it.

 

My understanding of this case is that if DCEP is not= used, the "open" event is triggered once the browser finishes cr= eating the protocol machinery for the data channel being created.  Thi= s is the only mechanism available to acknowledge to the JS app that the data channel has been set up since, as you say, the= browser will neither send nor receive an open/ack message.  I don't s= ee any other reasonable alternative to this without API changes.=

 

There is a slight problem with this since the peer m= ay not have established the protocol machinery necessary to actually commun= icate on the created data channel.  Some external mechanism is necessa= ry to verify that both peers have "opened" the same data channel before either party sends data.  See my draft o= n SDP for external negotiation of data channels for a description of one wa= y to do this.

 

Richard

 

On Thu, Feb 6, 2014 at 5:15 AM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

Hi,

 

As was indicated earlier, the usage of the Data Channel Protocol (= DCP) is optional with the Data Channel.

 

However, if I understand the API correctly, only the DCP "ope= n"/"ack" messages will trigger a JavaScript "open"= event.

 

If so, how will my JS App be able to use the data channel if I do = NOT use the Data Channel Protocol? Can I use it without the “openR= 21; event, and/or is there something else that will trigger it?

 

Regards,

 

Christer


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

 

--_000_7594FB04B1934943A5C02806D1A2204B1D16E732ESESSMB209erics_-- From christer.holmberg@ericsson.com Wed Feb 12 02:33: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 3D7A01A0927 for ; Wed, 12 Feb 2014 02:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 IE4lNN9QNIn0 for ; Wed, 12 Feb 2014 02:32:59 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 40E4A1A0922 for ; Wed, 12 Feb 2014 02:32:58 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-c6-52fb4dd8b0da Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4C.0F.23809.8DD4BF25; Wed, 12 Feb 2014 11:32:57 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 11:32:56 +0100 From: Christer Holmberg To: Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] RTCWEB Data Channel Protocol: Label vs Protocol glare Thread-Index: Ac8nUY8MdmECwmXERwuUTRwOK9mRzAATGveAAA/PlKA= Date: Wed, 12 Feb 2014 10:32:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16E756@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D16D248@ESESSMB209.ericsson.se> <52FAF0D9.6040703@alum.mit.edu> In-Reply-To: <52FAF0D9.6040703@alum.mit.edu> 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+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvje5N399BBouOMFqs2HCA1WLtv3Z2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj8fnZjAXfeSq2X33C1MD4ibOLkZNDQsBE YsaWb8wQtpjEhXvr2boYuTiEBA4xSiz7+IcFwlnMKPGuYR57FyMHB5uAhUT3P22QBhEBX4ne y+cYQWxhAW+JCfsnM0PEfST2rDjGClIuImAlcelGKUiYRUBVYs22AywgNi9Qa+PeI2CtQgL5 Et+2nGYHsTkFdCSePmsBsxmB7vl+ag0TiM0sIC5x68l8Jog7BSSW7DkPdbOoxMvH/8BWSQgo Sizvl4Mo15FYsPsTG4StLbFs4WtmiLWCEidnPmGZwCg6C8nUWUhaZiFpmYWkZQEjyypG9tzE zJz0cqNNjMA4OLjlt+oOxjvnRA4xSnOwKInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmD U6qBMbv5ONfemXvPp8y333PFgu9FWOr8r9nXww2q1K/Ixx37y+/qJr8iZd4CZgPxNz35e/wL js49t7TlkKGlxd+89RKr1fOMm22m5xXWhuk/3Rv985/57VWMU+2vrpzze8lq6WNVx5X7ea+m vtpfMCd1vdCV07zczG2HVR5OmcPwX2u5Q8akO8/UjJVYijMSDbWYi4oTASPFVBhRAgAA Subject: Re: [rtcweb] RTCWEB Data Channel Protocol: Label vs Protocol glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Feb 2014 10:33:01 -0000 Hi, >> The draft says: >> >> "Note: There is no attempt to resolve label glare; if both sides open >> >> a Channel labeled "x" at the same time, there will be=20 >> two Channels >> >> labeled "x" - one on an even Stream pair, one on an=20 >> odd pair." >> >> I think the text shall be extended to also cover the Protocol, i.e.=20 >> both ends can try to open a channel for protocol X at the same time. > > And that should be fine. > > Having two channels with the same protocol is analogous to having two aud= io rtp m-lines. ...and sometimes that is what you want. But, in case you only want one chan= nel for protocol X, the basic mechanism doesn't prevent a glare. (Then, as has been discussed, one can do other things from preventing multi= ple channels for the same protocol to be created.) >> Also, even if there is a label glare, it doesn't have to be for the=20 >> same protocol. As far as I know, endpoints can choose whatever label=20 >> value they want, and they don't even need to be for the same protcol=20 >> (unless specific protocols define what label value(s) must be used for=20 >> channels associated with that protocol). > > IIUC the point is for applications to manage the label namespace as they = wish. Assume that you are using application X, and I am using application Y. Both= X and Y support protocol Z. Now, unless protocol Z specifies what label value to use, X and Y may use d= ifferent values. I don't know whether it really matters, but my point was t= hat same label value doesn't by default mean same protocol :) Regards, Christer From internet-drafts@ietf.org Wed Feb 12 09:30: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 499531A0641; Wed, 12 Feb 2014 09:30:09 -0800 (PST) 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 OIl10xZ654kc; Wed, 12 Feb 2014 09:30:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 125FF1A05E5; Wed, 12 Feb 2014 09:30:07 -0800 (PST) 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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140212173007.1383.99485.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2014 09:30:07 -0800 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-14.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, 12 Feb 2014 17:30:09 -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 Use-cases and Requirements Authors : Christer Holmberg Stefan Hakansson Goran AP Eriksson Filename : draft-ietf-rtcweb-use-cases-and-requirements-14.txt Pages : 31 Date : 2014-02-12 Abstract: This document describes web based real-time communication use-cases. Requirements on the browser functionality are derived from the use- cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-use-cases-and-requirements-14 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 stefan.lk.hakansson@ericsson.com Wed Feb 12 09: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 D54981A05E5 for ; Wed, 12 Feb 2014 09:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SofHcaekHaKc for ; Wed, 12 Feb 2014 09:33:52 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 97A891A0376 for ; Wed, 12 Feb 2014 09:33:51 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-05-52fbb07daa00 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 8C.1D.04249.D70BBF25; Wed, 12 Feb 2014 18:33:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 18:33:49 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-14.txt Thread-Index: AQHPKBgor4OHMBnWQ062ciWfW6ykdJqx4DEw Date: Wed, 12 Feb 2014 17:33:48 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CF5699E@ESESSMB209.ericsson.se> References: <20140212173007.1383.99485.idtracker@ietfa.amsl.com> In-Reply-To: <20140212173007.1383.99485.idtracker@ietfa.amsl.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW7dht9BBgcXslqs/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujId/prAW7BCo6F/dy9zA2M7bxcjJISFgIjHrzE5WCFtM4sK9 9WxdjFwcQgJHGCUmHpjMCuEsZpRYPHEtO0gVm0CgxNZ9C9hAbBEBdYnLDy8AxTk4hAXCJY43 p0GEIyTe/tjOCmEbSSyY/ZwNpIRFQFWi96A9SJhXwFfi5eUOsE4hAQeJXf89QcKcAo4S83ds AFvECHTO91NrmEBsZgFxiVtP5jNBnCkgsWTPeWYIW1Ti5eN/UOcrSTQuecIKUa8ncWPqFDYI W1ti2cLXzBBrBSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjBzFqcVJuelGBpsYgUF/cMtv ix2Ml//aHGKU5mBREuf9+NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj8yLHCafNarv+ NH1pO3OTuyKewzGmwVZmyo7/bBzWpZv4hb8V/m1Y+aPiTSePu8GpLULxi/n2zbD4/fTRbr4N 9so5ltcmPHj3Lk26ta01/5bquzOqF/kuXN1mc+6PRvXRtZ1+ctP956pt/HEq5Vt/iqbcDo2T M3U5b/Yc3vUoyPrrg75e3UdZSizFGYmGWsxFxYkAd5OiFkgCAAA= Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-14.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, 12 Feb 2014 17:33:54 -0000 New for this version: * The requirements are spelled out as they are derived in each use-case * The requirements are put in categories * Updated the note about that other mechanisms than ICE/STUN/TURN are allow= ed for nat/fw traversal I'm not sure if there is anything more that needs to be fixed. Stefan -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: den 12 februari 2014 18:30 To: i-d-announce@ietf.org Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-= 14.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : Web Real-Time Communication Use-cases and Require= ments Authors : Christer Holmberg Stefan Hakansson Goran AP Eriksson Filename : draft-ietf-rtcweb-use-cases-and-requirements-14.txt Pages : 31 Date : 2014-02-12 Abstract: This document describes web based real-time communication use-cases. Requirements on the browser functionality are derived from the use- cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requiremen= ts/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-use-cases-and-requirem= ents-14 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. 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 Raju.Makaraju@alcatel-lucent.com Wed Feb 12 10:51: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 2F8981A0658 for ; Wed, 12 Feb 2014 10:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 gYjSWm0CEjyZ for ; Wed, 12 Feb 2014 10:51:35 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D2A7F1A062C for ; Wed, 12 Feb 2014 10:51:31 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1CIpMWE020673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 12:51:22 -0600 (CST) 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 s1CIpLxe010223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 13:51:21 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 12 Feb 2014 13:51:21 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , "'Peter Thatcher'" Thread-Topic: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare Thread-Index: Ac8mR2/m3LFj8oi+SFKLxbYiytu9PAAK7dsAAAArXYAAAIL7AAAB71EAAAtYFoAAB6VPygAtEOOAAACWDgAAAFfEgAAA+4iAACYhi7A= Date: Wed, 12 Feb 2014 18:51:20 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se> <4616BFFA-F461-4CE8-9D85-211B86D4BE93@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166D7B@ESESSMB209.ericsson.se> <71288EED-3C82-44A7-950B-EFEFA62616E6@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D166F8C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D167A2E@ESESSMB209.ericsson.se> <52F9786F.60809@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D16D2F3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D16D3C2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D16D3C2@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_E1FE4C082A89A246A11D7F32A95A17826DFDC655US70UWXCHMBA02z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "" Subject: Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Feb 2014 18:51:38 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17826DFDC655US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+SG93ZXZlciwgYXMgaXMgYWxzbyBpbmRpY2F0ZWQsIHRoZSBkcmFmdCBkb2VzIG5vdCBwcm92 aWRlIGEgbWVjaGFuaXNtIHRvIHByZXZlbnQvaGFuZGxlIHN1Y2ggZ2xhcmUgPnNpdHVhdGlvbi4N Cg0KPkkgcGVyc29uYWxseSB0aGluayB0aGVyZSBzaGFsbCBiZSBhIHdheSB0byBwcmV2ZW50IHN1 Y2ggc2l0dWF0aW9uLCBvciBvdGhlcndpc2UgSSdtIHN1cmUgd2UgYXJlIGdvaW5nID50byBlbmQg dXAgd2l0aCBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLg0KW1JhanVdIFRoZSB3aG9sZSBkaXNj dXNzaW9uIGlzIGFib3V0IOKAnFByZXZlbnQgREFUQV9DSEFOTkVMX09QRU4gZ2xhcmXigJ0uIEkg ZG9u4oCZdCB0aGluayB3ZSBzaG91bGQgY2FsbCBpdCBhIGdlbmVyYWwg4oCcZ2xhcmXigJ0gc2l0 dWF0aW9uLiBEQ1AganVzdCBwcm92aWRlcyBhIHdheSB0byBvcGVuIHJhdyBkYXRhIGNoYW5uZWxz IHdpdGggYm90aCBzaWRlcyB1c2luZyBzYW1lIHN0cmVhbSBpZCwgdGhhdOKAmXMgYWxsLiBSZXN0 IG9mIHRoZSBzZW1hbnRpY3MgZm9yIHR5aW5nIGEgZGF0YSBjaGFubmVsIHRvIGEgcGFydGljdWxh ciB1c2UgaXMgY29tcGxldGVseSBkZWZpbmVkIGJ5IGFwcGxpY2F0aW9uLiBUaGUg4oCccHJvdG9j b2zigJ0gZmllbGQgaXRzZWxmIGlzIG5vdCBzdWZmaWNpZW50IHRvIGhhdmUgdW5pcXVlbmVzcyBh dCB0aGUgYXBwbGljYXRpb24gbGV2ZWwgYXMgdGhlcmUgY291bGQgYmUgbXVsdGlwbGUgZGF0YSBj aGFubmVscyB1c2luZyB0aGUgc2FtZSBwcm90b2NvbC4gTVNSUCBhcHBsaWNhdGlvbiBpcyBhbiBl eGFtcGxlIHdoZXJlIE1TUlAgY291bGQgYmUgdXNlZCBmb3IgY2hhdCwgZmlsZSB0cmFuc2ZlciBl dGMuIFRoZSBsYWJlbCBjYW4gYmUgdXNlZCBieSBhcHBsaWNhdGlvbiB0byBoYXZlIHVuaXF1ZW5l c3MuIEJ1dCB0aGUgc21hcnRzIG5lZWQgdG8gYmUgaW4gdGhlIGFwcGxpY2F0aW9uIGluIGdlbmVy YWwgYXMgd2hlbiB0byBvcGVuIGRhdGEgY2hhbm5lbHMgYW5kIHdoYXQgZG8gdGhleSBtZWFuPyBT b21lIGFwcGxpY2F0aW9ucyBsaWtlIE1TUlAgZG8gbm90IG5lZWQgdG8ga25vdyBpZiB0aGUgZGF0 YSBjaGFubmVsIHN1Yi1wcm90b2NvbCtsYWJlbHMgYXJlIHVuaXF1ZSBvciBub3QuIE90aGVyIGFw cGxpY2F0aW9ucyBsaWtlIGdhbWluZyBtYXkgaGF2ZSBhIG5lZWQgZm9yIG9uZSBxdWlxdWUgZ2Ft ZSBjb250cm9sIGNoYW5uZWwsIG9wZW5lZCBieSBlaXRoZXIgc2lkZS4gVG8gYWNoaWV2ZSB0aGlz LCB0aGUgYXBwbGljYXRpb24gbmVlZHMgdG8gaGF2ZSBhIGRldGVybWluaXN0aWMgYWxnb3JpdGht IHdpdGggZWl0aGVyIG91dC1vZi1iYW5kIHNpZ25hbGluZyAoY291bGQgYmUgdXNpbmcgb25lIG9m IHRoZSBkYXRhIGNoYW5uZWxzIGFzIG1hc3RlciBjb250cm9sIGNoYW5uZWwgYnkgaW5pdGlhdG9y KSBvciBieSBhIHNpbXBsZSDigJxvZmZlcmVyIG9wZW5zIHRoZSBjb250cm9sIGNoYW5uZWzigJ0u DQoNClNvLCBpbiBzdW1tYXJ5IEkgZG9u4oCZdCB0aGluayBhbnkgc3BlY2lmaWMgbm90ZXMgYXJl IG5lZWRlZCBpbiBEQ1AgZm9yIHRoaXMgb3RoZXIgdGhhbiBzYXlpbmcg4oCcaXQgaXMgdXB0byB0 aGUgYXBwbGljYXRpb24gdG8gdGllIHNlbWFudGljcyBvZiBkYXRhIGNoYW5uZWwgdXNl4oCdLCB3 aGljaCBJIHRoaW5rIGlzIGluaGVyZW50IGJ5IGRlZmF1bHQuDQoNCi1SYWp1DQoNCg0K --_000_E1FE4C082A89A246A11D7F32A95A17826DFDC655US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy IDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0O0hvd2V2ZXIsIGFzIGlzIGFsc28gaW5k aWNhdGVkLCB0aGUgZHJhZnQgZG9lcyBub3QgcHJvdmlkZSBhIG1lY2hhbmlzbSB0byBwcmV2ZW50 L2hhbmRsZSBzdWNoIGdsYXJlICZndDtzaXR1YXRpb24uPGJyPg0KPGJyPg0KJmd0O0kgcGVyc29u YWxseSB0aGluayB0aGVyZSBzaGFsbCBiZSBhIHdheSB0byBwcmV2ZW50IHN1Y2ggc2l0dWF0aW9u LCBvciBvdGhlcndpc2UgSSdtIHN1cmUgd2UgYXJlIGdvaW5nICZndDt0byBlbmQgdXAgd2l0aCBp bnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+W1JhanVdIFRoZSB3aG9sZSBkaXNjdXNzaW9u IGlzIGFib3V0IOKAnFByZXZlbnQgREFUQV9DSEFOTkVMX09QRU4gZ2xhcmXigJ0uIEkgZG9u4oCZ dCB0aGluayB3ZSBzaG91bGQgY2FsbCBpdCBhIGdlbmVyYWwg4oCcZ2xhcmXigJ0gc2l0dWF0aW9u LiBEQ1AganVzdCBwcm92aWRlcyBhIHdheSB0byBvcGVuIHJhdyBkYXRhIGNoYW5uZWxzIHdpdGgg Ym90aCBzaWRlcyB1c2luZyBzYW1lIHN0cmVhbQ0KIGlkLCB0aGF04oCZcyBhbGwuIFJlc3Qgb2Yg dGhlIHNlbWFudGljcyBmb3IgdHlpbmcgYSBkYXRhIGNoYW5uZWwgdG8gYSBwYXJ0aWN1bGFyIHVz ZSBpcyBjb21wbGV0ZWx5IGRlZmluZWQgYnkgYXBwbGljYXRpb24uIFRoZSDigJxwcm90b2NvbOKA nSBmaWVsZCBpdHNlbGYgaXMgbm90IHN1ZmZpY2llbnQgdG8gaGF2ZSB1bmlxdWVuZXNzIGF0IHRo ZSBhcHBsaWNhdGlvbiBsZXZlbCBhcyB0aGVyZSBjb3VsZCBiZSBtdWx0aXBsZSBkYXRhIGNoYW5u ZWxzIHVzaW5nDQogdGhlIHNhbWUgcHJvdG9jb2wuIE1TUlAgYXBwbGljYXRpb24gaXMgYW4gZXhh bXBsZSB3aGVyZSBNU1JQIGNvdWxkIGJlIHVzZWQgZm9yIGNoYXQsIGZpbGUgdHJhbnNmZXIgZXRj LiBUaGUgbGFiZWwgY2FuIGJlIHVzZWQgYnkgYXBwbGljYXRpb24gdG8gaGF2ZSB1bmlxdWVuZXNz LiBCdXQgdGhlIHNtYXJ0cyBuZWVkIHRvIGJlIGluIHRoZSBhcHBsaWNhdGlvbiBpbiBnZW5lcmFs IGFzIHdoZW4gdG8gb3BlbiBkYXRhIGNoYW5uZWxzIGFuZCB3aGF0DQogZG8gdGhleSBtZWFuPyBT b21lIGFwcGxpY2F0aW9ucyBsaWtlIE1TUlAgZG8gbm90IG5lZWQgdG8ga25vdyBpZiB0aGUgZGF0 YSBjaGFubmVsIHN1Yi1wcm90b2NvbCYjNDM7bGFiZWxzIGFyZSB1bmlxdWUgb3Igbm90LiBPdGhl ciBhcHBsaWNhdGlvbnMgbGlrZSBnYW1pbmcgbWF5IGhhdmUgYSBuZWVkIGZvciBvbmUgcXVpcXVl IGdhbWUgY29udHJvbCBjaGFubmVsLCBvcGVuZWQgYnkgZWl0aGVyIHNpZGUuIFRvIGFjaGlldmUg dGhpcywgdGhlIGFwcGxpY2F0aW9uDQogbmVlZHMgdG8gaGF2ZSBhIGRldGVybWluaXN0aWMgYWxn b3JpdGhtIHdpdGggZWl0aGVyIG91dC1vZi1iYW5kIHNpZ25hbGluZyAoY291bGQgYmUgdXNpbmcg b25lIG9mIHRoZSBkYXRhIGNoYW5uZWxzIGFzIG1hc3RlciBjb250cm9sIGNoYW5uZWwgYnkgaW5p dGlhdG9yKSBvciBieSBhIHNpbXBsZSDigJxvZmZlcmVyIG9wZW5zIHRoZSBjb250cm9sIGNoYW5u ZWzigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOnJlZCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+U28sIGluIHN1bW1hcnkgSSBkb27i gJl0IHRoaW5rIGFueSBzcGVjaWZpYyBub3RlcyBhcmUgbmVlZGVkIGluIERDUCBmb3IgdGhpcyBv dGhlciB0aGFuIHNheWluZyDigJxpdCBpcyB1cHRvIHRoZSBhcHBsaWNhdGlvbiB0byB0aWUgc2Vt YW50aWNzIG9mIGRhdGEgY2hhbm5lbCB1c2XigJ0sIHdoaWNoIEkgdGhpbmsgaXMgaW5oZXJlbnQg YnkgZGVmYXVsdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6cmVkIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4tUmFqdTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E1FE4C082A89A246A11D7F32A95A17826DFDC655US70UWXCHMBA02z_-- From Raju.Makaraju@alcatel-lucent.com Wed Feb 12 10:57: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 506D31A062C for ; Wed, 12 Feb 2014 10:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 fbM8LTvL_SfI for ; Wed, 12 Feb 2014 10:57:03 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id F1D241A05D3 for ; Wed, 12 Feb 2014 10:57:02 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1CIuwNC026043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 12:56:59 -0600 (CST) 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 s1CIuvQT024956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 13:56:58 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 12 Feb 2014 13:56:57 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Comment on section 6 title Thread-Index: AQHPJ6d4H7mvcIJig0awnYUwxolMB5qxvYWAgAA6rWA= Date: Wed, 12 Feb 2014 18:56:56 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D16D2BA@ESESSMB209.ericsson.se> <52FAF2A9.9070507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D16E5F0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D16E5F0@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Comment on section 6 title X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Feb 2014 18:57:05 -0000 > Hi, >=20 > > I suggest that this just be called "Data Channel", not "WebRTC Data > Channel". (Or pick some other neutral name - perhaps SCTP Data Channel.) >=20 > Agree. A more generic name would be useful. >=20 > "Simple Data Channel" > "Simple SCTP Data Channel" > Etc... [Raju] How about "Application Data Channel"? > (But it would still make sense for the JS API to have a WebRTC-specific n= ame.) +1 -raju From suhasietf@gmail.com Wed Feb 12 14: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 EE8F01A0013 for ; Wed, 12 Feb 2014 14:27:52 -0800 (PST) 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 msqhVotJCSec for ; Wed, 12 Feb 2014 14:27:51 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id D5F3F1A0018 for ; Wed, 12 Feb 2014 14:27:50 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id f8so7689611wiw.9 for ; Wed, 12 Feb 2014 14:27:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0NN83eQ88eujGYQclCPnvouyus8F0O3lXZ383y6MRm4=; b=N2vTOXp/iCdu73A1emqPY3wcPqrMOiw/3JFGlb98nVImr5yD1aLqSQdKPlrt3x7R5/ 6SaI+NXs9tqknUCZtOwks3aU16RYQ4bmceVsWL6nFs2z3KJK+bc5pgrQI8lvUfwWCNYJ fX143cKOnjNkXfZKlWy6/VbnsXahCpU4rMgzGLYSDLiFtXgTyiAZl5dVgkYcPjzgi0pc 8/5iGuPjvZafdtdhI7oYxjlAvEdbs/JKx9CiQ41tXpu5WJ+VgmylMbbSHDMEphoP8kbD MDsfFF8oCBVOcUT07pyopHR+qcxKGCjNNAbeEU8RL1+fLDeXGcC2CGJlSO41p9lJdkwu bRHQ== MIME-Version: 1.0 X-Received: by 10.195.13.103 with SMTP id ex7mr3503735wjd.3.1392244069341; Wed, 12 Feb 2014 14:27:49 -0800 (PST) Received: by 10.195.12.134 with HTTP; Wed, 12 Feb 2014 14:27:49 -0800 (PST) In-Reply-To: <37D91FC30D69DE43B61E5EEADD959F180D07F5BB@xmb-aln-x12.cisco.com> References: <20140212222141.13560.95980.idtracker@ietfa.amsl.com> <37D91FC30D69DE43B61E5EEADD959F180D07F5BB@xmb-aln-x12.cisco.com> Date: Wed, 12 Feb 2014 14:27:49 -0800 Message-ID: From: Suhas Nandakumar To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7bfceb1a31cd9704f23d1510 Subject: [rtcweb] Fwd: FW: New Version Notification for draft-nandakumar-rtcweb-sdp-04.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, 12 Feb 2014 22:27:53 -0000 --047d7bfceb1a31cd9704f23d1510 Content-Type: text/plain; charset=ISO-8859-1 Hello All A new version of WebRTC SDP Examples draft has been submitted. The attempt with this version is to closely align with the JSEP document. URL: http://www.ietf.org/internet-drafts/draft-nandakumar-rtcweb-sdp-04.txt Please let us know your inputs and comments. Cheers Suhas --047d7bfceb1a31cd9704f23d1510 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello All

A new version of WebRTC SDP Examples draft=A0has been submitted. The attemp= t with this version is to closely align with the JSEP document.
Please let us know your inputs a= nd comments.

Cheers
Suhas

--047d7bfceb1a31cd9704f23d1510-- From cb.list6@gmail.com Wed Feb 12 22:07: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 2E2BE1A00F5 for ; Wed, 12 Feb 2014 22:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 T_4N9ryvSgIf for ; Wed, 12 Feb 2014 22:06:59 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7B31A0102 for ; Wed, 12 Feb 2014 22:06:58 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u56so7021443wes.16 for ; Wed, 12 Feb 2014 22:06:57 -0800 (PST) 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=6mT3zt8FutaGIVIF/hoBjL0LzQNTmoarFh9JoueleDI=; b=S4gvTFvzi/SYzXawHCfabFRoMOdLQ3SQD1XI16fLazsJduz4ULPnTMnEJ/VJmWQlE2 0/YGUQyMcpYUos4j3slx+GcsIwXh1YC2oeY1Y2qUggVcdhfTtguJXP9wxmkqXQAtT+B8 605QQe7z7w0is+bl6GkRmfjVKlqt3CazgbD/xE1oRYeqIbQeHMtWjmWAMskUSdk27+9V 9bFG1hd23AC3qxkflkjZi66q6Ms5PFcdtdo3AKblJYsUtd+N+Flm0BEW6HRe16E12Xlr suV95l2new9TityOrDSUkpITU28zgVmUsKpJvitAWesoK66zQvnkBIfTizYL9bOPuT9T XXIA== MIME-Version: 1.0 X-Received: by 10.180.105.41 with SMTP id gj9mr4976788wib.28.1392271616998; Wed, 12 Feb 2014 22:06:56 -0800 (PST) Received: by 10.194.133.169 with HTTP; Wed, 12 Feb 2014 22:06:56 -0800 (PST) Date: Wed, 12 Feb 2014 22:06:56 -0800 Message-ID: From: Cb B To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 06:07:01 -0000 Folks, For about a year now, i have been very concerned about IPv4 UDP. It has been increasingly associated with DDoS traffic [1], to the point that the protocol's reputation is akin to IPv4 PING in 2003 (widely blocked). The material point here is that IPv4 UDP is being indiscriminately blocked and policed in access networks. This is not something access networks are wantonly electing to do. This decision is made in the heat of the moment to restore service to customers and networks who are overrun with attack traffic [2]. And it is not simply DNS, NTP, and chargen for simple filtering. My suggestion is that draft-ietf-rtcweb-transports be updated to include SCTP as a transport type option. I understand that SCTP is not supported on Windows (tm) and most NATs. In general, we may find that TURN / TRAM is a required local trust anchor in access networks, just as local ISP-administered SMTP servers in access networks are frequently required relay points since access networks block SMTP. [3] This UDP concern is not an issue for IPv6, since IPv6 is not, as of yet, been associated with these massive attacks. And when i say massive, i mean massive [4]. And because of the scale and risk, access networks are simply clamping IPv4 UDP throughput and moving on and not looking back. I understand predicting the demise of UDP is not a popular opinion in the IETF. But as a network operator, and stakeholder in the internet / ietf / webrtc, i am hoping to share this information so that you all can make well informed protocol decisions. [1] http://www.us-cert.gov/ncas/alerts/TA14-017A [2] http://www.gossamer-threads.com/lists/nanog/users/168576 [3] http://customer.comcast.com/help-and-support/internet/email-port-25-no-longer-supported/ [4] http://rt.com/news/biggest-ddos-us-cloudflare-557/ From magnus.westerlund@ericsson.com Thu Feb 13 00:15: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 BFF3F1A0169 for ; Thu, 13 Feb 2014 00:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 vh-3eG1zYWiS for ; Thu, 13 Feb 2014 00:15:01 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A6F0D1A0113 for ; Thu, 13 Feb 2014 00:15:00 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-62-52fc7f028243 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B8.AF.23809.20F7CF25; Thu, 13 Feb 2014 09:14:58 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.2.347.0; Thu, 13 Feb 2014 09:14:57 +0100 Message-ID: <52FC7F01.7090406@ericsson.com> Date: Thu, 13 Feb 2014 09:14:57 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Ram Mohan R (rmohanr)" , "rtcweb@ietf.org" References: <5285E318.3090006@ericsson.com> <913383AAA69FF945B8F946018B75898A2428EC28@xmb-rcd-x10.cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Rpep/k+QwZtPIhbLu3YwWqz9187u wOQx5fdGVo8lS34yBTBFcdmkpOZklqUW6dslcGWce/aGtWCDasXtx08YGxh3yHYxcnBICJhI nJkX1cXICWSKSVy4t56ti5GLQ0jgEKPEqz9HWCGc5YwSEzddZgap4hXQlth97SOYzSKgKrHk z18mEJtNwELi5o9GNhBbVCBYYueB34wQ9YISJ2c+YQGxRQTCJKafWABmCwu4SCyecZIZYsEm RokVE/pZQRKcAvoSHz8cZ4S4TlyipzEIJMwsoCcx5WoLI4QtL9G8dTbYDUJA9zQ0dbBOYBSc hWTdLCQts5C0LGBkXsXInpuYmZNebrSJERiSB7f8Vt3BeOecyCFGaQ4WJXHeD2+dg4QE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUw7l5/IYYn8PL5BK656t1nv5TZGry6EXaV+Z3U7vtNNj1J PyfvsXm1Wkzo2LKcrwUXW6cu4LOxn/z464m1B5tEpMWseFY/KdBUlDj4TPvk9Jnii212ndpa pm4tmOYW7ajIHHbtA9djq7Wim842LpX54L/yckJz/nkJhr8ccm9l7Nb0/v8ke+9UuBJLcUai oRZzUXEiAF8t8z4XAgAA Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-stun-consent-freshness-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 08:15:05 -0000 Hi, (As individual) removing the parts that appears resolved. On 2014-02-05 07:19, Ram Mohan R (rmohanr) wrote: >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> On 2013-11-14 18:23, Ram Mohan R (rmohanr) wrote: >>> From: Magnus Westerlund > > > >> >> >>>> >>>> 8. Section 4: >>>> If a valid STUN Binding Response is not received after 500ms, the >>>> STUN Binding Request is retransmitted (with the same Transaction ID >>>> and all other fields). As long as a valid STUN Binding Response is >>>> not received, this retransmission is repeated every 500ms until Tf >>>> seconds have elapsed or a valid response is received. >>>> >>>> So no exponential back-off on the retransmission timer. I think that >>>> is fine. However, I think it do require you to expand a bit on what >>>> happens when one gets multiple response on the same Transaction ID. >>>> For example additional responses do they or do they not reset the Tc >>>> timer? >>> >>> Additional responses MUST reset the Tc timer. >>> >> >> Okay, that appears fine. >> >>> >>>> >>>> Then I wonder about the cases where the RTT is above 500 ms, should >>>> one then scale this factor to be once per RTT? >> >> What about this question? > > The ICE agent can learn the RTT of a given path from RTCP reports (if > present). If there is no RTCP reports then it can use STUN BindReq/Res to > learn RTT. > > STUN allows you to learn the RTT of a path when you sending Binding > request and get a Binding response for a candidate pair. Before consent > timer > is started the browser¹s ICE agent would have done ICE checks and > concluded on a candidate for each media stream. So an ICE agent can use > the RTT learnt here. > Thoughts on this ? I think using the STUN connectivity checks to gather an RTT estimate is fine for this and likely the easiest. That avoids the need to have the RTCP stack closely integrated with the consent mechanism. And if I understand each new request has a new Transaction ID, that way one can keep a running filtered RTT estimate to use for this. But, I do believe that we should ha a mechanism in place to protect against RTTs > 500 ms. In buffer bloat case, as well as certain paths they do occur. > > >> >>>> >>>> 9. Section 4: >>>> "with the same Transaction ID" >>>> >>>> Why not use a new transaction ID for each sent packet? It would allow >>>> tracking loss and determine RTT more reliable. All for the small cost >>>> of keeping track of slightly more Transaction IDs? >>> >>> Yes, new transaction ID will help to determine the packet loss and RTT. >>> >> >> Yes, so what is preferable here? Doing cloned retransmission, or >> generating new TIDs for each outgoing request? > > Using same Transaction ID would lead the peer ICE agent think this request > as a retransmission and it may not reset its Consent timer. So I think > using new ID is better. Good, lets use a new TID. > > > >> >>> >>> >>>> >>>> 10. Section 4. >>>> Liveness timer: If no packets have been received on the local port in >>>> Tr seconds, the WebRTC browser MUST inform the JavaScript that >>>> connectivity has been lost. The JavaScript application will use this >>>> notification however it desires (e.g., cease transmitting to the >>>> remote peer, provide a notification to the user, etc.). Note the >>>> definition of a received packet is liberal, and includes an SRTP >>>> packet that fails authentication, a STUN Binding Request with an >>>> invalid USERNAME or PASSWORD, or any other packet. >>>> >>>> I think this requires some considerations in regards to RTT. If the >>>> RTT is 700 ms, high for a real-time app but not unheard of at all. >>>> Then a Tr = 1 second would fire on a single loss. >>> >>> Ok. will start a discussion for this item in a separate email. >>> > > As discussed above the ICE agent can learn the RTT of a given path from > RTCP reports (if present) or compute the RTT from STUN BindReq/Response. > It can then use the learnt value > to influence the Tr value. I will leave it to you to consider how to use and specify a proposal for this. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Feb 13 00:41: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 053811A0169 for ; Thu, 13 Feb 2014 00:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 r3P-0BRIxgMt for ; Thu, 13 Feb 2014 00:41:34 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8E85F1A016F for ; Thu, 13 Feb 2014 00:41:33 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-41-52fc853bfd32 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E2.C3.23809.B358CF25; Thu, 13 Feb 2014 09:41:32 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.2.347.0; Thu, 13 Feb 2014 09:41:31 +0100 Message-ID: <52FC853B.60904@ericsson.com> Date: Thu, 13 Feb 2014 09:41:31 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Randell Jesup , References: <5280E181.20104@ericsson.com> <9A62A3AC-F990-4358-B2E7-B8DD39A81B03@fh-muenster.de> <52FAD6EE.3070807@jesup.org> In-Reply-To: <52FAD6EE.3070807@jesup.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3Rtem9U+QwYTtTBZnt2VZrP3Xzu7A 5LFkyU8mjw/L17EFMEVx2aSk5mSWpRbp2yVwZbza08xW0CFcMfvWDPYGxo38XYycHBICJhIL N31jhrDFJC7cW8/WxcjFISRwiFHiw7/djBDOckaJjTPfMIJU8QpoSly69wqsg0VAVeJH51dW EJtNwELi5o9GNhBbVCBYYueB31D1ghInZz5hAbFFBGwl3v3ZAFYjLOAs0fD3DlivkECNxKEF 88FsTqD5+79+BprPAXSRuERPYxBImFlAT2LK1RZGCFteonnrbGaIVm2JhqYO1gmMgrOQbJuF pGUWkpYFjMyrGNlzEzNz0suNNjECA/Lglt+qOxjvnBM5xCjNwaIkzvvhrXOQkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBsbuBVKX858G27xht7TraXA0eXZX7ne89undQlen/tp3KGUlH3P7 +sIYSzXBEhFuu11qR5fXxT9xkr2/QcHmxuw1/MtNWsMf/07ccm06RwH/ux23Xk/K/qUneiD0 8/2Cq6pPT7fsS7d/84Jt28rlrhvi9u8SXJVgprTawftIoQS/YnFZoITOi8NKLMUZiYZazEXF iQCiS3VEFgIAAA== Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 08:41:36 -0000 Hi, Just responding to one thing. I will have a goal to review the new versions prior to the WG session to see how well the new version resolves my previous comments. On 2014-02-12 03:05, Randell Jesup wrote: > On 2/11/2014 5:47 AM, Michael Tuexen wrote: >> On Nov 11, 2013, at 2:54 PM, Magnus Westerlund >> wrote: >> >> >>> 3. Section 3.2: >>> U-C 7: Proxy browsing, where a browser uses data channels of a >>> PeerConnection to send and receive HTTP/HTTPS requests and data, >>> for example to avoid local internet filtering or monitoring. >>> >>> Yes, this may be something that is possible, but to express it as a use >>> cases intended to be supported might not be the best. We are after all >>> likely talking about circumventing local security policies. I would also >>> note that "Internet" is with capital I. >> Change to Internet. The use case seems important, since there are already >> implementations doing this (possibly not using data channels, don't >> know). >> Randell: What do you think? > > There are people actively planning to use it for this usecase in > high-profile applications (using datachannels), or so I am told. Okay, this is going to be causing issue, independent on if you include the use case explicitly or not. Please discuss this security concerns in the security consideration section. From my perspective this has several implications. 1. Violating a sites security policy. Can this be detected, controlled or prevented somehow without generally blocking the data channel or even DTLS in general? 2. What privacy implications does this have? You are putting your proxied traffic into another browser instances JS code space. Thus isn't that browser going to have full insight in what the first browser is doing, including content coming over a HTTPS from the proxy to the. This has significant trust issues. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Feb 13 00:46: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 9A2CF1A0177 for ; Thu, 13 Feb 2014 00:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 6yowRQiVoA4o for ; Thu, 13 Feb 2014 00:46:27 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E4E141A0085 for ; Thu, 13 Feb 2014 00:46:26 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-fd-52fc86611885 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6F.94.23809.1668CF25; Thu, 13 Feb 2014 09:46:25 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.347.0; Thu, 13 Feb 2014 09:46:24 +0100 Message-ID: <52FC8660.3030901@ericsson.com> Date: Thu, 13 Feb 2014 09:46:24 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= , "rtcweb@ietf.org" References: <20140212173007.1383.99485.idtracker@ietfa.amsl.com> <1447FA0C20ED5147A1AA0EF02890A64B1CF5699E@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1CF5699E@ESESSMB209.ericsson.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+JvjW5i258gg643YhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9rqzYwFDzgqFjx4xdjA2M/excjBISFgIjF9pn0XIyeQKSZx 4d56ti5GLg4hgUOMEhM3LmCBcJYzSkyZ8IUdpIpXQFvi+5pfjCA2i4CqxKwPe1lAbDYBC4mb PxrZQGxRgWCJnQd+M0LUC0qcnPkErEZEoETiyvkDTCC2sECoxN0dU8HqhQSaGCUW/tcFsTkF /CQ+dX9ihThOXKKnMQgkzCygJzHlagsjhC0v0bx1NjNEq7ZEQ1MH6wRGwVlIts1C0jILScsC RuZVjOy5iZk56eVGmxiBwXdwy2/VHYx3zokcYpTmYFES5/3w1jlISCA9sSQ1OzW1ILUovqg0 J7X4ECMTB6dUA2N38Y8J+i+fvLoj8Ci16svVXB3JFMGgo9dYN/aWaKWL7BC9HSfyU+dVc0o9 63r7Bcs7FkmWf1ac82LPB+FJwdz65W2sU66lhTB+unJk28wjPGf/ewUfeMq+vqLp9LGQJW9P L30kL9ZSb35+4bI/nL2Pt7/6yON04eWWmuJidefFMes3Xs3i5hBQYinOSDTUYi4qTgQALtPq LAwCAAA= Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-14.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, 13 Feb 2014 08:46:29 -0000 On 2014-02-12 18:33, Stefan Håkansson LK wrote: > New for this version: > > * The requirements are spelled out as they are derived in each use-case > * The requirements are put in categories > * Updated the note about that other mechanisms than ICE/STUN/TURN are allowed for nat/fw traversal > > I'm not sure if there is anything more that needs to be fixed. Thanks, I think especially the first is helping readability significant. I intended to publication request this next week (On the 20th of Feb) unless a consensus appear to emerge around the change Partha requested or some significant issue is raised. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Feb 13 01:05: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 DE6511A01B6; Thu, 13 Feb 2014 01:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, 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 h8kVPa9nfwdO; Thu, 13 Feb 2014 01:05:51 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 21F071A018B; Thu, 13 Feb 2014 01:05:50 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-43-52fc8aedd2a7 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F5.B2.10875.DEA8CF25; Thu, 13 Feb 2014 10:05:49 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.2.347.0; Thu, 13 Feb 2014 10:05:47 +0100 Message-ID: <52FC8AEB.6020906@ericsson.com> Date: Thu, 13 Feb 2014 10:05:47 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti , Jonathan Lennox References: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+Jvje7brj9BBkt3KVl0TGazOHHjNLPF /sXnmS22ThWymLr8MYvF2n/t7A5sHlN+b2T1WLCp1GPJkp9MHm3P7rAHsERx2aSk5mSWpRbp 2yVwZfza08RUsI+rYu2l62wNjNs5uhg5OSQETCTOXP/BBGGLSVy4t56ti5GLQ0jgEKPEvfYm RghnOaNE4+sOsCpeAW2J771P2UFsFgFVifeL5rGC2GwCFhI3fzSygdiiAsESOw/8ZoSoF5Q4 OfMJSxcjB4eIgI/Em02CIDOZBboZJS4e6gGrERawlFgzu40dYtkeJom587eAJTgFAiWmr+pk AmmWEBCX6GkMAgkzC+hJTLnawghhy0s0b53NDGILAd3W0NTBOoFRaBaS1bOQtMxC0rKAkXkV I3tuYmZOernhJkZgiB/c8lt3B+OpcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwKgWut7jq/6/Ds9u8WglvueC9xKPiIvlralaVS3ALV+qbCfQdEV126HjYh+Mb/a+ OrtqnsXp/MvNy31P2m4ti+jlu/oj+1dV172MrQpLbLPfTngVHtN1RSbSU1Y8x511Ov/Knp33 Izd4FC7X2Hgr21PoH+vWL1zP5OW47rZtP9UYrPyvWWjffyWW4oxEQy3mouJEALB1gMY/AgAA Cc: Cullen Jennings , Harald Alvestrand , "rtcweb@ietf.org" , mmusic Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 09:05:55 -0000 On 2014-02-04 01:05, Justin Uberti wrote: > > Agree that msid should map m-line to MST, but it would seem recv-msid > could map RTP flow to m=line as well as indicate whether the receiver is > in fact interested in receiving the MST associated with said m= line. > Note that recv-msid doesn't specify an actual MSID; its purpose is to > indicate that the receiver wants to receive data from the remote side's > MST, and provide a mechanism for the sender to mark the data > accordingly. (Which ends up seeming a lot like appid.) > A question here, what are you really trying to reject? Is it the MST, a particular RTP Stream (Id by SSRC) or the usage of this media description (m= block) in a particular direction (i.e. SDP internal)? I think the solution differs quite a lot depending on what you really try to accomplish. cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ted.ietf@gmail.com Thu Feb 13 07:50: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 25ABF1A0294 for ; Thu, 13 Feb 2014 07:50:40 -0800 (PST) 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 sVNO5BfCtZZH for ; Thu, 13 Feb 2014 07:50:38 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC281A02C8 for ; Thu, 13 Feb 2014 07:50:38 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id c10so13067517igq.0 for ; Thu, 13 Feb 2014 07:50:37 -0800 (PST) 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=QjUaSR9C6knnOJaCUhXLTTAdXItURhdKO9OnvZ8JFHk=; b=Ovl6y80jqp/gOBTEW2SVPmH8F99mWbTa9297dWxaqxsB0rMzXJ/hCojCRgx338NqbI BcWeBdnQd+D3txBg5ZoYFEJ+yx8+FgMy8dSCIuUm6ROaR69tYIL2nlLg0ffNjNG6nCl/ DekR+C6q5EeRZHDDSND100hIVjuCfrxNPZF1Sf9nysNfZqZp8nvp91B8h4tFBQ5jV+TX CRWAfSDB64Pjmd7fqvlisIZF0TrcBa9ul/y0+YuSlNw/OvqxjMhgULHIn4myVXHnqMOF jvHhoxnd2EvPznWImh2oh4eXi8oYgMw9AsayoqAXrfoQXx9DsTJKTiPA3+ngGKmivU0/ otDA== MIME-Version: 1.0 X-Received: by 10.50.25.33 with SMTP id z1mr4159853igf.6.1392306637130; Thu, 13 Feb 2014 07:50:37 -0800 (PST) Received: by 10.42.237.206 with HTTP; Thu, 13 Feb 2014 07:50:37 -0800 (PST) Date: Thu, 13 Feb 2014 07:50:37 -0800 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Adam Roach , Cullen Jennings , Magnus Westerlund Content-Type: multipart/alternative; boundary=047d7bd74b10865b6904f24ba621 Subject: [rtcweb] Video draft author X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 15:50:40 -0000 --047d7bd74b10865b6904f24ba621 Content-Type: text/plain; charset=ISO-8859-1 Howdy, As folks know, we have suspended discussion of mandatory to implement video codecs for six months or so. We do, however, a milestone for a video draft that comes up pretty shortly after the period we've set aside comes to attend, and there are issues which are general enough that the working group chairs felt that it would valuable to begin working on those. We've asked Adam Roach to serve as author of the draft to fulfil that milestone requirement, and he has been kind enough to agree. We don't expect this to be a primary focus of discussion in London, but if Adam has a chance to create the initial text, we will ask for review at that time. regards, Ted --047d7bd74b10865b6904f24ba621 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Howdy,

As folks know, we have suspended discussion of mandato= ry to implement video codecs for six months or so.=A0 We do, however, a mil= estone for a video draft that comes up pretty shortly after the period we&#= 39;ve set aside comes to attend, and there are issues which are general eno= ugh that the working group chairs felt that it would valuable to begin work= ing on those.=A0 We've asked Adam Roach to serve as author of the draft= to fulfil that milestone requirement, and he has been kind enough to agree= .=A0 We don't expect this to be a primary focus of discussion in London= , but if Adam has a chance to create the initial text, we will ask for revi= ew at that time.=A0

regards,

Ted
--047d7bd74b10865b6904f24ba621-- From fluffy@cisco.com Thu Feb 13 08:44: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 8C1751A0306 for ; Thu, 13 Feb 2014 08:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.049 X-Spam-Level: X-Spam-Status: No, score=-115.049 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.548, SPF_PASS=-0.001, 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 T5KasLq1Ldv7 for ; Thu, 13 Feb 2014 08:44:51 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2B71A02B7 for ; Thu, 13 Feb 2014 08:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1453; q=dns/txt; s=iport; t=1392309890; x=1393519490; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=MELq/qM2AtqYys8BLhaApqC4fPrR6kEgzysQ9j+R/Yc=; b=lX+2A14qM308S/vDY1fZfA4TmEvc3oulFGIy8u356kKvsdA+8JJ3eloX /f4yUZ5P8HOYvWmrbCThefBH7iB93MhCDilyrNdHUD3r1QvTdhoorNREW cEQvhcdQW3MWnahjJ7XjCAaUToGgB2+1lTN7+1Iyiimz4cLATEPEbPBIf w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAA72/FKtJXG+/2dsb2JhbABZgwaBD79MgRgWdIIseRIBBnonBA6ICol4viYXjnmDK4EUAQOYLJIjgy2CKg X-IronPort-AV: E=Sophos;i="4.95,839,1384300800"; d="scan'208";a="303831689" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 13 Feb 2014 16:44:49 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1DGinxI011999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 16:44:49 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 10:44:49 -0600 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: Draft Agenda RTCWeb IETF89 - Version 1 Thread-Index: AQHPKNroA1BbAkEL7UmC4afRmUQA4g== Date: Thu, 13 Feb 2014 16:44:49 +0000 Message-ID: <96FF5D3E-ECF0-47C4-B26F-CA7CFD41D61F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] Draft Agenda RTCWeb IETF89 - Version 1 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 16:44:52 -0000 Here is very rough draft of what we currently have on the agenda.=20 Note that the first hour of wed conflicts with some transport stuff.=20 Thanks, the chairs =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97 Draft Agenda Version 1 Tuesday 9 -11:30 Chair Admin: (chairs) - 10 min=20 Data Channel: (who ???) - 80 min=20 draft-ietf-rtcweb-data-channel draft-ietf-rtcweb-data-protocol Transports - Harald - 45 min draft-ietf-rtcweb-transports - The appropriate form of the reference to draft-dhesikan - MUST support ALTERNATE-SERVER - MUST, SHOULD or MAY on TURN TCP candidates - MUST, SHOULD or MAY on ICE TCP candidates - Whether this draft should have normative references on anything SDP-relat= ed (which, conceptually, are above the transport level). Stun/DTLS heartbeat discussion: Dan Wing - 15 min draft-ietf-rtcweb-stun-consent-freshness Wed 9-11:30=20 Chair Admin: (chairs) - 5 min=20 JSEP: Justin - 90 min draft-ietf-rtcweb-jsep=20 Update from RMCAT - RMCAT Chairs - 10 min=20 Sec / Sec Arch: Eric Rescorla - 30 min=20 draft-ietf-rtcweb-security draft-ietf-rtcweb-security-arch RTP usage: Colin -15 min draft-ietf-rtcweb-rtp-usage - Prepared for WG Last Call - Issues with latest changes? NAT-Firewall: Still trying to resolve what parts of this are in this WG - = Andy ( ?? minutes)=20 draft-hutton-rtcweb-nat-firewall-considerations-03 = From magnus.westerlund@ericsson.com Thu Feb 13 08:46: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 631791A0319 for ; Thu, 13 Feb 2014 08:46:34 -0800 (PST) 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_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 PqiKgn9uqFph for ; Thu, 13 Feb 2014 08:46:32 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id CA4C11A02B7 for ; Thu, 13 Feb 2014 08:46:31 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-87-52fcf6e5757e Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id AA.4F.04249.5E6FCF25; Thu, 13 Feb 2014 17:46:29 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.2.347.0; Thu, 13 Feb 2014 17:46:29 +0100 Message-ID: <52FCF6E5.1010006@ericsson.com> Date: Thu, 13 Feb 2014 17:46:29 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: References: <52E8B4F8.4000900@ericsson.com> In-Reply-To: <52E8B4F8.4000900@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvje7Tb3+CDJ6cs7ZY+6+d3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGZMer2Qt+CpS8fr2WsYGxkcCXYwcHBICJhKTz7p0MXICmWIS F+6tZ+ti5OIQEjjCKPH39HxWkISQwHJGiUlbUkBsXgFtiT+P1zOD2CwCqhJvu/rZQWw2AQuJ mz8a2UBsUYFgiZ0HfjNC1AtKnJz5hAXEFhEQlXj9eBrYTGEBB4k5L++zQczXlnizZx7YTE4B HYkD57rZIG4Tl+hpDAIJMwvoSUy52sIIYctLNG+dzQzT2tDUwTqBUXAWkm2zkLTMQtKygJF5 FSNHcWpxUm66kcEmRmDwHdzy22IH4+W/NocYpTlYlMR5P751DhISSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAKNn2jtf12ff9DYGTfjO/FSlpmLTx/q3ffSE2dT1sCW+nyPZlh0lk8v+YWRz2 N2njvO4Dh7+88/Dl6WvrjSs4vnXBhCXqU2v3eLz+/Utg1zeLz4v6n04OZ/V9kaxkLHvNeVtL 5pflzz6e/lnEYf391hORi4XeMZVXZtcxXT9w8VS3yJuZ4nPao5RYijMSDbWYi4oTATStDAQM AgAA Subject: [rtcweb] Updated Potential dates for WebRTC/RTCWEB joint Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 16:46:34 -0000 WG, We have received some feedback on the dates. After having done some checking we propose to shift the interim meeting one day earlier to reduce the overlap with the 3GPP meeting. Thus, the proposed dates for the interim is 19-21 of May (Mon-Wed). If you are willing to host, please contact the WG chairs. Cheers Magnus, Ted and Cullen On 2014-01-29 08:59, Magnus Westerlund wrote: > WG, > > The chairs of this WG and the W3C are considering an joint interim > meeting. The dates we chairs have arrived as feasible are May 20-22 > (Tue-Thu). We are considering to split up the time between the two WGs > across all three days. So please take note of these dates in your > calendar now. > > The target region for this interim would be East Coast of North America, > but we have at this stage no host or set location. If you are willing to > host, please contact the chairs. > > We haven't decided on this interim yet, and appreciate your input into > holding one. The goals of the interim would be to advanced the state of > the core documents we need to finish up. We expect that we will have > some document that may have WG last call issues needing face to face > time to speed up resolving them. We expect to have documents that are > under development, like JSEP that will have thorny issues to deal with. > Especially issues that interact with the API where we can benefit from > having the W3C WG also present to come to joint conclusions. > > Cheers > > Magnus Westerlund > (For the RTCWEB Chairs) > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Feb 13 09:47: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 61A071A036E for ; Thu, 13 Feb 2014 09:47:35 -0800 (PST) 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 WJKPFD1uIsgh for ; Thu, 13 Feb 2014 09:47:33 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3AD1A0382 for ; Thu, 13 Feb 2014 09:47:33 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id e4so8955461wiv.10 for ; Thu, 13 Feb 2014 09:47:32 -0800 (PST) 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=B1xEVzJuG2xiHrrmxFCEc2Df1yEZQUv2TW0YKum5k8A=; b=pkKoYr2ysWowzIDavhUSWf0GjYMJhhsgk4Gkb4+RaGepUY/r0EJhqSo0MwOmN7wMa6 tK2cTMlIFEZiMco0lS14sF9SedHV6J1ryiTWzhcpLB4qpZ2J0EjRLuQNdb0VFxLjYZsH XuzowBsmwrGjAKAagYdb0dcMsng9FLm82NXzdDFxsQ7vECDtLxkGsINVqZ44+BEhCk0z rIg6HvKhjn5n0hOogNfog30BucL3d1m/0iyiM6zAhRVfte1EU9MOBbOxPo31laqkKuq2 +tknzIQqUCXtmjdOmgM0FaJJw5n+qo2N4m932gDmb5CjcVpsa4200P4PcEiKy6bnNs0X T4gg== MIME-Version: 1.0 X-Received: by 10.180.75.202 with SMTP id e10mr7522202wiw.50.1392313651932; Thu, 13 Feb 2014 09:47:31 -0800 (PST) Received: by 10.227.10.196 with HTTP; Thu, 13 Feb 2014 09:47:31 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Feb 2014 09:47:31 -0800 Message-ID: From: Martin Thomson To: Cb B Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CR6wZX4O_hcvOK8dUOi3Tw_43Zw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 17:47:35 -0000 On 12 February 2014 22:06, Cb B wrote: > For about a year now, i have been very concerned about IPv4 UDP. It > has been increasingly associated with DDoS traffic [1], Is your concern that WebRTC will increase the potential for DoS (which would presume the DoS mitigation measures in ICE [RFC 5245] are insufficient), or is it just that UDP is so toxic to network operators that you predict it will be turned off? From nobody Thu Feb 13 09:56: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 B08CC1A039B for ; Thu, 13 Feb 2014 09:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 J05zuOk4nVYB for ; Thu, 13 Feb 2014 09:56:45 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1A51A02A7 for ; Thu, 13 Feb 2014 09:56:45 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hm4so8983671wib.1 for ; Thu, 13 Feb 2014 09:56:43 -0800 (PST) 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=h9xpP6FZhFpPxD4qMgGppo9m9hTAHxYgyfdJ/OCfl8Y=; b=rstFKNH9QE22/0u1JO1wana1SfgZsCpTHhuDjMx9Z0XyV/HAJKFc+v6WC1OlNXFAXW LiENo425GsBgDiBCgL/KueKeKyFDxBw1/zZt0Jnt2oZ77h1EkmY24vPsOwNdwVJ3NI6o 0H0FzyBPXAE85EaqgB6NWZfDdLWQ+JW/pqqU38rNH7TBDTK1/CWp97KLhOEBK9L973zT UJ+2SjmgXUrEqdRXO4QjAROZbGJnT6yyklkM0zvdUmNL+D6TNGwFTYh0HtbZwoWebiGl p2K49JrYqYLZSb0VJt1npW0QlJlURMrqg9VCEqW4ilWohxTe2fAogFZFGXxUXj5xBRl0 PcDQ== MIME-Version: 1.0 X-Received: by 10.194.108.41 with SMTP id hh9mr53012wjb.89.1392314203679; Thu, 13 Feb 2014 09:56:43 -0800 (PST) Received: by 10.194.133.169 with HTTP; Thu, 13 Feb 2014 09:56:43 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Feb 2014 09:56:43 -0800 Message-ID: From: Cb B To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O5fDyI93niq1c45WhGeoWVnBjT0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 17:56:46 -0000 On Thu, Feb 13, 2014 at 9:47 AM, Martin Thomson wrote: > On 12 February 2014 22:06, Cb B wrote: >> For about a year now, i have been very concerned about IPv4 UDP. It >> has been increasingly associated with DDoS traffic [1], > > Is your concern that WebRTC will increase the potential for DoS (which > would presume the DoS mitigation measures in ICE [RFC 5245] are > insufficient), or is it just that UDP is so toxic to network operators > that you predict it will be turned off? My concern is that IPv4 UDP is so toxic it will be blocked. It may be wise to start SCTP in the standard from the start. Cameron From nobody Thu Feb 13 10:12: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 3A0661A03BD for ; Thu, 13 Feb 2014 10:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.326 X-Spam-Level: X-Spam-Status: No, score=-1.326 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_14=0.6, RP_MATCHES_RCVD=-0.548, 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 OToS8yKDaxGk for ; Thu, 13 Feb 2014 10:12:13 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 151791A03C1 for ; Thu, 13 Feb 2014 10:12:09 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id uy5so12525346obc.5 for ; Thu, 13 Feb 2014 10:12:07 -0800 (PST) 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=3782Tv+lTZwyjmw5vHI2Z/xje3sZropwl1cXflCjRWY=; b=VVPORjTZSMvWS78lea6HrcUM0XM1QhtT6JIkOmjqu6id7ehvjtDnfGrq6f4236AGim oqU/zl8zLW+q/xiP4S/yQsGgVrV7y2f18V7a7Wn6WizGtnNtJS9iXmDWqKDx5EqeNkj1 RqXkCb3+HEzdopvSwX2N70loUfmPH+fSZGRsarx/+E+vb5jlDccOMWpshq44p17V6ln/ 7wKr1+RkIDWKvTJw9V3u/sOncRWWn+1wEXZVM/Bbof1ApyvRLtpVQS/ILtbgc33t70Ti PT/HM+q7uVGuchtLLQGkK7QKW3JSnrFhw9w+x9kTbWDwtDkLY/eExdomK45srmlquzLu D0OA== 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=3782Tv+lTZwyjmw5vHI2Z/xje3sZropwl1cXflCjRWY=; b=IJqFhRvjQzDHg8LfOmGJZfP0jU5B6kH/SYw3tY7+edYH2sCotp9a84yEd6RKhe4+LX +FKs9JdSigLcDuPgG+aH7q21yPa8ZEUbLl8g1DV4kAU5uLAt5/MKbdiCz5+2VCHeQcVL nqKKg0RmDI3ZEYmVHAQL+dAVn1131H8LWyVmsl2TM37JwjH5Wre57oW5Sw9U+71Z8cuh k7mPdUfbAxTtM+4bPPt19AafsNFfl9PmeV5RZlD5gDlEzHvROsP82UieUREOM2AYOGCo qdtWjoeZurhMjTeiOON2lanRe3OtzzXSXmtLwV5jtO2/463wg5eCkd5vmi8dxN9rlq6Z ciZg== X-Gm-Message-State: ALoCoQnjxPvdMDgCBN1wRQV8zjqtJX60ou0W8VuAq6okR3xvvQ2wX/8pbx4pgJhRrYMeDjetn3rbIs1SOuQCEYnPOtHA1SfG0ZV1bjfaku0jvU4HhmY1dL+GYHfNUeP1Yf3ix1dxOaQfCbEK9/ZW95Z5WOseu6mVjdC8NoX3coYq3uncbaLsRkqpgrURKMJa5SM1YJGdlpi7 X-Received: by 10.60.84.143 with SMTP id z15mr2377147oey.27.1392315127491; Thu, 13 Feb 2014 10:12:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.38.137 with HTTP; Thu, 13 Feb 2014 10:11:47 -0800 (PST) In-Reply-To: <52FC8AEB.6020906@ericsson.com> References: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.com> <52FC8AEB.6020906@ericsson.com> From: Harald Alvestrand Date: Thu, 13 Feb 2014 19:11:47 +0100 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=089e0117696f994d5b04f24da06a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-L1Dk0GklONxNQCandpzzwcya5U Cc: Cullen Jennings , Jonathan Lennox , "rtcweb@ietf.org" , mmusic Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 18:12:15 -0000 --089e0117696f994d5b04f24da06a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What's being asked for is a way to control MediaStreamTracks. The RTP streams are only incidentally impacted. I'll put a strawman proposal into -msid- today. On Thu, Feb 13, 2014 at 10:05 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-02-04 01:05, Justin Uberti wrote: > > > > > Agree that msid should map m-line to MST, but it would seem recv-msid > > could map RTP flow to m=3Dline as well as indicate whether the receiver= is > > in fact interested in receiving the MST associated with said m=3D line. > > Note that recv-msid doesn't specify an actual MSID; its purpose is to > > indicate that the receiver wants to receive data from the remote side's > > MST, and provide a mechanism for the sender to mark the data > > accordingly. (Which ends up seeming a lot like appid.) > > > > A question here, what are you really trying to reject? > > Is it the MST, a particular RTP Stream (Id by SSRC) or the usage of this > media description (m=3D block) in a particular direction (i.e. SDP > internal)? > > I think the solution differs quite a lot depending on what you really > try to accomplish. > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --089e0117696f994d5b04f24da06a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What's being asked for is a way to control MediaStream= Tracks.

The RTP streams are only incidentally impacted.<= /div>

I'll put a strawman proposal into -msid- today= .


On Thu,= Feb 13, 2014 at 10:05 AM, Magnus Westerlund <magnus.westerl= und@ericsson.com> wrote:
On 2014-02-04 01:05, Justin = Uberti wrote:

>
> Agree that msid should map m-line to MST, but it would seem recv-msid<= br> > could map RTP flow to m=3Dline as well as indicate whether the receive= r is
> in fact interested in receiving the MST associated with said m=3D line= .
> Note that recv-msid doesn't specify an actual MSID; its purpose is= to
> indicate that the receiver wants to receive data from the remote side&= #39;s
> MST, and provide a mechanism for the sender to mark the data
> accordingly. (Which ends up seeming a lot like appid.)
>

A question here, what are you really trying to reject?

Is it the MST, a particular RTP Stream (Id by SSRC) or the usage of this media description (m=3D block) =C2=A0in a particular direction (i.e. SDP in= ternal)?

I think the solution differs quite a lot depending on what you really
try to accomplish.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Phone= =C2=A0+46 10 7= 148287
F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | Mobile +4= 6 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--089e0117696f994d5b04f24da06a-- From nobody Thu Feb 13 10: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 8D7DD1A03DF for ; Thu, 13 Feb 2014 10:45:54 -0800 (PST) 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 O2nPJTGY1LW3 for ; Thu, 13 Feb 2014 10:45:53 -0800 (PST) Received: from mail.eeph.com (mail.eeph.com [192.135.198.155]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE921A03D7 for ; Thu, 13 Feb 2014 10:45:53 -0800 (PST) Received: from [IPv6:2001:470:826a:d0:5075:df81:a4d2:5ddd] (unknown [IPv6:2001:470:826a:d0:5075:df81:a4d2:5ddd]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id 141AA280E81 for ; Thu, 13 Feb 2014 10:45:52 -0800 (PST) Message-ID: <52FD12E0.70205@matthew.at> Date: Thu, 13 Feb 2014 10:45:52 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GvjcfM8hBMwbjlVZA9oY8QH2FNY Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 18:45:54 -0000 On 2/13/2014 9:56 AM, Cb B wrote: > On Thu, Feb 13, 2014 at 9:47 AM, Martin Thomson > wrote: >> On 12 February 2014 22:06, Cb B wrote: >>> For about a year now, i have been very concerned about IPv4 UDP. It >>> has been increasingly associated with DDoS traffic [1], >> Is your concern that WebRTC will increase the potential for DoS (which >> would presume the DoS mitigation measures in ICE [RFC 5245] are >> insufficient), or is it just that UDP is so toxic to network operators >> that you predict it will be turned off? > My concern is that IPv4 UDP is so toxic it will be blocked. It may be > wise to start SCTP in the standard from the start. > Why SCTP? Why not "Just like UDP only restricted to having SRTP inside" or even "just like UDP only a different protocol number that we like better"? (Assuming that this is a good idea at all) Matthew Kaufman From nobody Thu Feb 13 10:50: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 BC2B61A039F for ; Thu, 13 Feb 2014 10:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 dXpd5A3iSEN4 for ; Thu, 13 Feb 2014 10:50:06 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFFA1A03CA for ; Thu, 13 Feb 2014 10:50:05 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id e4so3711588wiv.4 for ; Thu, 13 Feb 2014 10:50:04 -0800 (PST) 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=nIvOodgvL29Wx7YVxAQCTM9QytwrIMFTSdA5vsaDaI4=; b=p5CdHdiIYi+dstNWWgPX85klUAThAbpIs3l8bV1ojUa2U3z0kxUJVMfwYSnX3Q6g9R RaWjtcBz443fnszrnlNaNfLdA8qISUw2S6QS8LIHQP3l4tqn2B39NkZbioqz1S0ZYRIl NUnrHk884mqncL68diFLd4Ny/MMkIHOEc/VtWqSwrrbSWhZQ+rk8pPqOquRy9p3a9ABn yuN7v77p/L4BzYtYa1qQHJzPG4TBgfqTqh0Et/2Boh1txuk3q8tqw4wtwqj06FJXjtfx tBAUhNwFzeiZju8tO9rQrK8VmaR9oBj9WF9lx46FwG9irgAhvYSI4xjX267NTaZLt9En XnSw== MIME-Version: 1.0 X-Received: by 10.180.188.229 with SMTP id gd5mr7245056wic.54.1392317404228; Thu, 13 Feb 2014 10:50:04 -0800 (PST) Received: by 10.194.133.169 with HTTP; Thu, 13 Feb 2014 10:50:04 -0800 (PST) In-Reply-To: <52FD12E0.70205@matthew.at> References: <52FD12E0.70205@matthew.at> Date: Thu, 13 Feb 2014 10:50:04 -0800 Message-ID: From: Cb B To: Matthew Kaufman Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qmNnT5RXXssaC61Us4k0y9SqA14 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 18:50:08 -0000 On Thu, Feb 13, 2014 at 10:45 AM, Matthew Kaufman wrote: > On 2/13/2014 9:56 AM, Cb B wrote: >> >> On Thu, Feb 13, 2014 at 9:47 AM, Martin Thomson >> wrote: >>> >>> On 12 February 2014 22:06, Cb B wrote: >>>> >>>> For about a year now, i have been very concerned about IPv4 UDP. It >>>> has been increasingly associated with DDoS traffic [1], >>> >>> Is your concern that WebRTC will increase the potential for DoS (which >>> would presume the DoS mitigation measures in ICE [RFC 5245] are >>> insufficient), or is it just that UDP is so toxic to network operators >>> that you predict it will be turned off? >> >> My concern is that IPv4 UDP is so toxic it will be blocked. It may be >> wise to start SCTP in the standard from the start. >> > > Why SCTP? Why not "Just like UDP only restricted to having SRTP inside" or > even "just like UDP only a different protocol number that we like better"? > > (Assuming that this is a good idea at all) > UDP2 using a different protocol number would be sufficient to differentiate from the "bad" traffic. Cameron > Matthew Kaufman > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Feb 13 11:27: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 CAD441A0406 for ; Thu, 13 Feb 2014 11:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 n4-VMObHb9Nl for ; Thu, 13 Feb 2014 11:27:04 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id EA9991A0350 for ; Thu, 13 Feb 2014 11:27:03 -0800 (PST) X-AuditID: c1b4fb30-b7faa8e000007034-65-52fd1c85b2a4 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B8.97.28724.58C1DF25; Thu, 13 Feb 2014 20:27:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 20:26:41 +0100 From: Christer Holmberg To: Magnus Westerlund , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Updated Potential dates for WebRTC/RTCWEB joint Interim Thread-Index: AQHPKNsq/E4u9KKYhk+kHeFTMXvom5qzkKsw Date: Thu, 13 Feb 2014 19:26:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D17143C@ESESSMB209.ericsson.se> References: <52E8B4F8.4000900@ericsson.com> <52FCF6E5.1010006@ericsson.com> In-Reply-To: <52FCF6E5.1010006@ericsson.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM2K7lm6rzN8gg4avJhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/rr5ywFzVIVz8/wNzDOFe1i5OSQEDCRuH17HhOELSZx4d56 ti5GLg4hgYOMElsat7NAOIsZJXZNbWXtYuTgYBOwkOj+pw3SICIQK/F+9lVWEFtYwFfi1tIX zBDxAIkvu/5B2UYS+x//ZAGxWQRUJbbv/QFm8wLV3/3/nx3EFhLwlri5+hQbyHhOAR2Jx9sU QcKMQPd8P7UG7DZmAXGJDwevM0PcKSCxZM95KFtU4uXjf6wQtpJE45InrBD1ehI3pk5hg7C1 JZYtfM0MsVZQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcXInpuYmZNebr6JERjyB7f8NtjB uOm+2CFGaQ4WJXHeD2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwxr3f/O63nhCDV1pJ 8aITJ95/ltjysPhPv23Qsu2frtk/2+GgfiN1ieS3ivpOzUOLTWtSry3flDDjmbsFSyA7Z5Re Wgi7lvUn/0U6+zPfFbh/WaF+o2HzeQ6mrd0+fyaHLFM/IMI3j3lm6EOW9abLzG4um3hh9wln rw2HCxcd05oiIXjYWJBbVomlOCPRUIu5qDgRABRHO2xHAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nCdAO1ufJxypcYCmoyKxA1ZdjPA Subject: Re: [rtcweb] Updated Potential dates for WebRTC/RTCWEB joint Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 19:27:07 -0000 Hi Chairs, Thank You very much for the shift! I appreciate very much that you took the= 3GPP meeting in consideration when planning the meeting. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: rtcweb [mailto:rtcweb-bounces@ietf.org] Puolesta Magnus We= sterlund L=E4hetetty: 13. helmikuuta 2014 18:46 Vastaanottaja: rtcweb@ietf.org Aihe: [rtcweb] Updated Potential dates for WebRTC/RTCWEB joint Interim WG, We have received some feedback on the dates. After having done some checkin= g we propose to shift the interim meeting one day earlier to reduce the ove= rlap with the 3GPP meeting. Thus, the proposed dates for the interim is 19-= 21 of May (Mon-Wed). If you are willing to host, please contact the WG chairs. Cheers Magnus, Ted and Cullen On 2014-01-29 08:59, Magnus Westerlund wrote: > WG, >=20 > The chairs of this WG and the W3C are considering an joint interim=20 > meeting. The dates we chairs have arrived as feasible are May 20-22=20 > (Tue-Thu). We are considering to split up the time between the two WGs=20 > across all three days. So please take note of these dates in your=20 > calendar now. >=20 > The target region for this interim would be East Coast of North=20 > America, but we have at this stage no host or set location. If you are=20 > willing to host, please contact the chairs. >=20 > We haven't decided on this interim yet, and appreciate your input into=20 > holding one. The goals of the interim would be to advanced the state=20 > of the core documents we need to finish up. We expect that we will=20 > have some document that may have WG last call issues needing face to=20 > face time to speed up resolving them. We expect to have documents that=20 > are under development, like JSEP that will have thorny issues to deal wit= h. > Especially issues that interact with the API where we can benefit from=20 > having the W3C WG also present to come to joint conclusions. >=20 > Cheers >=20 > Magnus Westerlund > (For the RTCWEB Chairs) >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 --=20 Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Feb 13 12:36: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 EC7801A0456 for ; Thu, 13 Feb 2014 12:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548, 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 6o2v3PPIURL5 for ; Thu, 13 Feb 2014 12:36:03 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACBE1A0448 for ; Thu, 13 Feb 2014 12:36:03 -0800 (PST) Received: from [192.168.1.200] (p508F0C3F.dip0.t-ipconnect.de [80.143.12.63]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0A86D1C103E4E; Thu, 13 Feb 2014 21:35:59 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Thu, 13 Feb 2014 21:36:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52FD12E0.70205@matthew.at> To: Cb B X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/s92bVtfpDsSGXnGHMYiM888NbKA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 20:36:07 -0000 On Feb 13, 2014, at 7:50 PM, Cb B wrote: > On Thu, Feb 13, 2014 at 10:45 AM, Matthew Kaufman = wrote: >> On 2/13/2014 9:56 AM, Cb B wrote: >>>=20 >>> On Thu, Feb 13, 2014 at 9:47 AM, Martin Thomson >>> wrote: >>>>=20 >>>> On 12 February 2014 22:06, Cb B wrote: >>>>>=20 >>>>> For about a year now, i have been very concerned about IPv4 UDP. = It >>>>> has been increasingly associated with DDoS traffic [1], >>>>=20 >>>> Is your concern that WebRTC will increase the potential for DoS = (which >>>> would presume the DoS mitigation measures in ICE [RFC 5245] are >>>> insufficient), or is it just that UDP is so toxic to network = operators >>>> that you predict it will be turned off? >>>=20 >>> My concern is that IPv4 UDP is so toxic it will be blocked. It may = be >>> wise to start SCTP in the standard from the start. >>>=20 >>=20 >> Why SCTP? Why not "Just like UDP only restricted to having SRTP = inside" or >> even "just like UDP only a different protocol number that we like = better"? >>=20 >> (Assuming that this is a good idea at all) >>=20 >=20 > UDP2 using a different protocol number would be sufficient to > differentiate from the "bad" traffic. ... and would make sure that it does not pass NATs... I guess this is the same problem as using SCTP/IP. For NAT traversal through NATs not supporting SCTP one would use SCTP/UDP/IP. Best regards Michael >=20 > Cameron >=20 >> Matthew Kaufman >>=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 Thu Feb 13 12:48: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 AEFBA1A0474 for ; Thu, 13 Feb 2014 12:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 hIBo87Hqjx-f for ; Thu, 13 Feb 2014 12:48:41 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACAD1A0478 for ; Thu, 13 Feb 2014 12:48:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 41B8F7C4CCD for ; Thu, 13 Feb 2014 21:48:39 +0100 (CET) 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 JoPa0XMHevPL for ; Thu, 13 Feb 2014 21:48:39 +0100 (CET) Received: from [172.19.7.138] (unknown [216.239.45.74]) by mork.alvestrand.no (Postfix) with ESMTPSA id B23DD7C4CCC for ; Thu, 13 Feb 2014 21:48:38 +0100 (CET) Message-ID: <52FD2FA4.8040701@alvestrand.no> Date: Thu, 13 Feb 2014 21:48:36 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jF5es6L0p2Q7O1MXtRkCH6WHzzU Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 20:48:49 -0000 On 02/13/2014 06:56 PM, Cb B wrote: > On Thu, Feb 13, 2014 at 9:47 AM, Martin Thomson > wrote: >> On 12 February 2014 22:06, Cb B wrote: >>> For about a year now, i have been very concerned about IPv4 UDP. It >>> has been increasingly associated with DDoS traffic [1], >> Is your concern that WebRTC will increase the potential for DoS (which >> would presume the DoS mitigation measures in ICE [RFC 5245] are >> insufficient), or is it just that UDP is so toxic to network operators >> that you predict it will be turned off? > My concern is that IPv4 UDP is so toxic it will be blocked. It may be > wise to start SCTP in the standard from the start. The bad guys will follow wherever the ports are open (and are usually faster at writing code than the standards guys are at writing specs); so will the traversal artists. WebRTC over port 53, anyone? (DNS is the one UDP-based service that's so important to the Internet, it *cannot* be turned off unconditionally - so I expect that if UDP in general gets blocked, port 53 will be the port 80 of UDP-land.) -- Surveillance is pervasive. Go Dark. From nobody Thu Feb 13 13:20: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 D0CC61A0537 for ; Thu, 13 Feb 2014 13:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 lGI9eZ3XBo4e for ; Thu, 13 Feb 2014 13:20:35 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 521921A052C for ; Thu, 13 Feb 2014 13:20:35 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w62so8155013wes.29 for ; Thu, 13 Feb 2014 13:20:33 -0800 (PST) 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=LBOW4tU+2tbqJrgU5Ex4j5pRBQE9cljsVyjG+w93tVA=; b=uYOLaBTRRFZV8NX+6bnQjZxD1QaovhK8XdOc01AQM/L5OKbPvPuBl1ck2eyrbBQ/B4 LFBc05O9Dp3tNyqo6Ka53EP9SaLcsiPr8RHlzH21c4WWBSSnbfjYhl6FZmykcOJ+Pmf1 R5qcV+foYBHWZrEsq8D8gpwRSH8Ugeu2qD0lyiu87F3rYzTU8cNXMq+pfAGR6EcDBmqL 5w/kgGXIqBPo3xX4wQk0ROJacho0RLfwGS8/ipXpndTviofGMjqR0b8VGrRwiawWG28o bjkv4JsdtSl5QZoq2HAGeXXCDIjtiZchiags/m0VFhTn/sdnSKgs2cbu3uvRI0FOj3Gh xvZw== MIME-Version: 1.0 X-Received: by 10.194.119.168 with SMTP id kv8mr3048934wjb.41.1392326433638; Thu, 13 Feb 2014 13:20:33 -0800 (PST) Received: by 10.194.133.169 with HTTP; Thu, 13 Feb 2014 13:20:33 -0800 (PST) In-Reply-To: <52FD2FA4.8040701@alvestrand.no> References: <52FD2FA4.8040701@alvestrand.no> Date: Thu, 13 Feb 2014 13:20:33 -0800 Message-ID: From: Cb B To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FbllrxBHalPiCIIR1He8hDqWzak Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 21:20:38 -0000 On Thu, Feb 13, 2014 at 12:48 PM, Harald Alvestrand wrote: > On 02/13/2014 06:56 PM, Cb B wrote: >> On Thu, Feb 13, 2014 at 9:47 AM, Martin Thomson >> wrote: >>> On 12 February 2014 22:06, Cb B wrote: >>>> For about a year now, i have been very concerned about IPv4 UDP. It >>>> has been increasingly associated with DDoS traffic [1], >>> Is your concern that WebRTC will increase the potential for DoS (which >>> would presume the DoS mitigation measures in ICE [RFC 5245] are >>> insufficient), or is it just that UDP is so toxic to network operators >>> that you predict it will be turned off? >> My concern is that IPv4 UDP is so toxic it will be blocked. It may be >> wise to start SCTP in the standard from the start. > > The bad guys will follow wherever the ports are open (and are usually > faster at writing code than the standards guys are at writing specs); so > will the traversal artists. > Harald, the issue is not open ports. The issue is the entire transport type is polluted. > WebRTC over port 53, anyone? > > (DNS is the one UDP-based service that's so important to the Internet, > it *cannot* be turned off unconditionally - so I expect that if UDP in > general gets blocked, port 53 will be the port 80 of UDP-land.) > DNS runs over TCP as well. But that's not the point. The question is can we include native SCTP as an option in draft-ietf-rtcweb-transports? What is the downside? CB > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Feb 13 14:28: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 10D391A0012 for ; Thu, 13 Feb 2014 14:28:19 -0800 (PST) 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, 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 k_12t_Z59seu for ; Thu, 13 Feb 2014 14:28:17 -0800 (PST) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) by ietfa.amsl.com (Postfix) with ESMTP id 493051A000C for ; Thu, 13 Feb 2014 14:28:17 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id j1so14021741iga.2 for ; Thu, 13 Feb 2014 14:28:16 -0800 (PST) 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=esUlOHrHKbpiM75KVpPX/1k77CBfhmRwTnkVE1kZ6X0=; b=f+IviFUWmHgu2X4d9ABeXo5HIJJSDa4XzZpkvTAe/Pjtw3jP2yZ4nbigUEoiGRLPOS +jPt77vLPRuwakVJe/Kpw3/sV8jX3YvNavasIzVrrYUCyHfWW4kLEGxw0+QVCXgkRQMF KDP/eRl/7j5UoFMbyU+h5GtmMRwtrPxmZQbZr8vmh2H2eSgKgzKQjg3VqpdAKkhHgehF L8NhVtVFY7Yx07GYgqpx1blVp8vsL8OsWz+sWwXU1lqXJR4FTECZP/cBIhAtB1UKRpBt s47/VlUt3V35JQQsMsHl9N7NOUcLuvaFELjEjZBrW5UKz+3TWlkc874yQUjsPTZaZOgR vGwA== X-Gm-Message-State: ALoCoQngZ034Fiv14Qsc6/MtN4BgUCUYij7c+enMPw6NwdOIlOoxFNsDzUdQI8kYc4+gmZBlj5Au X-Received: by 10.50.20.39 with SMTP id k7mr6153130ige.13.1392330495937; Thu, 13 Feb 2014 14:28:15 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ro10sm10542801igb.6.2014.02.13.14.28.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 14:28:15 -0800 (PST) Message-ID: <52FD46F4.7030804@bbs.darktech.org> Date: Thu, 13 Feb 2014 17:28:04 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52FD2FA4.8040701@alvestrand.no> 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/x-jV9mAStYtY7y5TtLFWvKltU3I Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 22:28:19 -0000 On 13/02/2014 4:20 PM, Cb B wrote: > DNS runs over TCP as well. But that's not the point. The question is > can we include native SCTP as an option in > draft-ietf-rtcweb-transports? What is the downside? CB The biggest downside, as I see it, is that 90%+ of the world runs Windows and that platform does not support SCTP natively (a fact that you have mentioned before). I am all in favor of SCTP, but I think you need to solve the Windows problem before this solution become meaningful. Gili From nobody Thu Feb 13 14:32: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 B1AB01A0484 for ; Thu, 13 Feb 2014 14:32:37 -0800 (PST) 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 dixN3-YhJ5q0 for ; Thu, 13 Feb 2014 14:32:36 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 42AFD1A0483 for ; Thu, 13 Feb 2014 14:32:34 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id j1so13893892iga.3 for ; Thu, 13 Feb 2014 14:32:33 -0800 (PST) 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=3ihaTYhaGNjJBl2tiKOiT2kDd8a6nR22tFqWVe6cK0o=; b=X28dbUgacSJEu33zMp4sM275lUT2xHJLSJJhHD0LleNRAAkhQ9aFHkzA0AC68xMTlF dprYHG/MAfsynCNU2072NC4M4ILp0mUIvMLcWORK4hMs5ZKuuGXRJxL25DGG9cklnOhQ B/S1LtEks5Do1T+EU+YGoY81JUeAZTT+hNJB4S52io0mheG6QSSuMitVQTxc+sWjq3uR 39v36+bRSqGbRXX2oqREQ3N0XGH41w1DGM5DE8/qWyisNuVW1kKisNgFXtpIKQFMb9uL xh1orTsehv4+GbJ3wNICGy8juEZsSA57KXJNGnTbmOfDBMH3KEtb1lTno8OwoR9shsgq U8Ww== MIME-Version: 1.0 X-Received: by 10.42.129.9 with SMTP id o9mr3355955ics.38.1392330752957; Thu, 13 Feb 2014 14:32:32 -0800 (PST) Received: by 10.42.237.206 with HTTP; Thu, 13 Feb 2014 14:32:32 -0800 (PST) In-Reply-To: References: <52FD2FA4.8040701@alvestrand.no> Date: Thu, 13 Feb 2014 14:32:32 -0800 Message-ID: From: Ted Hardie To: Cb B Content-Type: multipart/alternative; boundary=20cf3010eb89f0a2af04f2514335 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/t574N3c0cyDUmezNpKAVlRjxh9k Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 22:32:37 -0000 --20cf3010eb89f0a2af04f2514335 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 13, 2014 at 1:20 PM, Cb B wrote: > > But that's not the point. The question is can we include native SCTP > as an option in draft-ietf-rtcweb-transports? What is the downside? > > CB > Howdy, Given previous decisions of the working group, you would need to describe how to provide confidentiality. At the moment, I know only of TLS over SCTP (which would reverse the current mapping) and SCTP over IPSec (which would likely actually be IPSec/UDP); do you know of other methods which would keep SCTP at the top layer of the protocol stack and still provide confidentiality? regarsd, Ted --20cf3010eb89f0a2af04f2514335 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 13, 2014 at 1:20 PM= , Cb B <cb.list6@gmail.com> wrote:

But that's not the point. =A0The question is can we include native SCTP=
as an option in =A0draft-ietf-rtcweb-transports? =A0What is the downside?
CB

Howdy,

Given previous dec= isions of the working group, you would need to describe how to provide conf= identiality.=A0 At the moment, I know only of TLS over SCTP (which would re= verse the current mapping) and SCTP over IPSec (which would likely actually= be IPSec/UDP); do you know of other methods which would keep SCTP at the t= op layer of the protocol stack and still provide confidentiality?

= regarsd,

Ted

--20cf3010eb89f0a2af04f2514335-- From nobody Thu Feb 13 14:37: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 657A21A0005 for ; Thu, 13 Feb 2014 14:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 EowOpfoEVhaj for ; Thu, 13 Feb 2014 14:37:45 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF461A04D8 for ; Thu, 13 Feb 2014 14:37:41 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q58so8256351wes.10 for ; Thu, 13 Feb 2014 14:37:39 -0800 (PST) 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=+IDnECUCma9D4Fo6f83SSkpnhw885JxuAtIzLR83a7c=; b=of5dmsASXOsd/i0XQ80pP4ALdJyKGxBRwvFX2xmBxzT53tM55zGAUrdiUzmrDOaQm9 IsXAzlh7QJGpDE1NYMnwqikwhaEsv/C+3AG2NpLH6FJBg9oadxcc3bwGJdZr7L2xzipP pakpncWAzHDiWGzccEv5MSx55kZAuP/ONMDYI+24zwNGZarAucFy/0NAWvfA7v46K3NE zZBOA5PZzXwxTABTbxWdU6inLf7DoOYvt7ywHpeTkHBVDKeHs+JhwycwU8x/OBGyXgM5 ksG5TlwyfgvxI86bNcDetE9240CL713XhyXiM4LD2170TuWWL2fWV/VwKZazhqJA7uCD te4w== MIME-Version: 1.0 X-Received: by 10.180.13.5 with SMTP id d5mr4439124wic.54.1392331059506; Thu, 13 Feb 2014 14:37:39 -0800 (PST) Received: by 10.194.133.169 with HTTP; Thu, 13 Feb 2014 14:37:39 -0800 (PST) In-Reply-To: References: <52FD2FA4.8040701@alvestrand.no> Date: Thu, 13 Feb 2014 14:37:39 -0800 Message-ID: From: Cb B To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9Bqygv8qPMU4yLr1PuU4xsIq_-U Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 22:37:46 -0000 On Thu, Feb 13, 2014 at 2:32 PM, Ted Hardie wrote: > On Thu, Feb 13, 2014 at 1:20 PM, Cb B wrote: >> >> >> But that's not the point. The question is can we include native SCTP >> as an option in draft-ietf-rtcweb-transports? What is the downside? >> >> CB > > > Howdy, > > Given previous decisions of the working group, you would need to describe > how to provide confidentiality. At the moment, I know only of TLS over SCTP > (which would reverse the current mapping) and SCTP over IPSec (which would > likely actually be IPSec/UDP); do you know of other methods which would keep > SCTP at the top layer of the protocol stack and still provide > confidentiality? > > regarsd, > > Ted > I believe the cleanest would be to do TLS over SCTP. I understand that changes the top of the transport stack, and create variation. But, i don't think current SCTP over DTLS plan has won any beauty prizes. If this is standards track work that must stand the test of time, TLS over SCTP seems appropriate. CB From nobody Thu Feb 13 14:44: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 0C2BB1A0079 for ; Thu, 13 Feb 2014 14:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 Xxgh4QwA-_x2 for ; Thu, 13 Feb 2014 14:44:46 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 989FE1A0018 for ; Thu, 13 Feb 2014 14:44:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E73557C4CB8; Thu, 13 Feb 2014 23:44:44 +0100 (CET) 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 E1uVDnNXBUUr; Thu, 13 Feb 2014 23:44:44 +0100 (CET) Received: from [172.19.7.138] (unknown [216.239.45.74]) by mork.alvestrand.no (Postfix) with ESMTPSA id 37A047C4B69; Thu, 13 Feb 2014 23:44:44 +0100 (CET) Message-ID: <52FD4AD9.7080204@alvestrand.no> Date: Thu, 13 Feb 2014 23:44:41 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Cb B References: <52FD2FA4.8040701@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Q-iJjUbL4aI4bif0QccV39u3UTQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 22:44:51 -0000 On 02/13/2014 10:20 PM, Cb B wrote: > On Thu, Feb 13, 2014 at 12:48 PM, Harald Alvestrand > wrote: >> On 02/13/2014 06:56 PM, Cb B wrote: >>> On Thu, Feb 13, 2014 at 9:47 AM, Martin Thomson >>> wrote: >>>> On 12 February 2014 22:06, Cb B wrote: >>>>> For about a year now, i have been very concerned about IPv4 UDP. It >>>>> has been increasingly associated with DDoS traffic [1], >>>> Is your concern that WebRTC will increase the potential for DoS (which >>>> would presume the DoS mitigation measures in ICE [RFC 5245] are >>>> insufficient), or is it just that UDP is so toxic to network operators >>>> that you predict it will be turned off? >>> My concern is that IPv4 UDP is so toxic it will be blocked. It may be >>> wise to start SCTP in the standard from the start. >> The bad guys will follow wherever the ports are open (and are usually >> faster at writing code than the standards guys are at writing specs); so >> will the traversal artists. >> > Harald, the issue is not open ports. The issue is the entire transport > type is polluted. And I think that notion is bogus. Faced with the choice of dealing with the devil they know (UDP) and the devil they don't have a clue about (SCTP), firewall operators are going to stick with building out the rulesets around UDP, and continuing to refuse all the "new stuff". So I don't think the plan has legs - adding SCTP without the UDP wrapper to our options will not help anyone do anything. But this is trying to forecast the thinking and action of humans that are not me, which is something I frequently get wrong - so other opinions would be welcome. > >> WebRTC over port 53, anyone? >> >> (DNS is the one UDP-based service that's so important to the Internet, >> it *cannot* be turned off unconditionally - so I expect that if UDP in >> general gets blocked, port 53 will be the port 80 of UDP-land.) >> > DNS runs over TCP as well. For AXFR, yes. For daily lookups .... better not tell any root DNS operator you're advocating that they should have all their lookups over TCP; you wouldn't like the expletives that result. > > But that's not the point. The question is can we include native SCTP > as an option in draft-ietf-rtcweb-transports? What is the downside? > Clutter. From nobody Thu Feb 13 14:45: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 4FB431A044D for ; Thu, 13 Feb 2014 14:45:54 -0800 (PST) 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 xUx049tadqBm for ; Thu, 13 Feb 2014 14:45:51 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 028641A0493 for ; Thu, 13 Feb 2014 14:45:50 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id uq10so14088620igb.2 for ; Thu, 13 Feb 2014 14:45:49 -0800 (PST) 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=XJNWcsaYRpQh/yQw1jiv5qUSj8XSlKBcQfnEgfIXGMA=; b=IUdgWnKeVyMsNFPoMtexMRvrWN7NL1rvacw9vnEekv2yVT56aZp2pGOI37VkwKXFoq vuL4pjrjM6sN5M37d9QLXaBM/3/Eyip8JJ1DobNjQUaflh6Z60nMxi7jsYjZ0Hk0SOFM Kij2GlMFfpi4rgpJgVDit1syDRBiTOsYNlMfJ37KlgWzSthXB92hDiMBnyT+5HevNTZV +JmMDJTQ06ush4jyVJIPWpW/CiYVTFWa5fV0zh86DU7v/nESqlJxRixTEBv4bPs1WfFc INCuLSYhx7MKOCX8JxvE9TJn0jFrBiIrdBlDGGefqxFk5UrVCLi8wOZupWPIx5bbOVMI kO8A== MIME-Version: 1.0 X-Received: by 10.50.20.39 with SMTP id k7mr6226410ige.13.1392331549586; Thu, 13 Feb 2014 14:45:49 -0800 (PST) Received: by 10.42.237.206 with HTTP; Thu, 13 Feb 2014 14:45:49 -0800 (PST) In-Reply-To: References: <52FD2FA4.8040701@alvestrand.no> Date: Thu, 13 Feb 2014 14:45:49 -0800 Message-ID: From: Ted Hardie To: Cb B Content-Type: multipart/alternative; boundary=047d7bd8fbac6c387b04f251735b Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9_v1MCBqezkz73CFu4b98DR9vYA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 22:45:54 -0000 --047d7bd8fbac6c387b04f251735b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 13, 2014 at 2:37 PM, Cb B wrote: > On Thu, Feb 13, 2014 at 2:32 PM, Ted Hardie wrote: > > On Thu, Feb 13, 2014 at 1:20 PM, Cb B wrote: > >> > >> > >> But that's not the point. The question is can we include native SCTP > >> as an option in draft-ietf-rtcweb-transports? What is the downside? > >> > >> CB > > > > > > Howdy, > > > > Given previous decisions of the working group, you would need to describe > > how to provide confidentiality. At the moment, I know only of TLS over > SCTP > > (which would reverse the current mapping) and SCTP over IPSec (which > would > > likely actually be IPSec/UDP); do you know of other methods which would > keep > > SCTP at the top layer of the protocol stack and still provide > > confidentiality? > > > > regarsd, > > > > Ted > > > > I believe the cleanest would be to do TLS over SCTP. I understand > that changes the top of the transport stack, and create variation. > But, i don't think current SCTP over DTLS plan has won any beauty > prizes. If this is standards track work that must stand the test of > time, TLS over SCTP seems appropriate. > > This requires a completely new method for providing channel abstractions. If you would like the working group to consider a change of that magnitude, a worked draft describing a solution that meets all of the use cases set out in draft-ietf-rtcweb-data-channel-07 seems to me the bare minimum to consider overturning the established working group consensus on this point. Speaking personally, I do not see sufficient SCTP/IP deployment to warrant further discussion on this point. The working group has invested considerable time and effort on this approach and the likely result of this change seems to me either a less deployable system or one which will deploy later because of the need to start discussions over. regards, Ted Hardie > CB > --047d7bd8fbac6c387b04f251735b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 13, 2014 at 2:37 PM= , Cb B <cb.list6@gmail.com> wrote:
On Thu, Feb 13, 2014 at 2:32 PM, Ted Hard= ie <ted.ietf@gmail.com> wro= te:
> On Thu, Feb 13, 2014 at 1:20 PM, Cb B <cb.list6@gmail.com> wrote:
>>
>>
>> But that's not the point. =A0The question is can we include na= tive SCTP
>> as an option in =A0draft-ietf-rtcweb-transports? =A0What is the do= wnside?
>>
>> CB
>
>
> Howdy,
>
> Given previous decisions of the working group, you would need to descr= ibe
> how to provide confidentiality. =A0At the moment, I know only of TLS o= ver SCTP
> (which would reverse the current mapping) and SCTP over IPSec (which w= ould
> likely actually be IPSec/UDP); do you know of other methods which woul= d keep
> SCTP at the top layer of the protocol stack and still provide
> confidentiality?
>
> regarsd,
>
> Ted
>

I believe the cleanest would be to do TLS over SCTP. =A0I under= stand
that changes the top of the transport stack, and create variation.
But, i don't think current SCTP over DTLS plan has won any beauty
prizes. =A0If this is standards track work that must stand the test of
time, TLS over SCTP seems appropriate.


This= requires a completely new method for providing channel abstractions.=A0
If you would like the working group to consider a change of that magnitude,=
a worked draft describing a solution that meets all of the use cases se= t out in
draft-ietf-rtcweb-data-channel-07 seems to me the bare minimum = to consider
overturning the established working group consensus on this point.

<= /div>
Speak= ing personally, I do not see sufficient SCTP/IP deployment to warrant
further discussion on this point.=A0 The working group has invested conside= rable
time and effort on this approach and the likely result of this cha= nge seems to
me either a less deployable system or one which will deploy= later because of the
need to start discussions over.

regards,

Ted Hardie

=
=A0
CB

--047d7bd8fbac6c387b04f251735b-- From nobody Thu Feb 13 14:46: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 E6B9E1A044D for ; Thu, 13 Feb 2014 14:46:55 -0800 (PST) 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 100cocqkdUt2 for ; Thu, 13 Feb 2014 14:46:53 -0800 (PST) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 34C441A0079 for ; Thu, 13 Feb 2014 14:46:53 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id o15so17391881qap.30 for ; Thu, 13 Feb 2014 14:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=v/Q5eCR4sSkYc6QZdxsn9lQ664jGblOAEf7wDEwOptA=; b=kwcw4qIIX8uUtlkXVpLN77mwmry/ni8rWoAu6JDthJ+splQCxnP2GeSnSqVWVPSYfP yy4OLbNCbe0tAxPKhU9aTWFAQQ4tMv9k+/cC4b+0itDi460Mc6bdly8DNm3g/E3kzgfc dRPWVdrmurMEDG/u9eWpxv+Ki8zdThbIlAXxS9LqoLN/72JhyJxGhowAQioZKLfd7kAO oa+RcZzoIGJa/x00vZR7XNnMCJvefJ0F63gDYRAB4FTEIxm3PIR5M3G87gUsEO2phR4n q8ew5bOcNDa7OmhjhuOxr2D25IQTkIXlx4zhVxcFaVJmBpPUW22/aw1RtOyPsGb7C2Yn uipQ== MIME-Version: 1.0 X-Received: by 10.140.89.167 with SMTP id v36mr6810000qgd.27.1392331611853; Thu, 13 Feb 2014 14:46:51 -0800 (PST) Received: by 10.224.27.133 with HTTP; Thu, 13 Feb 2014 14:46:51 -0800 (PST) In-Reply-To: <52FD46F4.7030804@bbs.darktech.org> References: <52FD2FA4.8040701@alvestrand.no> <52FD46F4.7030804@bbs.darktech.org> Date: Thu, 13 Feb 2014 17:46:51 -0500 Message-ID: From: Dave Taht To: cowwoc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZdBJuOC3unMmu0Jvw_QzuQMF7So Cc: rtcweb@ietf.org Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 22:46:56 -0000 On Thu, Feb 13, 2014 at 5:28 PM, cowwoc wrote: > On 13/02/2014 4:20 PM, Cb B wrote: >> >> DNS runs over TCP as well. But that's not the point. The question is can >> we include native SCTP as an option in draft-ietf-rtcweb-transports? Wha= t is >> the downside? CB > > > The biggest downside, as I see it, is that 90%+ of the world runs Windows > and that platform does not support SCTP natively (a fact that you have > mentioned before). I am all in favor of SCTP, but I think you need to sol= ve > the Windows problem before this solution become meaningful. The biggest downside, as I see it, is targeting advancements in the state o= f the art, at windows. 98% of the world or so run non-windows based cell phones and tablets, and in terms of total users, probably outnumber the windows contingent at this point. SCTP and MPTCP are quite feasible on android and IOS. > > Gili > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From nobody Thu Feb 13 14:47: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 4883A1A04DE for ; Thu, 13 Feb 2014 14:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 51dDDQNna7WJ for ; Thu, 13 Feb 2014 14:47:54 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 85CF61A0481 for ; Thu, 13 Feb 2014 14:47:54 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so9374495wib.12 for ; Thu, 13 Feb 2014 14:47:52 -0800 (PST) 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=afpn94pJJ+JiRZObuaNz8CrerxzX9QF+HCU7Rx4/05g=; b=MQt4FOolSuayhdN7xquqWCvWSF8HFR60nP+whpDzrgiJWgRZuFfeZgJCSs6z1vkCMG FNwWc9AO7boMZ4NNyKJ6hQSlJk6fgt1eNx/L/IAGsQvvFj4xOqrRni9oJA2jnWY7FoMY ptwdg9Uq9neEeZFjpOeYdJgpbCMdSIOHi3gzlaX24WfeM0W66B/hMw7MnPJ9krag51KU REeo0iJJW0a9Wd788UfeyL3wFxmDJKee38i7WsxnXu8qbK75qCD+VU6fCcqvvBrTD14p eRSxcdcvIP0zKgPENtcCr4E2wn/jJoaIO1tz94pH5TDbYhjIOVj4yrGuSY/U+Sl5eTUM D7pw== MIME-Version: 1.0 X-Received: by 10.180.165.15 with SMTP id yu15mr4508699wib.28.1392331672832; Thu, 13 Feb 2014 14:47:52 -0800 (PST) Received: by 10.194.133.169 with HTTP; Thu, 13 Feb 2014 14:47:52 -0800 (PST) In-Reply-To: References: <52FD2FA4.8040701@alvestrand.no> Date: Thu, 13 Feb 2014 14:47:52 -0800 Message-ID: From: Cb B To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/f12WMJw2-YbfBnS2Z1Lb-jwpU6g Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 22:47:56 -0000 On Thu, Feb 13, 2014 at 2:45 PM, Ted Hardie wrote: > On Thu, Feb 13, 2014 at 2:37 PM, Cb B wrote: >> >> On Thu, Feb 13, 2014 at 2:32 PM, Ted Hardie wrote: >> > On Thu, Feb 13, 2014 at 1:20 PM, Cb B wrote: >> >> >> >> >> >> But that's not the point. The question is can we include native SCTP >> >> as an option in draft-ietf-rtcweb-transports? What is the downside? >> >> >> >> CB >> > >> > >> > Howdy, >> > >> > Given previous decisions of the working group, you would need to >> > describe >> > how to provide confidentiality. At the moment, I know only of TLS over >> > SCTP >> > (which would reverse the current mapping) and SCTP over IPSec (which >> > would >> > likely actually be IPSec/UDP); do you know of other methods which would >> > keep >> > SCTP at the top layer of the protocol stack and still provide >> > confidentiality? >> > >> > regarsd, >> > >> > Ted >> > >> >> I believe the cleanest would be to do TLS over SCTP. I understand >> that changes the top of the transport stack, and create variation. >> But, i don't think current SCTP over DTLS plan has won any beauty >> prizes. If this is standards track work that must stand the test of >> time, TLS over SCTP seems appropriate. >> > > This requires a completely new method for providing channel abstractions. > > If you would like the working group to consider a change of that magnitude, > a worked draft describing a solution that meets all of the use cases set out > in > draft-ietf-rtcweb-data-channel-07 seems to me the bare minimum to consider > overturning the established working group consensus on this point. > > Speaking personally, I do not see sufficient SCTP/IP deployment to warrant > further discussion on this point. The working group has invested > considerable > time and effort on this approach and the likely result of this change seems > to > me either a less deployable system or one which will deploy later because of > the > need to start discussions over. > > regards, > > Ted Hardie > Acknowledged. That is approximately the story arc i expected before I initiated the conversation. CB > > >> >> CB > > From nobody Thu Feb 13 14:52: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 B04501A007F for ; Thu, 13 Feb 2014 14:52:03 -0800 (PST) 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, 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 uW8RhBDACayK for ; Thu, 13 Feb 2014 14:52:00 -0800 (PST) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2D81A010B for ; Thu, 13 Feb 2014 14:51:59 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id c10so13965523igq.0 for ; Thu, 13 Feb 2014 14:51:58 -0800 (PST) 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=sLwJcvGnDrr/SaW43bmxchXwVbs5sYLqmAUT309rEw4=; b=T1ImlTw0wyt+6+0Vpm96QMb9yi2wkDQNq/Oh780a3pAKMmTPy5HOaqL+8o5v3g6twd lkhxnmn9zTnJybnH7bRJWnqcctSnOAsyob6rhEROct+b9E8zicvhz3qFj1v7YNOt85HM jupbe4YqVDkZQZZ5ixuMfDTPDBW0/SNW3Rft5DsDFyHlGecsMkN3dGomPrnh1UAEt5OR hF5i6eG6QQWQyT05qeHIMp7s/VIBVU8kWPy6SXCS8dFji5pgPQsXKVtD3+SMCHWqv1wT 6yeZfAiKtpOuV12jWs7ZqhO/r5LFqYoZWoyK4J1jVGia//W3l6eVCtZ5iNKTSNbqApae MvjQ== X-Gm-Message-State: ALoCoQlqOw19xR+OHmLIiYMT5/2r4ZF/c5x/pResdMmcGdgPqxjuSiutCHeY0t1Ba1moPGrYAMaQ X-Received: by 10.50.66.129 with SMTP id f1mr5648197igt.26.1392331918127; Thu, 13 Feb 2014 14:51:58 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id bf7sm10712345igb.9.2014.02.13.14.51.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 14:51:57 -0800 (PST) Message-ID: <52FD4C82.8040300@bbs.darktech.org> Date: Thu, 13 Feb 2014 17:51:46 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Dave Taht References: <52FD2FA4.8040701@alvestrand.no> <52FD46F4.7030804@bbs.darktech.org> 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/cueY_K52n8C9qfcc6HH-LvKZDLI Cc: rtcweb@ietf.org Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 22:52:03 -0000 On 13/02/2014 5:46 PM, Dave Taht wrote: > The biggest downside, as I see it, is targeting advancements in the state of > the art, at windows. 98% of the world or so run non-windows based cell > phones and tablets, and in terms of total users, probably outnumber > the windows contingent at this point. > > SCTP and MPTCP are quite feasible on android and IOS. It doesn't matter how many smartphones there are. What matters is how many of them will be used to do meaningful video chat. The screen real estate on these devices is way too small. So yes, mobile is huge, but from the point of view of WebRTC, Windows is still king. Gili From nobody Thu Feb 13 14:58: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 2AAEE1A0470 for ; Thu, 13 Feb 2014 14:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 Y-9Lcbixi0M9 for ; Thu, 13 Feb 2014 14:57:58 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 13E2C1A0021 for ; Thu, 13 Feb 2014 14:57:57 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id hn9so9343347wib.6 for ; Thu, 13 Feb 2014 14:57:56 -0800 (PST) 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=eNJLtRseXQYKz1BF62v3fJrDhVBQZiRN49xnxcTOpbI=; b=jqqySSXuo7GHgWF9Eff+/1BjjJvI9cd++LLTcxXKYCJyVR65xjLsnWfj9PAVP26cZW IUQpSuIfaIaYMLT3/aSYn71AaMXnaFUU9zBWvXfAb0mc4KQmQgdUkVEaxUMqrik8Ok/z wYmGA4SIOutWOyYLh7aICO2uo/3nopmChUD4aNveh0bA2dNeDitZioIYP2oRnbDv2Nbi l5huo4kcuL/hfOvBjw9X+uhJRbm8Zcrg008uvv4vB8H1d/Mk6IJfJvDe09sKciwT8Bnj AsXr0YRsvOSoedUWf2dE20H3aaj/nnMcMmvwRQTiFZB50TZN/xs7Lz1XY52CkIbSdroZ yRRg== MIME-Version: 1.0 X-Received: by 10.194.78.16 with SMTP id x16mr88494wjw.86.1392332276309; Thu, 13 Feb 2014 14:57:56 -0800 (PST) Received: by 10.194.133.169 with HTTP; Thu, 13 Feb 2014 14:57:56 -0800 (PST) In-Reply-To: <52FD4AD9.7080204@alvestrand.no> References: <52FD2FA4.8040701@alvestrand.no> <52FD4AD9.7080204@alvestrand.no> Date: Thu, 13 Feb 2014 14:57:56 -0800 Message-ID: From: Cb B To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XyoM8miDuq9nWKCtgiUDN4QJzWI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 22:58:00 -0000 On Thu, Feb 13, 2014 at 2:44 PM, Harald Alvestrand wrote: > On 02/13/2014 10:20 PM, Cb B wrote: >> On Thu, Feb 13, 2014 at 12:48 PM, Harald Alvestrand >> wrote: >>> On 02/13/2014 06:56 PM, Cb B wrote: >>>> On Thu, Feb 13, 2014 at 9:47 AM, Martin Thomson >>>> wrote: >>>>> On 12 February 2014 22:06, Cb B wrote: >>>>>> For about a year now, i have been very concerned about IPv4 UDP. It >>>>>> has been increasingly associated with DDoS traffic [1], >>>>> Is your concern that WebRTC will increase the potential for DoS (which >>>>> would presume the DoS mitigation measures in ICE [RFC 5245] are >>>>> insufficient), or is it just that UDP is so toxic to network operators >>>>> that you predict it will be turned off? >>>> My concern is that IPv4 UDP is so toxic it will be blocked. It may be >>>> wise to start SCTP in the standard from the start. >>> The bad guys will follow wherever the ports are open (and are usually >>> faster at writing code than the standards guys are at writing specs); so >>> will the traversal artists. >>> >> Harald, the issue is not open ports. The issue is the entire transport >> type is polluted. > > And I think that notion is bogus. Faced with the choice of dealing with > the devil they know (UDP) and the devil they don't have a clue about > (SCTP), firewall operators are going to stick with building out the > rulesets around UDP, and continuing to refuse all the "new stuff". > I never mentioned firewall operators. I mentioned access networks and internet backbone operators. As many network operators know, there is a big issue with UDP going on that is crushing some networks http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack https://puck.nether.net/pipermail/outages/2014-February/006651.html This is the point in bring to the WG. > So I don't think the plan has legs - adding SCTP without the UDP wrapper > to our options will not help anyone do anything. > it's a path out. > But this is trying to forecast the thinking and action of humans that > are not me, which is something I frequently get wrong - so other > opinions would be welcome. > >> >>> WebRTC over port 53, anyone? >>> >>> (DNS is the one UDP-based service that's so important to the Internet, >>> it *cannot* be turned off unconditionally - so I expect that if UDP in >>> general gets blocked, port 53 will be the port 80 of UDP-land.) >>> >> DNS runs over TCP as well. > > For AXFR, yes. For daily lookups .... better not tell any root DNS > operator you're advocating that they should have all their lookups over > TCP; you wouldn't like the expletives that result. > cute. But, TCP works. Maybe you can ask someone at Android to support EDNS0 so that TCP is used less. Because for now, android required TCP for any response over 512 bytes. >> >> But that's not the point. The question is can we include native SCTP >> as an option in draft-ietf-rtcweb-transports? What is the downside? >> > > Clutter. > > From nobody Thu Feb 13 15:01: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 047F51A0029 for ; Thu, 13 Feb 2014 15:01:03 -0800 (PST) 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 FaUp-ujDue40 for ; Thu, 13 Feb 2014 15:01:01 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4A91A001A for ; Thu, 13 Feb 2014 15:01:01 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id e9so19333297qcy.1 for ; Thu, 13 Feb 2014 15:00:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4EbrBqEp03+nDPxvrS7NT2jdEJ9/0KlcHfCziqpa8Og=; b=qwmtbMwW+E+YUJ5HGi/n5CQaXLsAsFQvD95eqo72S/Yuc9f+5StlV4SeGY+b4RjGTc scefUpOPRzbr3oAno85obQcT/P93oFFHJSfKs/BuAaFmxGXa6sNRncS4YvBdW1Qp+6ZX 1E/qPl3rISYKNqw0KeeM6ZFrYnGk4lHjp1BArlQkzKWnzJ/rcR7JhKyEHI6hKiKd70Cn iqH/pTNt/cjsu2E9GA+Y2d4VuPWWVDTJW/ST2/qNjeUGFOby8DYcsIq5SGT8Y+/Gb2lx 7/uC2JMtSnda3+GHQqogWb95j38NcJzk3erTJliUBCspGPGXR+DetJVy635z9z5Ey4fT 0eJw== MIME-Version: 1.0 X-Received: by 10.140.49.9 with SMTP id p9mr6774892qga.75.1392332459825; Thu, 13 Feb 2014 15:00:59 -0800 (PST) Received: by 10.224.27.133 with HTTP; Thu, 13 Feb 2014 15:00:59 -0800 (PST) In-Reply-To: <52FD4C82.8040300@bbs.darktech.org> References: <52FD2FA4.8040701@alvestrand.no> <52FD46F4.7030804@bbs.darktech.org> <52FD4C82.8040300@bbs.darktech.org> Date: Thu, 13 Feb 2014 18:00:59 -0500 Message-ID: From: Dave Taht To: cowwoc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RtaaJ1ygGCr7gmVg8erOKLomYlY Cc: rtcweb@ietf.org Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 23:01:03 -0000 On Thu, Feb 13, 2014 at 5:51 PM, cowwoc wrote: > On 13/02/2014 5:46 PM, Dave Taht wrote: >> >> The biggest downside, as I see it, is targeting advancements in the stat= e >> of >> the art, at windows. 98% of the world or so run non-windows based cell >> phones and tablets, and in terms of total users, probably outnumber >> the windows contingent at this point. >> >> SCTP and MPTCP are quite feasible on android and IOS. > > > It doesn't matter how many smartphones there are. What matters is how man= y > of them will be used to do meaningful video chat. The screen real estate = on > these devices is way too small. In my experience, everybody is using tablets and handheld devices for video chat. It is a natural extension of the usage of the device to extend it from phone calls to video calls. The lack of a working camera on most desktops is a hindrance, and the place= ment of cameras on most laptops is not ideal. > > So yes, mobile is huge, but from the point of view of WebRTC, Windows is > still king. I am under the impression that this is actually backed by statistics, but a= m interested in recent statistics for things like google hangouts and facetim= e. > Gili --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From nobody Thu Feb 13 15:09: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 568C31A04E3 for ; Thu, 13 Feb 2014 15:09:11 -0800 (PST) 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 yTMfdD-co5A7 for ; Thu, 13 Feb 2014 15:09:08 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 812851A04E0 for ; Thu, 13 Feb 2014 15:09:08 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id e16so18785922qcx.38 for ; Thu, 13 Feb 2014 15:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=a3ejuU4Dk4oYhcm9DUevZ7vy9nUqCqNIfKpxbc3QS+w=; b=hcodQfI3KTJZKyio8ReQNeANOUmrRgHU9D515QSgGklmB5/xtCYH81uzIlqLS7wy7G DayyozAJ2NYOmBS2ft0ZCYYanpFuCj9tP12oHEmQrPtZkLeDTSbzeGoYhxPMuaFfJFe5 TRV4yCbhnQTCvcgauqAqLnLliNf7vHzy6xpGmvnoZYMpVMiXm9awQnU2qoGYeU3SxpMb X5idXfrnHhtubff1TH8nSozm1NaLzQ4ZacpOpQOtBEOZWf6Efi+IDbisIMyg2PE0IRFL xMPQsuGILvuFA/fAiw9eeAH2yywCZ3gqKwE6Tp3WDd8Tj3Tig1NHSDdcl3QPIgDnhjVb LbZQ== MIME-Version: 1.0 X-Received: by 10.140.49.9 with SMTP id p9mr6830403qga.75.1392332947068; Thu, 13 Feb 2014 15:09:07 -0800 (PST) Received: by 10.224.27.133 with HTTP; Thu, 13 Feb 2014 15:09:06 -0800 (PST) In-Reply-To: References: <52FD2FA4.8040701@alvestrand.no> <52FD4AD9.7080204@alvestrand.no> Date: Thu, 13 Feb 2014 18:09:06 -0500 Message-ID: From: Dave Taht To: Cb B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XXr9jrKExyRvH3vX3abIfXyYIX8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 23:09:11 -0000 On Thu, Feb 13, 2014 at 5:57 PM, Cb B wrote: > cute. But, TCP works. Maybe you can ask someone at Android to support > EDNS0 so that TCP is used less. Because for now, android required TCP > for any response over 512 bytes. Android, in part, uses dnsmasq, which we are busily adding dnssec support t= o. https://www.internetsociety.org/deploy360/blog/2014/02/weekend-project-4/ EDNS0 is supported. I would certainly like to see android's DNS handling to be improved. > >>> >>> But that's not the point. The question is can we include native SCTP >>> as an option in draft-ietf-rtcweb-transports? What is the downside? >>> >> >> Clutter. >From a QoS standpoint I would not mind at all if it were possible to run webrtc (and things like QUIC) over their own protocol numbers. I realize this would make webrtc more easily identifiable, but so long as the e2e encryption is = good, the ability for operators and edge devices to optimize for highly interactive traffic would be enhanced. I don't have a lot of hope for SCTP, do have more hope for mptcp, and the ipv6 rollout is seemingly accelerating. https://www.internetsociety.org/deploy360/blog/2014/02/googles-ipv6-stats-p= ass-3-less-than-5-months-after-passing-2/ I am under the impression ipv6 support for webrtc landed in chrome recently= . >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From nobody Thu Feb 13 15:39: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 881971A0532 for ; Thu, 13 Feb 2014 15:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 fB83veaeh6gc for ; Thu, 13 Feb 2014 15:39:22 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id EDFBE1A052C for ; Thu, 13 Feb 2014 15:39:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 45BE77C4CCC; Fri, 14 Feb 2014 00:39:20 +0100 (CET) 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 yqZigeyj6eaq; Fri, 14 Feb 2014 00:39:20 +0100 (CET) Received: from [172.19.7.138] (unknown [216.239.45.74]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2A4467C4CC9; Fri, 14 Feb 2014 00:39:18 +0100 (CET) Message-ID: <52FD57A5.8090804@alvestrand.no> Date: Fri, 14 Feb 2014 00:39:17 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Cb B References: <52FD2FA4.8040701@alvestrand.no> <52FD4AD9.7080204@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/84VDGGCwuLNMTRL60DFwhWIIM2Q Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 23:39:24 -0000 Most important point of reality anchoring (DNS over UDP vs TCP) is at the bottom. Other comments are incidental. On 02/13/2014 11:57 PM, Cb B wrote: > On Thu, Feb 13, 2014 at 2:44 PM, Harald Alvestrand wrote: >> On 02/13/2014 10:20 PM, Cb B wrote: >>> On Thu, Feb 13, 2014 at 12:48 PM, Harald Alvestrand >>> wrote: >>>> On 02/13/2014 06:56 PM, Cb B wrote: >>>>> On Thu, Feb 13, 2014 at 9:47 AM, Martin Thomson >>>>> wrote: >>>>>> On 12 February 2014 22:06, Cb B wrote: >>>>>>> For about a year now, i have been very concerned about IPv4 UDP. It >>>>>>> has been increasingly associated with DDoS traffic [1], >>>>>> Is your concern that WebRTC will increase the potential for DoS (which >>>>>> would presume the DoS mitigation measures in ICE [RFC 5245] are >>>>>> insufficient), or is it just that UDP is so toxic to network operators >>>>>> that you predict it will be turned off? >>>>> My concern is that IPv4 UDP is so toxic it will be blocked. It may be >>>>> wise to start SCTP in the standard from the start. >>>> The bad guys will follow wherever the ports are open (and are usually >>>> faster at writing code than the standards guys are at writing specs); so >>>> will the traversal artists. >>>> >>> Harald, the issue is not open ports. The issue is the entire transport >>> type is polluted. >> And I think that notion is bogus. Faced with the choice of dealing with >> the devil they know (UDP) and the devil they don't have a clue about >> (SCTP), firewall operators are going to stick with building out the >> rulesets around UDP, and continuing to refuse all the "new stuff". >> > I never mentioned firewall operators. I mentioned access networks and > internet backbone operators. > > As many network operators know, there is a big issue with UDP going on > that is crushing some networks > > http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack That's an UDP port 123 (NTP) matter. We've done several of these exercises (live-fire updates of critical Internet infrastructure) over the last few years. > > https://puck.nether.net/pipermail/outages/2014-February/006651.html > > This is the point in bring to the WG. Yes, thanks for bringing it. I just happen to totally disagree with your conclusions. > >> So I don't think the plan has legs - adding SCTP without the UDP wrapper >> to our options will not help anyone do anything. >> > it's a path out. I don't see any property of this path that makes it a) traversable, or b) "out". > >> But this is trying to forecast the thinking and action of humans that >> are not me, which is something I frequently get wrong - so other >> opinions would be welcome. >> >>>> WebRTC over port 53, anyone? >>>> >>>> (DNS is the one UDP-based service that's so important to the Internet, >>>> it *cannot* be turned off unconditionally - so I expect that if UDP in >>>> general gets blocked, port 53 will be the port 80 of UDP-land.) >>>> >>> DNS runs over TCP as well. >> For AXFR, yes. For daily lookups .... better not tell any root DNS >> operator you're advocating that they should have all their lookups over >> TCP; you wouldn't like the expletives that result. >> > cute. But, TCP works. Maybe you can ask someone at Android to support > EDNS0 so that TCP is used less. Because for now, android required TCP > for any response over 512 bytes. I'm talking about http://k.root-servers.org/statistics/ams-ix/ip_protocols.html Note the relative width of the green (TCP) against the purple (UDP). (I've been unable to find a green pixel on those graphs.) -- Surveillance is pervasive. Go Dark. From nobody Thu Feb 13 15:50: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 271C81A033A for ; Thu, 13 Feb 2014 15:50:53 -0800 (PST) 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, 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 L_tnsHFcevEu for ; Thu, 13 Feb 2014 15:50:50 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 576641A001E for ; Thu, 13 Feb 2014 15:50:50 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id lx4so2937496iec.29 for ; Thu, 13 Feb 2014 15:50:49 -0800 (PST) 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=EP5IEL8u5nuXKAtUhwScdXqX8uB1CIaYOEyX2QpvddE=; b=GWQZX+5BjcDJQUhgcPjHNv+ac5YGw3F+2r6n58ylQ86y9xxiPiCLV1zayrUe0WZf/c cE1M1G8g9aSDFqHF4oIndmlU8tZCbA753lcgBAIXzfxzlnvND7ovNcRNLZ15xPCU9u/y X7QqudfTheMbPtS4gASCd4PXLEO9wNID2+wifpUf6ZRYbdMljLVE2nVMI2mUp+9KkAX9 CBvQOhW+t0aX5/1lm/XVOB825i1BHUtUsQLBZnqCiVloYRBITb6MCx/hE7qJuli14J/3 Q/4CzBrv2mNJbQB+75SZrGqT4dV6T1FJpMzUTkNR76v59AeqszeKYP4xzhKWEd4WqM0H QiaQ== X-Gm-Message-State: ALoCoQnoqW3X4WYge8wsA2pFth/3uWrYkHzm7Qc9u5EGrfLqWqKh5cjp3zIwOviBqnbKyJT2QAOa X-Received: by 10.50.20.100 with SMTP id m4mr5863265ige.17.1392335448957; Thu, 13 Feb 2014 15:50:48 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id m6sm10081522igx.9.2014.02.13.15.50.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 15:50:48 -0800 (PST) Message-ID: <52FD5A4E.8060604@bbs.darktech.org> Date: Thu, 13 Feb 2014 18:50:38 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Dave Taht References: <52FD2FA4.8040701@alvestrand.no> <52FD46F4.7030804@bbs.darktech.org> <52FD4C82.8040300@bbs.darktech.org> 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/-oyCSDyNlrKU2PceXsdxVCBkP48 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 23:50:53 -0000 On 13/02/2014 6:00 PM, Dave Taht wrote: > On Thu, Feb 13, 2014 at 5:51 PM, cowwoc wrote: >> On 13/02/2014 5:46 PM, Dave Taht wrote: >>> The biggest downside, as I see it, is targeting advancements in the state >>> of >>> the art, at windows. 98% of the world or so run non-windows based cell >>> phones and tablets, and in terms of total users, probably outnumber >>> the windows contingent at this point. >>> >>> SCTP and MPTCP are quite feasible on android and IOS. >> >> It doesn't matter how many smartphones there are. What matters is how many >> of them will be used to do meaningful video chat. The screen real estate on >> these devices is way too small. > In my experience, everybody is using tablets and handheld devices for > video chat. > It is a natural extension of the usage of the device to extend it from > phone calls > to video calls. > > The lack of a working camera on most desktops is a hindrance, and the placement > of cameras on most laptops is not ideal. All laptops and tablets come with decent cameras. I will agree that WebRTC on tablets will be strong, but smartphones is really pushing it. Most of the time I've seen people engage in video chat it was between family members; far less for business use. And in those cases, I've seen people jump on tablets and laptops instead of having to deal with a tiny, underpowered smartphone for video. These are just personal observations, not science, so please take them with a grain of salt. Gili From nobody Thu Feb 13 15:55: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 DF6FE1A033A for ; Thu, 13 Feb 2014 15:54:59 -0800 (PST) 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 7qLmHAFTah94 for ; Thu, 13 Feb 2014 15:54:57 -0800 (PST) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9C93B1A0026 for ; Thu, 13 Feb 2014 15:54:57 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id w8so17027941qac.22 for ; Thu, 13 Feb 2014 15:54:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vaxfctYj5JW3EVhEDQZ1YcydBsz1hulWnF2NdBaA3Ns=; b=UWOxKShQ5oB1Bmf5SoOeT0CLk3OeEdWaDwINCNih3SZ1PTWImfuMDDefvYMGE9bJDp LQjlSUuHSRAbgNvKqlR84D+P7MBpz6w9A/RE/OZh2HgW7ynWFExVypUk5Tt/tjLuNToX TT8AOENESSyMkipHRnhfEpC5LawsmKqxvHPnGXYMtXOv51vxTfrMSnqYUUPIwyxpDPHn CDt868oFMRUlIewKYBe7o4TXxqOMAgqlfi6pvojeQbrg2yQIXhZkdy70nt4sHWKWJIHb p+cv7HaxnElzQnEwam6XQFYwwk6mc5iAjBYjoxoHeHUeMMGhh/NVWVxMDsQWKwAM83M/ Thmw== MIME-Version: 1.0 X-Received: by 10.140.91.23 with SMTP id y23mr7237014qgd.3.1392335696247; Thu, 13 Feb 2014 15:54:56 -0800 (PST) Received: by 10.224.27.133 with HTTP; Thu, 13 Feb 2014 15:54:56 -0800 (PST) In-Reply-To: <52FD5A4E.8060604@bbs.darktech.org> References: <52FD2FA4.8040701@alvestrand.no> <52FD46F4.7030804@bbs.darktech.org> <52FD4C82.8040300@bbs.darktech.org> <52FD5A4E.8060604@bbs.darktech.org> Date: Thu, 13 Feb 2014 18:54:56 -0500 Message-ID: From: Dave Taht To: cowwoc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wjgguOP8IVLthSHheCqGpQV-DyQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Feb 2014 23:55:00 -0000 On Thu, Feb 13, 2014 at 6:50 PM, cowwoc wrote: > On 13/02/2014 6:00 PM, Dave Taht wrote: >> >> On Thu, Feb 13, 2014 at 5:51 PM, cowwoc wrote: >>> >>> On 13/02/2014 5:46 PM, Dave Taht wrote: >>>> >>>> The biggest downside, as I see it, is targeting advancements in the >>>> state >>>> of >>>> the art, at windows. 98% of the world or so run non-windows based cell >>>> phones and tablets, and in terms of total users, probably outnumber >>>> the windows contingent at this point. >>>> >>>> SCTP and MPTCP are quite feasible on android and IOS. >>> >>> >>> It doesn't matter how many smartphones there are. What matters is how >>> many >>> of them will be used to do meaningful video chat. The screen real estat= e >>> on >>> these devices is way too small. >> >> In my experience, everybody is using tablets and handheld devices for >> video chat. >> It is a natural extension of the usage of the device to extend it from >> phone calls >> to video calls. >> >> The lack of a working camera on most desktops is a hindrance, and the >> placement >> of cameras on most laptops is not ideal. > > > All laptops and tablets come with decent cameras. I will agree that WebRT= C > on tablets will be strong, but smartphones is really pushing it. Most of = the > time I've seen people engage in video chat it was between family members; > far less for business use. And in those cases, I've seen people jump on > tablets and laptops instead of having to deal with a tiny, underpowered > smartphone for video. These are just personal observations, not science, = so > please take them with a grain of salt. I will clarify what I said above is that what I observe among the under 20s is huge tablet and handheld use for videoconferencing. For business use I see primarily things like dedicated hardware, webex and to a smaller extent hangouts, and facetime. > Gili --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From nobody Thu Feb 13 17:20: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 23D801A0057; Thu, 13 Feb 2014 17:20:15 -0800 (PST) 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 Ex3zNUcuWE0c; Thu, 13 Feb 2014 17:20:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4982E1A0045; Thu, 13 Feb 2014 17:20:13 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214012013.22748.33800.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 17:20:13 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VLURWbmZGrh6DeW1jxd_NIXGvJs Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-05.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, 14 Feb 2014 01:20:15 -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-05.txt Pages : 6 Date : 2014-02-13 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-05 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 Thu Feb 13 22:24: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 AC16D1A00F3 for ; Thu, 13 Feb 2014 22:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 JUqbCGeFDPDe for ; Thu, 13 Feb 2014 22:24:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A3F011A00C0 for ; Thu, 13 Feb 2014 22:24:40 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDO68296; Fri, 14 Feb 2014 06:24:38 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 06:23:18 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 06:24:18 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 14:24:12 +0800 From: "Huangyihong (Rachel)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] WebRTC base P2P streaming Thread-Index: Ac8pTV94lElzeOuPTfGfsZYgp7Zvdg== Date: Fri, 14 Feb 2014 06:24:11 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4591F709@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.116] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB4591F709nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/khuut-DSqHf9AyTfIEEhdjvkozQ Subject: [rtcweb] WebRTC base P2P streaming X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Feb 2014 06:24:42 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB4591F709nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We have just published a draft in PPSP working group to discuss the current= emerging WebRTC based P2P streaming applications. If you're interested in = this, comments and suggestions are appreciated. http://tools.ietf.org/html/draft-huang-ppsp-p2p-webrtc-survey-00 This draft will be discussed in the PPSP WG in the coming London meeting. Best regards, Rachel --_000_51E6A56BD6A85142B9D172C87FC3ABBB4591F709nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We have just published a draft in PPSP working group= to discuss the current emerging WebRTC based P2P streaming applications. I= f you’re interested in this, comments and suggestions are appreciated= .

http://tools.ietf.org/html/draft-huang-ppsp-p2p-we= brtc-survey-00

This draft will be discussed in the PPSP WG in the c= oming London meeting.

 

Best regards,

Rachel

 

--_000_51E6A56BD6A85142B9D172C87FC3ABBB4591F709nkgeml501mbschi_-- From nobody Thu Feb 13 23:20: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 18BE81A0158 for ; Thu, 13 Feb 2014 23:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548, 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 yn-Hclm-Lwqg for ; Thu, 13 Feb 2014 23:20:35 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id B08501A014E for ; Thu, 13 Feb 2014 23:20:32 -0800 (PST) Received: from [192.168.1.200] (p508F0C3F.dip0.t-ipconnect.de [80.143.12.63]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 2BB4B1C0B4068; Fri, 14 Feb 2014 08:20:28 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Fri, 14 Feb 2014 08:20:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <836ACF58-5756-41EE-8665-01AB66ECD9D3@lurchi.franken.de> References: <52FD2FA4.8040701@alvestrand.no> To: Cb B X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OmeHhkblkX_3zgJsAvlN7J_jKz8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Feb 2014 07:20:40 -0000 On Feb 13, 2014, at 11:37 PM, Cb B wrote: > On Thu, Feb 13, 2014 at 2:32 PM, Ted Hardie = wrote: >> On Thu, Feb 13, 2014 at 1:20 PM, Cb B wrote: >>>=20 >>>=20 >>> But that's not the point. The question is can we include native = SCTP >>> as an option in draft-ietf-rtcweb-transports? What is the = downside? >>>=20 >>> CB >>=20 >>=20 >> Howdy, >>=20 >> Given previous decisions of the working group, you would need to = describe >> how to provide confidentiality. At the moment, I know only of TLS = over SCTP >> (which would reverse the current mapping) and SCTP over IPSec (which = would >> likely actually be IPSec/UDP); do you know of other methods which = would keep >> SCTP at the top layer of the protocol stack and still provide >> confidentiality? >>=20 >> regarsd, >>=20 >> Ted >>=20 >=20 > I believe the cleanest would be to do TLS over SCTP. I understand > that changes the top of the transport stack, and create variation. > But, i don't think current SCTP over DTLS plan has won any beauty > prizes. If this is standards track work that must stand the test of > time, TLS over SCTP seems appropriate. Using TLS over SCTP as defined in http://tools.ietf.org/search/rfc3436 doesn't support all features of SCTP, for example partial reliability, and it doesn't scale well (It needs a TLS connection per bidirectional stream, so per data channel in our case). Using DTLS over SCTP resolves these issues: http://tools.ietf.org/search/rfc6083 DTLS over SCTP is supported by OpenSSL. Best regards Michael >=20 > CB >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Fri Feb 14 01:15: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 331411A00A8; Fri, 14 Feb 2014 01:15:50 -0800 (PST) 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 dQ69lXldCFf4; Fri, 14 Feb 2014 01:15:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDA91A00C5; Fri, 14 Feb 2014 01:15:47 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214091547.5597.67045.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 01:15:47 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/T-jPofz2hzdzLU-t8-oIZ7wnhNY Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.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, 14 Feb 2014 09:15:50 -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 Filename : draft-ietf-rtcweb-jsep-06.txt Pages : 51 Date : 2014-02-14 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-06 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 Feb 14 02:20: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 AC7E91A01FB for ; Fri, 14 Feb 2014 02:20:56 -0800 (PST) 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 Mt5JxWQmo_22 for ; Fri, 14 Feb 2014 02:20:54 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 659B61A01C3 for ; Fri, 14 Feb 2014 02:20:54 -0800 (PST) Received: from [12.131.214.70] (port=52638 helo=[10.0.0.14]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WEFt6-000ECl-HX for rtcweb@ietf.org; Fri, 14 Feb 2014 04:20:52 -0600 Message-ID: <52FDEE06.1030003@jesup.org> Date: Fri, 14 Feb 2014 02:20:54 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xWRVaL_SNVKkskGFiNb7n7VULVk Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Feb 2014 10:20:57 -0000 On 2/12/2014 10:06 PM, Cb B wrote: > For about a year now, i have been very concerned about IPv4 UDP. It > has been increasingly associated with DDoS traffic [1], to the point > that the protocol's reputation is akin to IPv4 PING in 2003 (widely > blocked). The material point here is that IPv4 UDP is being > indiscriminately blocked and policed in access networks. This is not > something access networks are wantonly electing to do. This decision > is made in the heat of the moment to restore service to customers and > networks who are overrun with attack traffic [2]. And it is not > simply DNS, NTP, and chargen for simple filtering. > > My suggestion is that draft-ietf-rtcweb-transports be updated to > include SCTP as a transport type option. I understand that SCTP is > not supported on Windows (tm) and most NATs. Side note: it would be ironic to end up using DataChannel-over-SCTP-over-DTLS-over-SCTP > In general, we may find > that TURN / TRAM is a required local trust anchor in access networks, > just as local ISP-administered SMTP servers in access networks are > frequently required relay points since access networks block SMTP. [3] I certainly understand the reason for concern; but the idea that UDP would become limited to TURN-mediated is frightening and depressing (and whose TURN and how does the ISP know it's TURN-mediated unless it's an ISP's TURN?) One significant piece of the value proposition of WebRTC is that through use of ICE (and TURN) it will usually bypass the need for relays, significantly improving media quality (delay), dramatically cutting the cost of operation for services, easing deployment, and avoiding a number of levels of control/ability-to-block/etc. It's especially depressing in that we put significant effort into reducing the likelihood that WebRTC could be used for DDoS attacks. I will note that blocking UDP (or massively-rate-limiting it) will have all sorts of nasty effects on all forms of VoIP. TCP-entrained VoIP can evade that, but at a serious cost to call quality. Surely the operators know this. > This UDP concern is not an issue for IPv6, since IPv6 is not, as of > yet, been associated with these massive attacks. And when i say > massive, i mean massive [4]. And because of the scale and risk, > access networks are simply clamping IPv4 UDP throughput and moving on > and not looking back. Can the DNS amplification attack be used to hit any ports other than 53? Can clamps be limited to port 53 > I understand predicting the demise of UDP is not a popular opinion in > the IETF. But as a network operator, and stakeholder in the internet > / ietf / webrtc, i am hoping to share this information so that you all > can make well informed protocol decisions. Thank you -- Randell Jesup randell-ietf@jesup.org From nobody Fri Feb 14 06:22: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 03F9C1A0289 for ; Fri, 14 Feb 2014 06:22:53 -0800 (PST) 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_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 E0v9UlUxJl0F for ; Fri, 14 Feb 2014 06:22:51 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB491A025C for ; Fri, 14 Feb 2014 06:22:49 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-47-52fe26b7f624 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id E2.F2.04249.7B62EF25; Fri, 14 Feb 2014 15:22:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Fri, 14 Feb 2014 15:22:46 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - PeerConnection BUNDLE policy Thread-Index: Ac8pjtnjzyDELOBDTjiX88M43xAyxw== Date: Fri, 14 Feb 2014 14:22:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1730E7@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.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+Jvje52tX9BBsvvSFms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEf7DjIVvGOr+NCxna2BcS1rFyMnh4SAicTJRy1sELaYxIV7 64FsLg4hgSOMEkf2vWCCcBYzStx/PJ+li5GDg03AQqL7nzZIg4iAusTlhxfYQWxhgQSJNffX MELEEyVe/+5gg7D1JE4eXgpmswioSuxcdJ8FxOYV8JU4c7MBrJcRaPH3U2uYQGxmAXGJW0/m M0EcJCCxZM95ZghbVOLl439QRytJ/NhwiQWiXkdiwe5PbBC2tsSyha+ZIeYLSpyc+YRlAqPw LCRjZyFpmYWkZRaSlgWMLKsYOYpTi5Ny040MNjECA/nglt8WOxgv/7U5xCjNwaIkzvvxrXOQ kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsa9fWs3KEfFHJtmP6NObn+J/KzGlprAONeonZHq mn5pZ+LVJr31ksjKiP1Z9fbvbbd/iRUMN7TYvxf+8XL5OXfO/K5jM6pNt+XsipiX8HWvwy9t ibJP3cE7/c0jXFTqzdZcE7vqsZGnqMymzD7zinSHlFN4aEdai9XqNn+pDzfXP7x7NO5hsxJL cUaioRZzUXEiAAPq0yIyAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PXj0Uqi_ML4t9iEg2TNz_OTVwaY Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - PeerConnection BUNDLE policy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Feb 2014 14:22:53 -0000 Hi, Section 4.1.1. defines, for the PeerConnection constructor, the possibility= to specify BUNDLE policy. However, I am missing the possibility to indicate whether, within a BUNDLE = group, the same port number shall be used or not.=20 Section 5.2.1 does say: "o The port value is set to the port of the default ICE candidate for this m=3D section; if this m=3D section is not being bundled into another m=3D section, the port value MUST be unique." ...but, it doesn't talk about the case when the port IS being bundled into = another m=3D section. Normally, in the initial Offer, the port value will b= e unique also in that case, but if the PeerConnection is created due to for= king, and it is known that the remote peer supports BUNDLE, then identical = port values can be used already in the initial offer. Regards, Christer From nobody Fri Feb 14 06:26: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 348D01A0275 for ; Fri, 14 Feb 2014 06:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 MMlFkd53qHGv for ; Fri, 14 Feb 2014 06:26:46 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1A11A026F for ; Fri, 14 Feb 2014 06:26:45 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-23-52fe27a3d14f Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 63.6F.10875.3A72EF25; Fri, 14 Feb 2014 15:26:43 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Fri, 14 Feb 2014 15:26:43 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - SDP sctpmap attribute usage Thread-Index: Ac8pkGsqajJyywweSF21x5yZu3cFWA== Date: Fri, 14 Feb 2014 14:26:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D173112@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.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvje5i9X9BBsePa1ms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOYrH9kKtrBVrOl5wtzAOIO1i5GDQ0LARGLP6aouRk4gU0zi wr31bF2MXBxCAocYJd7eW8UKkhASWMwosaMRrJ5NwEKi+582SFhEQF3i8sML7CC2sEC8xNTt c9kh4gkS3be+sUHYehLvZm5jArFZBFQlPr3pYwaxeQV8JSb+Xg82nhFo7/dTa8BqmAXEJW49 mc8EcY+AxJI955khbFGJl4//sULYShI/NlxigajXkViw+xMbhK0tsWzha6j5ghInZz5hmcAo PAvJ2FlIWmYhaZmFpGUBI8sqRvbcxMyc9HLDTYzAED645bfuDsZT50QOMUpzsCiJ83546xwk JJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdFmcb/DtesvvNdMaF6y/umNXi61tVrPeeb9KH96 6c+6e8fmbeMOfHu33mtK+CRuDcNlCusSzy8o+xkiJR0taW/7w++O8a4IxTU/Ni8TfsK5MuHY hq33PreyWZStYMi39g0sNP7t6c26pOvfpZ+cd3PtZ92smM5xfO/Sz/ZqjNEfWH+uCNwrpuGj xFKckWioxVxUnAgAATyN6i8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/a_nBeOEernihFQercl7k3kAHt1U Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - SDP sctpmap attribute 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: Fri, 14 Feb 2014 14:26:47 -0000 Hi, Section 5.2.1 says: "Within the data m=3D section, the "a=3Dmid", "a=3Dice-ufrag", "a=3Dice- passwd", "a=3Dice-options", "a=3Dcandidate", "a=3Dfingerprint", and "a=3Dsetup" lines MUST be included as mentioned above, along with an "a=3Dsctpmap" line referencing the SCTP port number and specifying the application protocol indicated in [I-D.ietf-rtcweb-data-protocol]." The statement that the sctpmap attribute specifies the application protocol= indicate in the DCP is not aligned with the sctp-sdp draft. The sctp-sdp d= raft specifies that the attribute specifies the application running on top = of the SCTP association - which in this case is the WebRTC Data Channel. Th= e protocol running on top of that data channel is then specified in the DCP= . Regards, Christer From nobody Fri Feb 14 06:42: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 8B3191A026C for ; Fri, 14 Feb 2014 06:42:49 -0800 (PST) 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 t6wEiyY2NTEE for ; Fri, 14 Feb 2014 06:42:47 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id B21391A0253 for ; Fri, 14 Feb 2014 06:42:46 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hi5so533364wib.2 for ; Fri, 14 Feb 2014 06:42:44 -0800 (PST) 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=2CUFOAJAcJmBtI82IcmS81LnBklHOKQPKFtR6ZuseaQ=; b=Dgbs6lkJkdHKxMb6ANE+Zavqb58i6jhfbwfXOPoRPvIldR83Aw300hAe+wINoGFisz ZcNCumV3iPCrJxDLNIGT0SJGlMAzgjBd2rZUGSqlG64KRsY0DYkfWkuVFquUxEHvuCi+ jCx+VX2iEMRpKaoW2MGgTkdiFiwDj+bAIe1PnmJHbIy2bvw8i985mpdNn2iDi083a3JO qBFExZ2eyMb1eq6p0sHn6ho4AQdFI/CvLQa5jBRWM8QSM7+5YAA2X061ImicxLpt9cvl tbauqyoIfW96akIvhjpUmhz69XR3l5Tx2PtQNhLwHyijuFW+bUhqQIZS2JY8hlpi071J kqog== MIME-Version: 1.0 X-Received: by 10.181.12.16 with SMTP id em16mr2601126wid.3.1392388964467; Fri, 14 Feb 2014 06:42:44 -0800 (PST) Received: by 10.194.133.169 with HTTP; Fri, 14 Feb 2014 06:42:44 -0800 (PST) Received: by 10.194.133.169 with HTTP; Fri, 14 Feb 2014 06:42:44 -0800 (PST) In-Reply-To: <52FDEE06.1030003@jesup.org> References: <52FDEE06.1030003@jesup.org> Date: Fri, 14 Feb 2014 06:42:44 -0800 Message-ID: From: Cb B To: Randell Jesup Content-Type: multipart/alternative; boundary=f46d0434c0a09dc9b804f25ed11a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kiKg-aIBJ2Ip9vPingaGve5_Q2I Cc: rtcweb@ietf.org Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Feb 2014 14:42:49 -0000 --f46d0434c0a09dc9b804f25ed11a Content-Type: text/plain; charset=ISO-8859-1 On Feb 14, 2014 2:20 AM, "Randell Jesup" wrote: > > On 2/12/2014 10:06 PM, Cb B wrote: >> >> For about a year now, i have been very concerned about IPv4 UDP. It >> has been increasingly associated with DDoS traffic [1], to the point >> that the protocol's reputation is akin to IPv4 PING in 2003 (widely >> blocked). The material point here is that IPv4 UDP is being >> indiscriminately blocked and policed in access networks. This is not >> something access networks are wantonly electing to do. This decision >> is made in the heat of the moment to restore service to customers and >> networks who are overrun with attack traffic [2]. And it is not >> simply DNS, NTP, and chargen for simple filtering. >> >> My suggestion is that draft-ietf-rtcweb-transports be updated to >> include SCTP as a transport type option. I understand that SCTP is >> not supported on Windows (tm) and most NATs. > > > Side note: it would be ironic to end up using DataChannel-over-SCTP-over-DTLS-over-SCTP > The history of p2p applications such as skype have shown history favors the nimble. > >> In general, we may find >> that TURN / TRAM is a required local trust anchor in access networks, >> just as local ISP-administered SMTP servers in access networks are >> frequently required relay points since access networks block SMTP. [3] > > > I certainly understand the reason for concern; but the idea that UDP would become limited to TURN-mediated is frightening and depressing (and whose TURN and how does the ISP know it's TURN-mediated unless it's an ISP's TURN?) > > One significant piece of the value proposition of WebRTC is that through use of ICE (and TURN) it will usually bypass the need for relays, significantly improving media quality (delay), dramatically cutting the cost of operation for services, easing deployment, and avoiding a number of levels of control/ability-to-block/etc. > > It's especially depressing in that we put significant effort into reducing the likelihood that WebRTC could be used for DDoS attacks. > > I will note that blocking UDP (or massively-rate-limiting it) will have all sorts of nasty effects on all forms of VoIP. TCP-entrained VoIP can evade that, but at a serious cost to call quality. Surely the operators know this. > Agreed on all points. My view is one related to the basic requirement of keeping the network up. I hope i have provided enough reference points to make the magnitude of the problem clear as well as how history has shown protocols get blocked (smtp) > >> This UDP concern is not an issue for IPv6, since IPv6 is not, as of >> yet, been associated with these massive attacks. And when i say >> massive, i mean massive [4]. And because of the scale and risk, >> access networks are simply clamping IPv4 UDP throughput and moving on >> and not looking back. > > > Can the DNS amplification attack be used to hit any ports other than 53? Can clamps be limited to port 53 > Right. The source port will be a function of the amp server such as 53, 123, 19... all very common. The destination port is of the spoofers choosing. But, as the us-cert advisory notes, there are several impacted appilication ports. Well-known webrtc fixed ports would help for a white list. Creating a blacklist of just 53, 123, 19 makes us still behind the curve on whatever is next. CB > >> I understand predicting the demise of UDP is not a popular opinion in >> the IETF. But as a network operator, and stakeholder in the internet >> / ietf / webrtc, i am hoping to share this information so that you all >> can make well informed protocol decisions. > > > Thank you > > > -- > Randell Jesup > randell-ietf@jesup.org > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --f46d0434c0a09dc9b804f25ed11a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Feb 14, 2014 2:20 AM, "Randell Jesup" <randell-ietf@jesup.org> wrote:
>
> On 2/12/2014 10:06 PM, Cb B wrote:
>>
>> For about a year now, i have been very concerned about IPv4 UDP. = =A0It
>> has been increasingly associated with DDoS traffic [1], to the poi= nt
>> that the protocol's reputation is akin to IPv4 PING in 2003 (w= idely
>> blocked). =A0The material point here is that IPv4 UDP is being
>> indiscriminately blocked and policed in access networks. =A0This i= s not
>> something access networks are wantonly electing to do. This decisi= on
>> is made in the heat of the moment to restore service to customers = and
>> networks who are overrun with attack traffic [2]. =A0And it is not=
>> simply DNS, NTP, and chargen for simple filtering.
>>
>> My suggestion is that draft-ietf-rtcweb-transports be updated to >> include SCTP as a transport type option. =A0I understand that SCTP= is
>> not supported on Windows (tm) and most NATs.
>
>
> Side note: it would be ironic to end up using DataChannel-over-SCTP-ov= er-DTLS-over-SCTP
>

The history of p2p applications such as skype have shown his= tory favors the nimble.

>
>> In general, we may find
>> that TURN / TRAM is a required local trust anchor in access networ= ks,
>> just as local ISP-administered SMTP servers in access networks are=
>> frequently required relay points since access networks block SMTP.= [3]
>
>
> I certainly understand the reason for concern; but the idea that UDP w= ould become limited to TURN-mediated is frightening and depressing (and who= se TURN and how does the ISP know it's TURN-mediated unless it's an= ISP's TURN?)
>
> One significant piece of the value proposition of WebRTC is that throu= gh use of ICE (and TURN) it will usually bypass the need for relays, signif= icantly improving media quality (delay), dramatically cutting the cost of o= peration for services, easing deployment, and avoiding a number of levels o= f control/ability-to-block/etc.
>
> It's especially depressing in that we put significant effort into = reducing the likelihood that WebRTC could be used for DDoS attacks.
>
> I will note that blocking UDP (or massively-rate-limiting it) will hav= e all sorts of nasty effects on all forms of VoIP. =A0TCP-entrained VoIP ca= n evade that, but at a serious cost to call quality. =A0Surely the operator= s know this.
>

Agreed on all points. My view is one related to the basic re= quirement of keeping the network up.=A0 I hope i have provided enough refer= ence points to make the magnitude of the problem clear as well as how histo= ry has shown protocols get blocked (smtp)

>
>> This UDP concern is not an issue for IPv6, since IPv6 is not, as o= f
>> yet, been associated with these massive attacks. =A0And when i say=
>> massive, i mean massive [4]. =A0And because of the scale and risk,=
>> access networks are simply clamping IPv4 UDP throughput and moving= on
>> and not looking back.
>
>
> Can the DNS amplification attack be used to hit any ports other than 5= 3? =A0Can clamps be limited to port 53
>

Right. The source port will be a function of the amp server = such as 53, 123, 19... all very common. The destination port is of the spoo= fers choosing.

But, as the us-cert advisory notes, there are several impact= ed appilication ports. Well-known webrtc fixed ports would help for a white= list.

Creating a blacklist of just 53, 123, 19 makes us still behi= nd the curve on whatever is next.

CB

>
>> I =A0understand predicting the demise of UDP is not a popular opin= ion in
>> the IETF. =A0But as a network operator, and stakeholder in the int= ernet
>> / ietf / webrtc, i am hoping to share this information so that you= all
>> can make well informed protocol decisions.
>
>
> Thank you
>
>
> --
> Randell Jesup
> randell-ietf@jesup.org >
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb
=A0

--f46d0434c0a09dc9b804f25ed11a-- From nobody Fri Feb 14 08:46: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 056AB1A02A3 for ; Fri, 14 Feb 2014 08:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hB_qkyxPwO7F for ; Fri, 14 Feb 2014 08:46:28 -0800 (PST) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by ietfa.amsl.com (Postfix) with ESMTP id CF6F31A02FA for ; Fri, 14 Feb 2014 08:46:22 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id uy5so14156625obc.19 for ; Fri, 14 Feb 2014 08:46:21 -0800 (PST) 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; bh=NQpTb+rGbpQwCnrlra6zAjwCShdMQgjqeN3KSL2Kj1Y=; b=hFPvoYJMCNpDkS5V6htKO2bRgF5RvxcURIQ/R3Pc5o0V0zMmXE24JDYobv2fRIvzid z30lqY94skwfVbndYQUIHy5iGgwem1ORUeXBMFafywko2Sab6wBhtZ95xXZ7cO5UPMJR M82qHIQl3XUDas44W9zmmN2BxQJy+0I7HKOK+zGawj7FiZ5bM0QYsamgBUxNti+3OoId +ZaS8StZL4Ib7PHgycyH1M+89PiRyY66EuydIuZlwNCl9WhO5I19ob5SBHOklQGELc2K E0HbHygOxuZuwaYQVCzhfMnDQQnc/cy/SGnhb8pmR2ZBuQwWxrDS7kZvN+51JOkATUUq FRig== X-Gm-Message-State: ALoCoQlii6uJ5oyX6+06FcdGPBOUnqZwt8t2o3ipYNJbs7M/4oiYiJ6Zx3IriAlp374hx0OGpO2W X-Received: by 10.182.33.102 with SMTP id q6mr7383862obi.8.1392396381164; Fri, 14 Feb 2014 08:46:21 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id tr10sm17569420obb.6.2014.02.14.08.46.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Feb 2014 08:46:20 -0800 (PST) Message-ID: <52FE4851.3000206@bbs.darktech.org> Date: Fri, 14 Feb 2014 11:46:09 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52FDEE06.1030003@jesup.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000709040700070400090005" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9fHjhsJA5CuoIJPf6QREHzsv60k Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Feb 2014 16:46:31 -0000 This is a multi-part message in MIME format. --------------000709040700070400090005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 14/02/2014 9:42 AM, Cb B wrote: > Right. The source port will be a function of the amp server such as > 53, 123, 19... all very common. The destination port is of the > spoofers choosing. > > But, as the us-cert advisory notes, there are several impacted > appilication ports. Well-known webrtc fixed ports would help for a > white list. > > Creating a blacklist of just 53, 123, 19 makes us still behind the > curve on whatever is next. > Which is why we will never be able to stop DDoS attacks: 1. With dumb firewall rules that rely upon port numbers alone. 2. Unless the destination address is able to communicate back to the source (or as close as possible to the source) that it does not wish to continue receiving (any) packets from it, and in so doing pushes the problem back as far as possible to the source. Gili --------------000709040700070400090005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 14/02/2014 9:42 AM, Cb B wrote:
Right. The source port will be a function of the amp server such as 53, 123, 19... all very common. The destination port is of the spoofers choosing.

But, as the us-cert advisory notes, there are several impacted appilication ports. Well-known webrtc fixed ports would help for a white list.

Creating a blacklist of just 53, 123, 19 makes us still behind the curve on whatever is next.


Which is why we will never be able to stop DDoS attacks:
  1. With dumb firewall rules that rely upon port numbers alone.
  2. Unless the destination address is able to communicate back to the source (or as close as possible to the source) that it does not wish to continue receiving (any) packets from it, and in so doing pushes the problem back as far as possible to the source.

Gili

--------------000709040700070400090005-- From nobody Fri Feb 14 10:06: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 149D61A0371 for ; Fri, 14 Feb 2014 10:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.345 X-Spam-Level: X-Spam-Status: No, score=0.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 fYcQ1S5kpTZa for ; Fri, 14 Feb 2014 10:06:52 -0800 (PST) Received: from mork.alvestrand.no (unknown [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 73C8C1A037E for ; Fri, 14 Feb 2014 10:06:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5888F7C4CF1 for ; Fri, 14 Feb 2014 19:06:50 +0100 (CET) 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 p2wrxDaJN6mL for ; Fri, 14 Feb 2014 19:06:50 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id B03417C4CF0 for ; Fri, 14 Feb 2014 19:06:49 +0100 (CET) Message-ID: <52FE5B37.80409@alvestrand.no> Date: Fri, 14 Feb 2014 19:06:47 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <52FDC17E.8070708@alvestrand.no> In-Reply-To: <52FDC17E.8070708@alvestrand.no> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <52FDC17E.8070708@alvestrand.no> Content-Type: multipart/alternative; boundary="------------090201050803040603040600" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wA5RAEp7W-0k1o63nQC5vKfVIjg Subject: [rtcweb] Stream control: [MMUSIC] msid-04 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Feb 2014 18:06:56 -0000 This is a multi-part message in MIME format. --------------090201050803040603040600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I created a proposal for how one could signal the receiver's desires for handling of a MediaStream as an extension to the MSID proposal. The result is in draft-ietf-mmusic-msid-04 section 5. There will be discussion in MMUSIC; comments on whether the mechanism fits the RTCWEB need may be appropriate here. Harald -------- Original Message -------- Subject: [MMUSIC] msid-04 submitted Date: Fri, 14 Feb 2014 08:10:54 +0100 From: Harald Alvestrand To: mmusic I have submitted a new version of the MSID draft, -04. It tries to make it crystal clear that the msid-semantic:wms is only intended for signalling MediaStreamTracks and MediaStreams. It also adds a new functionality: msid-control, which can be used by a receiver of MediaStreamTracks to signal the sender of a MediaStreamTrack what the receiver wishes with regard to that MediaStreamTrack; this need has been identified within the WebRTC and RTCWEB WGs. It seemed logical to extend this draft with that functionality, since it is closely allied functionality. Comments are welcome. Harald -- Surveillance is pervasive. Go Dark. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------090201050803040603040600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I created a proposal for how one could signal the receiver's desires for handling of a MediaStream as an extension to the MSID proposal.

The result is in draft-ietf-mmusic-msid-04 section 5.

There will be discussion in MMUSIC; comments on whether the mechanism fits the RTCWEB need may be appropriate here.

         Harald

-------- Original Message --------
Subject: [MMUSIC] msid-04 submitted
Date: Fri, 14 Feb 2014 08:10:54 +0100
From: Harald Alvestrand <harald@alvestrand.no>
To: mmusic <mmusic@ietf.org> 


I have submitted a new version of the MSID draft, -04.

It tries to make it crystal clear that the msid-semantic:wms is only
intended for signalling MediaStreamTracks and MediaStreams.

It also adds a new functionality: msid-control, which can be used by a
receiver of MediaStreamTracks to signal the sender of a MediaStreamTrack
what the receiver wishes with regard to that MediaStreamTrack; this need
has been identified within the WebRTC and RTCWEB WGs.

It seemed logical to extend this draft with that functionality, since it
is closely allied functionality.

Comments are welcome.

          Harald

-- 
Surveillance is pervasive. Go Dark.

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


--------------090201050803040603040600-- From nobody Fri Feb 14 10:24: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 5DDDB1A03C8 for ; Fri, 14 Feb 2014 10:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] 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 XGltAEw1gjTv for ; Fri, 14 Feb 2014 10:24:06 -0800 (PST) Received: from mork.alvestrand.no (unknown [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 1916C1A03CC for ; Fri, 14 Feb 2014 10:24:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 33EA07C4CF1 for ; Fri, 14 Feb 2014 19:24:04 +0100 (CET) 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 Zkba+25YVKI0 for ; Fri, 14 Feb 2014 19:24:04 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id B140A7C4CF0 for ; Fri, 14 Feb 2014 19:24:03 +0100 (CET) Message-ID: <52FE5F41.1010106@alvestrand.no> Date: Fri, 14 Feb 2014 19:24:01 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52FDEE06.1030003@jesup.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UnzKrp-ODkpS2-AFQW386dkwKVg Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Feb 2014 18:24:07 -0000 On 02/14/2014 03:42 PM, Cb B wrote: > > > It's especially depressing in that we put significant effort into > reducing the likelihood that WebRTC could be used for DDoS attacks. > > > > I will note that blocking UDP (or massively-rate-limiting it) will > have all sorts of nasty effects on all forms of VoIP. TCP-entrained > VoIP can evade that, but at a serious cost to call quality. Surely > the operators know this. > > > > Agreed on all points. My view is one related to the basic requirement > of keeping the network up. I hope i have provided enough reference > points to make the magnitude of the problem clear as well as how > history has shown protocols get blocked (smtp) > This SMTP example doesn't match what I've seen happen. SMTP is not blocked by any backbone service provider I know of. Outgoing SMTP on port 25 is commonly blocked by firewalls that think they don't have servers behind them (hotels are notorious in this aspect). That's why the submit port is popular (and deployed with authentication). The main concern isn't DDOS attacks, it's being blamed for spam. I've not seen any report of a DDOS attack that used port 25 for a traffic-volume-based attack (although intentional or unintentional DDOS attacks on mail servers are too common to care about). Given that I still haven't seen a report that leads me to belive we'll ever see a proposal that seriously proposes blocking all UDP traffic on the Internet - I continue to disbelieve the premise, so it's not surprising that I disagree with the conclusion. -- Surveillance is pervasive. Go Dark. From nobody Fri Feb 14 10:42: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 710371A0214 for ; Fri, 14 Feb 2014 10:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 8BqKl4YTuSid for ; Fri, 14 Feb 2014 10:42:01 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 70B181A02E3 for ; Fri, 14 Feb 2014 10:41:59 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-63-52fe6375be16 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 59.0C.23809.5736EF25; Fri, 14 Feb 2014 19:41:57 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0387.000; Fri, 14 Feb 2014 19:41:56 +0100 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Stream control: [MMUSIC] msid-04 submitted Thread-Index: AQHPKVPuF/VJzX0Fb0yVt/Xv3TzOfJq0+6GAgAAXm1Q= Date: Fri, 14 Feb 2014 18:41:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1735EE@ESESSMB209.ericsson.se> References: <52FDC17E.8070708@alvestrand.no>,<52FE5B37.80409@alvestrand.no> In-Reply-To: <52FE5B37.80409@alvestrand.no> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+JvjW5p8r8gg4uzRC2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGVc//eeteCvSEXzjrnsDYz/BboYOTkkBEwk Xm+9ww5hi0lcuLeerYuRi0NI4BCjxM7bC1ghnMWMEot27AKq4uBgE7CQ6P6nDdIgIhAs0fv8 PSNIWFjAQeLIYz6IsKPEnK3LmSBsK4nX2ztZQWwWAVWJXdsugk3hFfCVeHe/CCQsJOAtsflT IyOIzSmgLbF431Owckagc76fWgM2hllAXOLWk/lMEGcKSCzZc54ZwhaVePn4HyvISAkBJYlp W9MgynUkFuz+xAZha0ssW/garJxXQFDi5MwnLBMYRWchmToLScssJC2zkLQsYGRZxciem5iZ k15utIkRGAUHt/xW3cF455zIIUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBK NTBOjc9unC+X9ydRPvKy7dyq+uOb9mSu5zubJ/MprkGGc9rXX+pxrU/YS4z2/Vw5f1/R640i p3U5FvD2sggbHt/h9UFGYn7iYkvxPs9pdV82Fey4ksY7P7pA8hD3mVMb4z+L1V+xs45+5mk8 t4kxQOey0TGfI/tePmua/8PSM+/N78QjnznkuByVWIozEg21mIuKEwGWV9foUAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/phOKJVEmSabYHGCpEUX4fTLe5bQ Subject: Re: [rtcweb] Stream control: [MMUSIC] msid-04 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Feb 2014 18:42:03 -0000 Hi Harald, When reading the text, my take is that this is more than controlling a MS a= nd MST. You are actaually OVERRIDING the rules for sending RTCP. The rules say that= RTCP is always sent, as long as the m- line is enabled (non-zero port valu= e). Regarding "msid-control: enable", I don't think this is needed at all. The = DEFAULT is whatever is the value of the existing direction attributes. Regarding "msid-control: disable", what is the difference compared to using= "sendonly"? Regarding "msid-control: reject", what couldn't you use "msid-control: stop= " instead? If the stream has never been enabled, doesn't stop and reject me= an the same thing? Regarding "msid-control: stop", the text says that one guarantees that the = track will not be used again. But, I assume the m- line could still be used= for sending media, for another track (assuming we allow associating an m- = line with another track, that is)? Regards, Christer ________________________________________ From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Harald Alvestrand [hara= ld@alvestrand.no] Sent: Friday, 14 February 2014 8:06 PM To: rtcweb@ietf.org Subject: [rtcweb] Stream control: [MMUSIC] msid-04 submitted I created a proposal for how one could signal the receiver's desires for ha= ndling of a MediaStream as an extension to the MSID proposal. The result is in draft-ietf-mmusic-msid-04 section 5. There will be discussion in MMUSIC; comments on whether the mechanism fits = the RTCWEB need may be appropriate here. Harald -------- Original Message -------- Subject: [MMUSIC] msid-04 submitted Date: Fri, 14 Feb 2014 08:10:54 +0100 From: Harald Alvestrand To: mmusic I have submitted a new version of the MSID draft, -04. It tries to make it crystal clear that the msid-semantic:wms is only intended for signalling MediaStreamTracks and MediaStreams. It also adds a new functionality: msid-control, which can be used by a receiver of MediaStreamTracks to signal the sender of a MediaStreamTrack what the receiver wishes with regard to that MediaStreamTrack; this need has been identified within the WebRTC and RTCWEB WGs. It seemed logical to extend this draft with that functionality, since it is closely allied functionality. Comments are welcome. Harald -- Surveillance is pervasive. Go Dark. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Feb 14 10:54: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 36AB01A03A8 for ; Fri, 14 Feb 2014 10:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 b2XnoyLLD_Sv for ; Fri, 14 Feb 2014 10:54:11 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 401781A0390 for ; Fri, 14 Feb 2014 10:54:08 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u56so9107253wes.16 for ; Fri, 14 Feb 2014 10:54:06 -0800 (PST) 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=uOHldLGex53bmiWfJEdhgiY7mkII6sbilbQC8KWLQBI=; b=jkmpcR1j1p4IBKmFsuKH1r7thWkWzUfakYB1l0aCvWkCB3r6UwGkxyS8QZSYfrcLZL 1yR20Mgz/sHeU0Sqn6GGSIwDVSSmG/arGHcITQuhUJ/qP99huNVTNArKtdlxb6iQArW8 WiT03gtCm74rfIWcbMqrnV0KxBZVwY0UcyCc1zcrPx7ykqEI2trkIdp/xj517VgAAU7i YjtLZPqHJgy0kp9jenRgFfHqOA6KTOaCowOQmS/tdSUgJOoK16Up+HWbI2ACCVXDocJW 3LqGlj0TnzIdKnUgvNNqBikK7GAF71Hra8FkkFmcsrZLjjY4PYBAnzdUIfmydj29zMIs Mviw== MIME-Version: 1.0 X-Received: by 10.194.202.230 with SMTP id kl6mr7582617wjc.9.1392404046219; Fri, 14 Feb 2014 10:54:06 -0800 (PST) Received: by 10.194.133.169 with HTTP; Fri, 14 Feb 2014 10:54:06 -0800 (PST) In-Reply-To: <52FE5F41.1010106@alvestrand.no> References: <52FDEE06.1030003@jesup.org> <52FE5F41.1010106@alvestrand.no> Date: Fri, 14 Feb 2014 10:54:06 -0800 Message-ID: From: Cb B To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HvuYPLW4bSO72T8la-sgC9I0Vf0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Feb 2014 18:54:13 -0000 On Fri, Feb 14, 2014 at 10:24 AM, Harald Alvestrand wrote: > On 02/14/2014 03:42 PM, Cb B wrote: >> >> > It's especially depressing in that we put significant effort into >> reducing the likelihood that WebRTC could be used for DDoS attacks. >> > >> > I will note that blocking UDP (or massively-rate-limiting it) will >> have all sorts of nasty effects on all forms of VoIP. TCP-entrained >> VoIP can evade that, but at a serious cost to call quality. Surely >> the operators know this. >> > >> >> Agreed on all points. My view is one related to the basic requirement >> of keeping the network up. I hope i have provided enough reference >> points to make the magnitude of the problem clear as well as how >> history has shown protocols get blocked (smtp) >> > This SMTP example doesn't match what I've seen happen. > > SMTP is not blocked by any backbone service provider I know of. > > Outgoing SMTP on port 25 is commonly blocked by firewalls that think > they don't have servers behind them (hotels are notorious in this > aspect). That's why the submit port is popular (and deployed with > authentication). The main concern isn't DDOS attacks, it's being blamed > for spam. > Spam is a type of attack. It is an L7 attack as opposed to a volume attack. The largest broadband ISP in the USA blocks port 25, i provided this info in my first email. http://customer.comcast.com/help-and-support/internet/email-port-25-no-longer-supported/ > I've not seen any report of a DDOS attack that used port 25 for a > traffic-volume-based attack (although intentional or unintentional DDOS > attacks on mail servers are too common to care about). > > Given that I still haven't seen a report that leads me to belive we'll > ever see a proposal that seriously proposes blocking all UDP traffic on > the Internet - I continue to disbelieve the premise, so it's not > surprising that I disagree with the conclusion. > That's fine. It is not my goal to block UDP or save WebRTC. I am just submitting information that i have and connecting the dots that are in front of me. The future may show that i am too pessimistic or not enough. CB > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Feb 14 11:52: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 1906F1A0393; Fri, 14 Feb 2014 11:52:20 -0800 (PST) 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 wGLZQX3zirac; Fri, 14 Feb 2014 11:52:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE52E1A0397; Fri, 14 Feb 2014 11:51:31 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214195131.12199.3422.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 11:51:31 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/d1rpTxXNoA-U8miOYSdz256ZhGU Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-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: Fri, 14 Feb 2014 19:52:20 -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-12.txt Pages : 41 Date : 2014-02-14 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-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 Fri Feb 14 12:44: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 BF3591A030A for ; Fri, 14 Feb 2014 12:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 FGr1wsVkbY4Z for ; Fri, 14 Feb 2014 12:44:49 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 8864D1A02AF for ; Fri, 14 Feb 2014 12:44:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 75D027C4CF8; Fri, 14 Feb 2014 21:44:47 +0100 (CET) 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 CdBxbPxzqZ3B; Fri, 14 Feb 2014 21:44:47 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id AB1717C4CF7; Fri, 14 Feb 2014 21:44:46 +0100 (CET) Message-ID: <52FE803C.8040103@alvestrand.no> Date: Fri, 14 Feb 2014 21:44:44 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Christer Holmberg , "rtcweb@ietf.org" References: <52FDC17E.8070708@alvestrand.no>, <52FE5B37.80409@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1735EE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1735EE@ESESSMB209.ericsson.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tg3G5M9_1rfhcGS8zhaLOK-yqOc Subject: Re: [rtcweb] Stream control: [MMUSIC] msid-04 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Feb 2014 20:44:54 -0000 On 02/14/2014 07:41 PM, Christer Holmberg wrote: > Hi Harald, > > When reading the text, my take is that this is more than controlling a MS and MST. > > You are actaually OVERRIDING the rules for sending RTCP. The rules say that RTCP is always sent, as long as the m- line is enabled (non-zero port value). Yep, I think I'm repeating that. The question is not if RTCP is sent, it's if this SSID is included in the RTCP sender report or not - which the rules for RTCP do *not* dictate. > > Regarding "msid-control: enable", I don't think this is needed at all. The DEFAULT is whatever is the value of the existing direction attributes. I don't think it's needed either. I included it for completeness. > > Regarding "msid-control: disable", what is the difference compared to using "sendonly"? > > Regarding "msid-control: reject", what couldn't you use "msid-control: stop" instead? If the stream has never been enabled, doesn't stop and reject mean the same thing? As I said in the draft, I wonder about that too. People have talked about rejecting a track at the API level; if they come out with a sensible proposal, this should not prevent them. Personally, my API preference is a model where tracks occur, and if you don't want them, you have to stop them; I don't see a need for "reject". But others might. > > Regarding "msid-control: stop", the text says that one guarantees that the track will not be used again. But, I assume the m- line could still be used for sending media, for another track (assuming we allow associating an m- line with another track, that is)? Do we allow that? I don't know, and that's a problem. > > Regards, > > Christer > ________________________________________ > From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Harald Alvestrand [harald@alvestrand.no] > Sent: Friday, 14 February 2014 8:06 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Stream control: [MMUSIC] msid-04 submitted > > I created a proposal for how one could signal the receiver's desires for handling of a MediaStream as an extension to the MSID proposal. > > The result is in draft-ietf-mmusic-msid-04 section 5. > > There will be discussion in MMUSIC; comments on whether the mechanism fits the RTCWEB need may be appropriate here. > > Harald > > -------- Original Message -------- > Subject: [MMUSIC] msid-04 submitted > Date: Fri, 14 Feb 2014 08:10:54 +0100 > From: Harald Alvestrand > To: mmusic > > > > I have submitted a new version of the MSID draft, -04. > > It tries to make it crystal clear that the msid-semantic:wms is only > intended for signalling MediaStreamTracks and MediaStreams. > > It also adds a new functionality: msid-control, which can be used by a > receiver of MediaStreamTracks to signal the sender of a MediaStreamTrack > what the receiver wishes with regard to that MediaStreamTrack; this need > has been identified within the WebRTC and RTCWEB WGs. > > It seemed logical to extend this draft with that functionality, since it > is closely allied functionality. > > Comments are welcome. > > Harald > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > -- Surveillance is pervasive. Go Dark. From nobody Fri Feb 14 12:50: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 836CC1A03D0 for ; Fri, 14 Feb 2014 12:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 L2yf2j_ImCAV for ; Fri, 14 Feb 2014 12:50:48 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 334421A0045 for ; Fri, 14 Feb 2014 12:50:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E20A77C4CF8; Fri, 14 Feb 2014 21:50:40 +0100 (CET) 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 YLjy2lJKynMc; Fri, 14 Feb 2014 21:50:40 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1CF087C4CF7; Fri, 14 Feb 2014 21:50:39 +0100 (CET) Message-ID: <52FE819E.2010500@alvestrand.no> Date: Fri, 14 Feb 2014 21:50:38 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Cb B References: <52FDEE06.1030003@jesup.org> <52FE5F41.1010106@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/V2zJwGqZfsP05kFrMYl5A_TlF-k Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Feb 2014 20:50:51 -0000 On 02/14/2014 07:54 PM, Cb B wrote: > On Fri, Feb 14, 2014 at 10:24 AM, Harald Alvestrand > wrote: >> On 02/14/2014 03:42 PM, Cb B wrote: >>>> It's especially depressing in that we put significant effort into >>> reducing the likelihood that WebRTC could be used for DDoS attacks. >>>> I will note that blocking UDP (or massively-rate-limiting it) will >>> have all sorts of nasty effects on all forms of VoIP. TCP-entrained >>> VoIP can evade that, but at a serious cost to call quality. Surely >>> the operators know this. >>> Agreed on all points. My view is one related to the basic requirement >>> of keeping the network up. I hope i have provided enough reference >>> points to make the magnitude of the problem clear as well as how >>> history has shown protocols get blocked (smtp) >>> >> This SMTP example doesn't match what I've seen happen. >> >> SMTP is not blocked by any backbone service provider I know of. >> >> Outgoing SMTP on port 25 is commonly blocked by firewalls that think >> they don't have servers behind them (hotels are notorious in this >> aspect). That's why the submit port is popular (and deployed with >> authentication). The main concern isn't DDOS attacks, it's being blamed >> for spam. >> > Spam is a type of attack. It is an L7 attack as opposed to a volume attack. > > > The largest broadband ISP in the USA blocks port 25, i provided this > info in my first email. > > http://customer.comcast.com/help-and-support/internet/email-port-25-no-longer-supported/ I believe this is consistent with what I said. They block it *for residential customers*. That's why I said "by backbone providers" above. If port 25 was blocked by backbone providers, we would not be having this conversation in this medium; from your message: 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 l5OItdTpHJNZ for ; Fri, 14 Feb 2014 19:54:12 +0100 (CET) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mork.alvestrand.no (Postfix) with ESMTPS id D71377C4CF1 for ; Fri, 14 Feb 2014 19:54:11 +0100 (CET) Received: by mail-wg0-f50.google.com with SMTP id z12so676422wgg.17 for ; Fri, 14 Feb 2014 10:54:07 -0800 (PST) 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=uOHldLGex53bmiWfJEdhgiY7mkII6sbilbQC8KWLQBI=; b=jkmpcR1j1p4IBKmFsuKH1r7thWkWzUfakYB1l0aCvWkCB3r6UwGkxyS8QZSYfrcLZL 1yR20Mgz/sHeU0Sqn6GGSIwDVSSmG/arGHcITQuhUJ/qP99huNVTNArKtdlxb6iQArW8 WiT03gtCm74rfIWcbMqrnV0KxBZVwY0UcyCc1zcrPx7ykqEI2trkIdp/xj517VgAAU7i YjtLZPqHJgy0kp9jenRgFfHqOA6KTOaCowOQmS/tdSUgJOoK16Up+HWbI2ACCVXDocJW 3LqGlj0TnzIdKnUgvNNqBikK7GAF71Hra8FkkFmcsrZLjjY4PYBAnzdUIfmydj29zMIs Mviw== MIME-Version: 1.0 X-Received: by 10.194.202.230 with SMTP id kl6mr7582617wjc.9.1392404046219; Fri, 14 Feb 2014 10:54:06 -0800 (PST) The occurences of the word "SMTP" in those header fields should tell you something. > >> I've not seen any report of a DDOS attack that used port 25 for a >> traffic-volume-based attack (although intentional or unintentional DDOS >> attacks on mail servers are too common to care about). >> >> Given that I still haven't seen a report that leads me to belive we'll >> ever see a proposal that seriously proposes blocking all UDP traffic on >> the Internet - I continue to disbelieve the premise, so it's not >> surprising that I disagree with the conclusion. >> > That's fine. It is not my goal to block UDP or save WebRTC. I am > just submitting information that i have and connecting the dots that > are in front of me. The future may show that i am too pessimistic or > not enough. > > CB > >> -- >> Surveillance is pervasive. Go Dark. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From nobody Fri Feb 14 14:21: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 E36321A0140; Fri, 14 Feb 2014 14:21:09 -0800 (PST) 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 Gk7sAThubZc0; Fri, 14 Feb 2014 14:21:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC7B1A0166; Fri, 14 Feb 2014 14:21:00 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214222100.19297.41509.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 14:21:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fLVxG4J9yxL8AQWBNrvyZPx_nEo Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-09.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, 14 Feb 2014 22:21:10 -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 Brower-based Applications Author : Harald T. Alvestrand Filename : draft-ietf-rtcweb-overview-09.txt Pages : 21 Date : 2014-02-14 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. The document will be publishd as an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications RTCWEB 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-09 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 Feb 14 15:01: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 0B7391A03A9; Fri, 14 Feb 2014 15:01:33 -0800 (PST) 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 R_UnCQ3C9MbK; Fri, 14 Feb 2014 15:01:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF65A1A029A; Fri, 14 Feb 2014 15:01:30 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214230130.28939.51813.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:01:30 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Pxdemj1qlztlxA7icA3RVuwC_ag Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-09.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, 14 Feb 2014 23:01:33 -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 Security Architecture Author : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-09.txt Pages : 43 Date : 2014-02-14 Abstract: The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for enabling real-time communications within user-agents using web technologies (commonly called "WebRTC"). This document defines the security architecture for WebRTC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-arch-09 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 Feb 14 15:29: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 3D4311A04E5 for ; Fri, 14 Feb 2014 15:29:21 -0800 (PST) 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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSyyyb_HfYBo for ; Fri, 14 Feb 2014 15:29:18 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5B51A04D7 for ; Fri, 14 Feb 2014 15:29:18 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id hu8so10070485vcb.1 for ; Fri, 14 Feb 2014 15:29:16 -0800 (PST) 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; bh=2SyDK4oIokYKUU1Gn4CQaPvbiyHqRHjWHqc5GYnzO2s=; b=KQ1GvpJHaeHZ43uGfG1DWao3hSdAnXvyqk/ZXlIwYPPWh5406tnTGMMY/mcBWHmBe9 3oJ5AYr6TeYOFM7Cf/KFgoJbqNnsIO3Hiy1F4LQZyN/8J32mf6HXo6xo9uxh5nTDTF3X Y/Vl1xJ6eOQaeEbYHFwtjdehpbGc1xl1+E2ki0IKZ2gNrOmRjf1Z0BHichceuKhmf4dw d9XoXD7bzMFMhffh7pN7jwACSrugZUxFYUAL2FpntHk2bWTWQvUnSIH6g/QkFkk2NCrA Kfx+j7mSGga5CbHbLzU7vfLxnGaxIP64Jpn/RLuQpuGzl+baLdQVhdKaWyrZkkol/6lc aA5A== X-Gm-Message-State: ALoCoQmiQdK7eKXx7te6xInbzj/n0q+LvvAvqPshSddrjg9xCwk36ux5b0J5ot19wTQOMZGosM1X X-Received: by 10.221.30.14 with SMTP id sa14mr241667vcb.44.1392420556643; Fri, 14 Feb 2014 15:29:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.198.12 with HTTP; Fri, 14 Feb 2014 15:28:36 -0800 (PST) X-Originating-IP: [50.193.20.145] From: Eric Rescorla Date: Fri, 14 Feb 2014 15:28:36 -0800 Message-ID: To: "rtcweb@ietf.org" , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11336a2ea8356b04f2662cdd Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ftvdqwYN6xRF0b_uLZwAP8YAVeo Subject: [rtcweb] Short Authentication String for TLS/DTLS 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: Fri, 14 Feb 2014 23:29:21 -0000 --001a11336a2ea8356b04f2662cdd Content-Type: text/plain; charset=ISO-8859-1 RTCWEB WG members may be interested in the following draft: http://tools.ietf.org/html/draft-miers-tls-sas-00 This draft specifies a Short Authentication String feature for TLS and DTLS which would allow a pair of communicating to compare SAS values computed from the TLS/DTLS handshake in order to detect active attack. -Ekr --001a11336a2ea8356b04f2662cdd Content-Type: text/html; charset=ISO-8859-1
RTCWEB WG members may be interested in the following draft:


This draft specifies a Short Authentication String feature for
TLS and DTLS which would allow a pair of communicating
to compare SAS values computed from the TLS/DTLS
handshake in order to detect active attack.

-Ekr

--001a11336a2ea8356b04f2662cdd-- From nobody Fri Feb 14 16: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 EE67B1A0390 for ; Fri, 14 Feb 2014 15:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 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.548, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaAU18GGJ0J5 for ; Fri, 14 Feb 2014 15:41:42 -0800 (PST) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id E4D1A1A0360 for ; Fri, 14 Feb 2014 15:41:41 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id oy12so10226821veb.14 for ; Fri, 14 Feb 2014 15:41:40 -0800 (PST) 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=gOLFnVrIz8W0qESzES9vHyqTT3yIcLTnwzobVe4FGzc=; b=CWzE/rI3PfzjQfJLdhkqLoxPu64RU7z5pZUgydIoQsTdqSapjyV3poJiptQXCK7SR5 ZSq9EXS8WDAoWKRQbQnHY8hh0eRSrB5LYaOsMmAURcKQUJDNf/NbDSLPUWvcUAHPakKm i3SySco+OxgfgG+t/LBh8T/5GM0pADSNBoAdYilcTSd9FrX4/RYzzTYIGmidWJZKDBfk ZeN3rBQ5r2oJRX0iixSnCsfAVbAFc/YPD3JnKVkcXxS6M7ptrs6zXRB32y+IJd1MXW9e 2/dtio8VWklLIEbSVxaxj3A/vkoLnbWhw+PMwRHQF4WNdWCHgxE1s1n04iRGm22ZFRp2 T68Q== 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=gOLFnVrIz8W0qESzES9vHyqTT3yIcLTnwzobVe4FGzc=; b=idhH8slPipDaVtWywk2UioideTeVH2+hufzz4uZr6UlXOeoT3EzDhyvGxH/pDuG5Fi t2PGG5gihmdcqzE/qLpwnVov12YpsVhxExVaqFcoMOH6MNt+xV61A3n2zh2JifdkxW36 FZaCgqkGdd2wvvqc0YZI6LPnEchPWoLjr1xGh/2Qd6yjnr/8hfPvqelP4IacqFynyR69 yT9cI4n8ATOwzMMrOwiTkA345wEEJz/Wi5NGyHydhRN3C4zIbuudgQ/gsYYp8otLiTXU pxuVvB06mD5+NqN563hRDgN9HZeuoT8QbLUUjdq4NNW3y477iMOSDxnwUtMGqBIb47fJ J1DQ== X-Gm-Message-State: ALoCoQmFDxIya1R3KIbU/X0pgS4XnQBk3wgETme9Vm+3NPaNVzUSkzHz4chni+iWTiHYc1n3EJxNjVzPWC9ndf1e0hJchjfRxiqBjEzdKRNujp632NqoJ+AQszRCDP0p7+uDJdeEeQtKq0GxIRJe9RBSSQYVVjXPbCPK68gI4IiEPkK3l+xtDdIc9XF4uKAR51GqbQn8cfXY X-Received: by 10.221.37.1 with SMTP id tc1mr3092138vcb.32.1392421300022; Fri, 14 Feb 2014 15:41:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Fri, 14 Feb 2014 15:41:18 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Fri, 14 Feb 2014 18:41:18 -0500 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HMifCyRC9bMT0u-4FXg4nLDepqg X-Mailman-Approved-At: Fri, 14 Feb 2014 16:09:47 -0800 Cc: "rtcweb@ietf.org" , "tls@ietf.org" Subject: Re: [rtcweb] [TLS] Short Authentication String for TLS/DTLS 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: Fri, 14 Feb 2014 23:41:44 -0000 On Fri, Feb 14, 2014 at 6:28 PM, Eric Rescorla wrote: > RTCWEB WG members may be interested in the following draft: > > http://tools.ietf.org/html/draft-miers-tls-sas-00 > > This draft specifies a Short Authentication String feature for > TLS and DTLS which would allow a pair of communicating > to compare SAS values computed from the TLS/DTLS > handshake in order to detect active attack. I think the draft should discuss why a channel binding doesn't work. It's hinted at in the introduction but it's a subtle point because they are otherwise very similar. Given that I see M. Green as an author, should I assume that the requirement for 64 bytes of randomness for a /short/ authentication string is to ensure that users of Dual_EC DRBG have no problems leaking the necessary entropy to a passive observer? :) Cheers AGL From nobody Sat Feb 15 23:22: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 C4E161A0383 for ; Sat, 15 Feb 2014 23:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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, RP_MATCHES_RCVD=-0.548, 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 3oacO5C4kat9 for ; Sat, 15 Feb 2014 23:22:34 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4691A0065 for ; Sat, 15 Feb 2014 23:22:34 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id ik5so10431439vcb.23 for ; Sat, 15 Feb 2014 23:22:32 -0800 (PST) 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=OX/7CbVDHXYNptfMrYqCkAu331knMagQJOc21eMfw8c=; b=H1V501ttgE2uwoI3X5iKeqWsX6NR4ZMB5GxuygHGU/6hJ9J7hs7iOOimyj4cHpJZpt R8sPD3X8IyNPb40q5KUUPm4EMxWByQrimMmQ5G5TpR7uGFLn+nlQRCEasH3Maz8Td3La Faxj5dJsXibFyQO2O9V2DgZoTV9iLSrVL0QkEjkgTac8TDU+ubUYhyV29P2WCFKHXcm3 vS4DyK23637b0FlWAIsi950FKkE6Lya9aUgO2Y2BZbt35yQcXA2Yrf0cOJduEMlQJL4d fCT4IrbCoizqNoAFLI+VvVsVOD9oAQxdqpSoRVxNTE0Yaz42+QRptkclvR4HV3RcQCuq 75aw== 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=OX/7CbVDHXYNptfMrYqCkAu331knMagQJOc21eMfw8c=; b=X5k34fR/IXrvvDIgUUpQedsM5ibJN162zd9bLujAI7aRwIksjp1fhci9zgg9E5v2Cl SLSB8EjaZlDQgp3jf1CjqnhqXFxF4cXQLpuhjulMkInhkn8XcplBu+9siXoVB3hsF7gp haMnvyabovCoJVfwsmpmP/uIypx2Al0LhUOq+q0Gxykpf9X8Z+IPXFMZ3eJsPLF0Vsne Wy1I0qSjh/7lUUZivQQapaxEa1TeZSbSGHtNrN0OTy0TlRe4cpZhzhBREev5IcNqCIvo suVppzn+TXEkiyu3Z80gWbBrIZU755bX4e8um5IZKIQPVhqiPw/5FhbSSpBpubO1bHBN KZXg== X-Gm-Message-State: ALoCoQnVipUh2hUofdy75nnjoD9XcNCqmGr2DzNvklk49TUMBk4Yn051EdRWlPwvKcnTBG0Vfwbx5eZnh5hI8n4hG1UdxoQmImIPhsyouFY9C6VW1wV644jjUZagvauLlg3x3nPwY9ALfWrJCEWUEg2gh01BtgMR+I2UmcBUEMvGRt+BLZa9wHR3IyKZgkH+u9H5VlbMUMyb X-Received: by 10.53.9.107 with SMTP id dr11mr357522vdd.1.1392535352136; Sat, 15 Feb 2014 23:22:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Sat, 15 Feb 2014 23:22:11 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D173112@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D173112@ESESSMB209.ericsson.se> From: Justin Uberti Date: Sat, 15 Feb 2014 23:22:11 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1133e89000813a04f280e7a2 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TO31KiAbCE8bV41I0yuYvubhMfw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - SDP sctpmap attribute 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: Sun, 16 Feb 2014 07:22:37 -0000 --001a1133e89000813a04f280e7a2 Content-Type: text/plain; charset=UTF-8 OK, I think the text may be confusing; I think we mean the same things. The value that should be placed in the SDP is the protocol that identifies "WebRTC Data Channel", not the protocol used in the specific data channel. On Fri, Feb 14, 2014 at 6:26 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Section 5.2.1 says: > > "Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- > passwd", "a=ice-options", "a=candidate", "a=fingerprint", and > "a=setup" lines MUST be included as mentioned above, along with an > "a=sctpmap" line referencing the SCTP port number and specifying > the > application protocol indicated in [I-D.ietf-rtcweb-data-protocol]." > > The statement that the sctpmap attribute specifies the application > protocol indicate in the DCP is not aligned with the sctp-sdp draft. The > sctp-sdp draft specifies that the attribute specifies the application > running on top of the SCTP association - which in this case is the WebRTC > Data Channel. The protocol running on top of that data channel is then > specified in the DCP. > > Regards, > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1133e89000813a04f280e7a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, I think the text may be confusing; I think we mean the= same things. The value that should be placed in the SDP is the protocol th= at identifies "WebRTC Data Channel", not the protocol used in the= specific data channel.


On Fri, Feb 1= 4, 2014 at 6:26 AM, Christer Holmberg <christer.holmberg@eric= sson.com> wrote:
Hi,

Section 5.2.1 says:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Within the data m=3D section, the "a= =3Dmid", "a=3Dice-ufrag", "a=3Dice-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 passwd", "a=3Dice-options", &quo= t;a=3Dcandidate", "a=3Dfingerprint", and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "a=3Dsetup" lines MUST be included as= mentioned above, along with an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "a=3Dsctpmap" line referencing the SC= TP port number and specifying the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 application protocol indicated in [I-D.ietf-rtc= web-data-protocol]."

The statement that the sctpmap attribute specifies the application protocol= indicate in the DCP is not aligned with the sctp-sdp draft. The sctp-sdp d= raft specifies that the attribute specifies the application running on top = of the SCTP association - which in this case is the WebRTC Data Channel. Th= e protocol running on top of that data channel is then specified in the DCP= .

Regards,

Christer

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

--001a1133e89000813a04f280e7a2-- From nobody Sun Feb 16 06:00: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 EEC301A01FA for ; Sun, 16 Feb 2014 06:00:42 -0800 (PST) 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 WfeEgznn1Utb for ; Sun, 16 Feb 2014 06:00:40 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8D31A0110 for ; Sun, 16 Feb 2014 06:00:39 -0800 (PST) Received: (qmail 81177 invoked from network); 16 Feb 2014 14:00:36 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 1833 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 16 Feb 2014 14:00:36 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 5B09918A0C51; Sun, 16 Feb 2014 14:00:35 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 4EEA718A0B54; Sun, 16 Feb 2014 14:00:32 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_01FB7A2E-A5FC-4D07-B37C-41E57F311F9D" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton In-Reply-To: <52FE4851.3000206@bbs.darktech.org> Date: Sun, 16 Feb 2014 14:00:26 +0000 Message-Id: <104BC8B8-77D0-4E2E-BF77-09A2CCB11437@phonefromhere.com> References: <52FDEE06.1030003@jesup.org> <52FE4851.3000206@bbs.darktech.org> To: cowwoc X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RsiZ61wIn1PwdFQAhaf4NVR-128 Cc: "rtcweb@ietf.org >> rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 16 Feb 2014 14:00:43 -0000 --Apple-Mail=_01FB7A2E-A5FC-4D07-B37C-41E57F311F9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 14 Feb 2014, at 16:46, cowwoc wrote: > On 14/02/2014 9:42 AM, Cb B wrote: >> Right. The source port will be a function of the amp server such as = 53, 123, 19... all very common. The destination port is of the spoofers = choosing. >> But, as the us-cert advisory notes, there are several impacted = appilication ports. Well-known webrtc fixed ports would help for a white = list. >>=20 >> Creating a blacklist of just 53, 123, 19 makes us still behind the = curve on whatever is next. >>=20 >=20 > Which is why we will never be able to stop DDoS attacks: > With dumb firewall rules that rely upon port numbers alone. > Unless the destination address is able to communicate back to the = source (or as close as possible to the source) that it does not wish to = continue receiving (any) packets from it, and in so doing pushes the = problem back as far as possible to the source. I don't agree, when we set up an ISP in the '90s we had egress filter = rules that dropped any packets with =46rom address that were not routed as 'inside' our network. At the time we were told to drop that (along with a pile of other = security features which are slowly returning).=20 I see no reason why anyone would peer with an ISP that refused to do = that. (We now return to your #rtcweb program). T. =20 =20 > Gili > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_01FB7A2E-A5FC-4D07-B37C-41E57F311F9D Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 14 Feb 2014, at 16:46, cowwoc <cowwoc@bbs.darktech.org> wrote:

On 14/02/2014 9:42 AM, Cb B wrote:
Right. The source port will be a function of the amp server such as 53, 123, 19... all very common. The destination port is of the spoofers choosing.

But, as the us-cert advisory notes, there are several impacted appilication ports. Well-known webrtc fixed ports would help for a white list.

Creating a blacklist of just 53, 123, 19 makes us still behind the curve on whatever is next.


Which is why we will never be able to stop DDoS attacks:
  1. With dumb firewall rules that rely upon port numbers alone.
  2. Unless the destination address is able to communicate back to the source (or as close as possible to the source) that it does not wish to continue receiving (any) packets from it, and in so doing pushes the problem back as far as possible to the source.


I don't agree, when we set up an ISP in the '90s we had egress filter rules that dropped any packets with From address that were not
routed as 'inside' our network.

At the time we were told to drop that (along with a pile of other security features which are slowly returning). 
I see no reason why anyone would peer with an ISP that refused to do that.

(We now return to your #rtcweb program).

T.
 
 

Gili

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

Tim Panton - Web/VoIP consultant and implementor



--Apple-Mail=_01FB7A2E-A5FC-4D07-B37C-41E57F311F9D-- From nobody Sun Feb 16 06:03: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 C6E121A01FA for ; Sun, 16 Feb 2014 06:03:21 -0800 (PST) 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 6_pWypNgjG7c for ; Sun, 16 Feb 2014 06:03:20 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id E53621A0110 for ; Sun, 16 Feb 2014 06:03:19 -0800 (PST) Received: (qmail 81755 invoked from network); 16 Feb 2014 14:03:17 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 1839 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 16 Feb 2014 14:03:17 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 1088818A0C51; Sun, 16 Feb 2014 14:03:17 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id A0BF818A0B54; Sun, 16 Feb 2014 14:03:13 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton In-Reply-To: <52FD5A4E.8060604@bbs.darktech.org> Date: Sun, 16 Feb 2014 14:03:07 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52FD2FA4.8040701@alvestrand.no> <52FD46F4.7030804@bbs.darktech.org> <52FD4C82.8040300@bbs.darktech.org> <52FD5A4E.8060604@bbs.darktech.org> To: cowwoc X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tv3MHYTnBeqayXpx7xA6ZZZhPxg Cc: "rtcweb@ietf.org >> rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 16 Feb 2014 14:03:22 -0000 On 13 Feb 2014, at 23:50, cowwoc wrote: > On 13/02/2014 6:00 PM, Dave Taht wrote: >> On Thu, Feb 13, 2014 at 5:51 PM, cowwoc = wrote: >>> On 13/02/2014 5:46 PM, Dave Taht wrote: >>>> The biggest downside, as I see it, is targeting advancements in the = state >>>> of >>>> the art, at windows. 98% of the world or so run non-windows based = cell >>>> phones and tablets, and in terms of total users, probably outnumber >>>> the windows contingent at this point. >>>>=20 >>>> SCTP and MPTCP are quite feasible on android and IOS. >>>=20 >>> It doesn't matter how many smartphones there are. What matters is = how many >>> of them will be used to do meaningful video chat. The screen real = estate on >>> these devices is way too small. >> In my experience, everybody is using tablets and handheld devices for >> video chat. >> It is a natural extension of the usage of the device to extend it = from >> phone calls >> to video calls. >>=20 >> The lack of a working camera on most desktops is a hindrance, and the = placement >> of cameras on most laptops is not ideal. >=20 > All laptops and tablets come with decent cameras. I will agree that = WebRTC on tablets will be strong, but smartphones is really pushing it. = Most of the time I've seen people engage in video chat it was between = family members; far less for business use. And in those cases, I've seen = people jump on tablets and laptops instead of having to deal with a = tiny, underpowered smartphone for video. These are just personal = observations, not science, so please take them with a grain of salt. >=20 > Gili Again, I disagree, I often use a smartphone for video, but only if I can = airplay/chromecast the video to a suitable TV. T. Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk From nobody Sun Feb 16 06:57: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 CC3151A03EE for ; Sun, 16 Feb 2014 06:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 Mi2Xd8DjAPw4 for ; Sun, 16 Feb 2014 06:57:30 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D14271A03EC for ; Sun, 16 Feb 2014 06:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2434; q=dns/txt; s=iport; t=1392562648; x=1393772248; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FOe+6WjFQ8d+HpOZbhQpCBMSyMsHDghjCs7KsQROGpE=; b=crsQd7c92QxEhBWPbJVlgn6suhBFs+gdy3C9bg9rVf1x5JFgJGnLKuxe 8AL47h4GGal6YnqPuCHUv5sCB7awZLN3GrBZwlRz+mH0gQcIS+tGyf2Jc 5gx9RqKq9H3UuPMJn9N42qql3rrEkAhEorvLKW+DbB1UzoY/wjaVoNEWW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABzRAFOtJV2d/2dsb2JhbABZgwg4vHRPgRAWAXSDfQEBAQMBAQEBNw8lCwULAgEIGB4QJwslAgQOBYd8CA3BSheOXzMHhDYEmBaSFIMr X-IronPort-AV: E=Sophos;i="4.95,855,1384300800"; d="scan'208";a="301395319" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 16 Feb 2014 14:57:27 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1GEvRj3029081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Feb 2014 14:57:27 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.15]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Sun, 16 Feb 2014 08:57:27 -0600 From: "Jeremy Laurenson (jlaurens)" To: Tim Panton Thread-Topic: [rtcweb] UDP transport problem Thread-Index: AQHPKx/ReTPUYSIEFUimiJt3/lhYxJq3+JDm Date: Sun, 16 Feb 2014 14:57:26 +0000 Message-ID: <93FE15F7-DE61-41C6-845E-949188098013@cisco.com> References: <52FD2FA4.8040701@alvestrand.no> <52FD46F4.7030804@bbs.darktech.org> <52FD4C82.8040300@bbs.darktech.org> <52FD5A4E.8060604@bbs.darktech.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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/RHD_xHbpG5HZXtqbAkovdOX4RRk Cc: "rtcweb@ietf.org >> rtcweb@ietf.org" Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 16 Feb 2014 14:57:32 -0000 Why would we assume anything about the devices this stuff will run on in th= e future? Technology change tells me we'll all be wrong and underestimate w= hat's next. Assume WebRTC on everything, including my smarty ring. :-) Jeremy > On Feb 16, 2014, at 9:03 AM, "Tim Panton" wrote: >=20 >=20 >> On 13 Feb 2014, at 23:50, cowwoc wrote: >>=20 >>> On 13/02/2014 6:00 PM, Dave Taht wrote: >>>> On Thu, Feb 13, 2014 at 5:51 PM, cowwoc wrot= e: >>>>> On 13/02/2014 5:46 PM, Dave Taht wrote: >>>>> The biggest downside, as I see it, is targeting advancements in the s= tate >>>>> of >>>>> the art, at windows. 98% of the world or so run non-windows based cel= l >>>>> phones and tablets, and in terms of total users, probably outnumber >>>>> the windows contingent at this point. >>>>>=20 >>>>> SCTP and MPTCP are quite feasible on android and IOS. >>>>=20 >>>> It doesn't matter how many smartphones there are. What matters is how = many >>>> of them will be used to do meaningful video chat. The screen real esta= te on >>>> these devices is way too small. >>> In my experience, everybody is using tablets and handheld devices for >>> video chat. >>> It is a natural extension of the usage of the device to extend it from >>> phone calls >>> to video calls. >>>=20 >>> The lack of a working camera on most desktops is a hindrance, and the p= lacement >>> of cameras on most laptops is not ideal. >>=20 >> All laptops and tablets come with decent cameras. I will agree that WebR= TC on tablets will be strong, but smartphones is really pushing it. Most of= the time I've seen people engage in video chat it was between family membe= rs; far less for business use. And in those cases, I've seen people jump on= tablets and laptops instead of having to deal with a tiny, underpowered sm= artphone for video. These are just personal observations, not science, so p= lease take them with a grain of salt. >>=20 >> Gili >=20 > Again, I disagree, I often use a smartphone for video, but only if I can = airplay/chromecast the video to a suitable TV. >=20 >=20 > T. >=20 >=20 > Tim Panton - Web/VoIP consultant and implementor > www.westhawk.co.uk >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Feb 16 12: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 1E5971A0277 for ; Sun, 16 Feb 2014 12:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 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_NEUTRAL=0.779] 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 WeUwtE6YC5pt for ; Sun, 16 Feb 2014 12:29:39 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB9A1A0068 for ; Sun, 16 Feb 2014 12:29:39 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id x12so1712746wgg.20 for ; Sun, 16 Feb 2014 12:29:36 -0800 (PST) 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=O6Wkrveaknoa9zzwPrlGJqeJE1E+ptHjZorExjn7UZE=; b=QAuKo0QARQ8+q+X8VHduuXbznx3VHTUslenPb6IvM68QSf8A7DXq/T9Go/QZQ6cdhU tbwmGDxiMGbC/bSItfjVmUqBrnnUeNWREj94Xd+8Iki8zNgMMeAyQechpO7XYp5kdWzo wXa3SoPimJ8lLYKQ5tJoBbMHfjoiYijQ+LQFOZNSJQLuSdeJm+nkTcpb9cUZpdmo0I6g E5tFoYJt+RakXdcFqyHmT8MSeofwTqT8cmZmgjN4oqB54B6FHNnvgsUpCqiC1YLgMvyz NJ4AUU5hip7nRtGL2aXPE219M/tTYx02RE+eHT0pLym3T8VEEjzjRGyNl9C6GOpE8b8i O8HA== X-Gm-Message-State: ALoCoQkEcPm7XL+sTfU36X2T+ntHdFMA5Y1UKCts4Vj/iZt1ZvEauim++i9av6mmzH+wkBslKjFn MIME-Version: 1.0 X-Received: by 10.194.2.70 with SMTP id 6mr14316111wjs.25.1392582576333; Sun, 16 Feb 2014 12:29:36 -0800 (PST) Received: by 10.217.68.138 with HTTP; Sun, 16 Feb 2014 12:29:36 -0800 (PST) Received: by 10.217.68.138 with HTTP; Sun, 16 Feb 2014 12:29:36 -0800 (PST) Date: Sun, 16 Feb 2014 12:29:36 -0800 Message-ID: From: "Cynthia G. Anderson" To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=047d7b3a8174c8733704f28be566 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6_8RmO7BGnM-eEZKOezZhZd0I98 Subject: Re: [rtcweb] UDP transport problem X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 16 Feb 2014 20:29:43 -0000 --047d7b3a8174c8733704f28be566 Content-Type: text/plain; charset=ISO-8859-1 Forgive me for adding in my own two cents, as I only recently joined the list ( as digest even), and am still reading like mad and trying to come up to speed on this huge, complex area.... But I do know something about UX and people behavior, so I must say I agree with Jeremy, you can't really assume that people won't do something. It is more typical for people to use any communication device in any possible way...even if it isn't ideal for the communication. Other factors often are more important, like being in a situation where a preferred device isn't available (examples. A car. A remote location. No wifi or connections. Not wanting to carry a larger device.) And beyond that, new tech emerges constantly, some fail, some fail but come back later ( like tablets, wearables, etc) and some devices get new looks and UX such that they suddenly catch on....ipod to iphone to ipad...and such pervasive popularity moves them from gadget to personal only to business use...which has happened with phones, the iphone inspired UX, and tablets....Linux was another success that also accelerated into wide acceptance when it became, not just more reliable, but also more *general* user friendly....it made it easier for techies to convince non-tech finance types to buy in.... So my 2cents, uninformed in many other ways, is to recommend assuming the widest possible usage and scale, if possible. I'll go back to lurking now.... ;) CG > > ---------- Forwarded message ---------- > From: "Jeremy Laurenson (jlaurens)" > To: Tim Panton > Cc: "rtcweb@ietf.org >> rtcweb@ietf.org" > Date: Sun, 16 Feb 2014 14:57:26 +0000 > Subject: Re: [rtcweb] UDP transport problem > Why would we assume anything about the devices this stuff will run on in the future? Technology change tells me we'll all be wrong and underestimate what's next. Assume WebRTC on everything, including my smarty ring. :-) > > Jeremy > > > On Feb 16, 2014, at 9:03 AM, "Tim Panton" wrote: > > > > > >> On 13 Feb 2014, at 23:50, cowwoc wrote: > >> > >>> On 13/02/2014 6:00 PM, Dave Taht wrote: > >>>> On Thu, Feb 13, 2014 at 5:51 PM, cowwoc wrote: > >>>>> On 13/02/2014 5:46 PM, Dave Taht wrote: > >>>>> The biggest downside, as I see it, is targeting advancements in the state > >>>>> of > >>>>> the art, at windows. 98% of the world or so run non-windows based cell > >>>>> phones and tablets, and in terms of total users, probably outnumber > >>>>> the windows contingent at this point. > >>>>> > >>>>> SCTP and MPTCP are quite feasible on android and IOS. > >>>> > >>>> It doesn't matter how many smartphones there are. What matters is how many > >>>> of them will be used to do meaningful video chat. The screen real estate on > >>>> these devices is way too small. > >>> In my experience, everybody is using tablets and handheld devices for > >>> video chat. > >>> It is a natural extension of the usage of the device to extend it from > >>> phone calls > >>> to video calls. > >>> > >>> The lack of a working camera on most desktops is a hindrance, and the placement > >>> of cameras on most laptops is not ideal. > >> > >> All laptops and tablets come with decent cameras. I will agree that WebRTC on tablets will be strong, but smartphones is really pushing it. Most of the time I've seen people engage in video chat it was between family members; far less for business use. And in those cases, I've seen people jump on tablets and laptops instead of having to deal with a tiny, underpowered smartphone for video. These are just personal observations, not science, so please take them with a grain of salt. > >> > >> Gili > > > > Again, I disagree, I often use a smartphone for video, but only if I can airplay/chromecast the video to a suitable TV. > > > > > > T. > > > > > > Tim Panton - Web/VoIP consultant and implementor > > www.westhawk.co.uk > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b3a8174c8733704f28be566 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


Forgive me for adding in my own two cents, as I only recently joined the li= st ( as digest even), and am still reading like mad and trying to come up t= o speed on this huge, complex area....

But I do know something about UX and people behavior, so I must say I ag= ree with Jeremy, you can't really assume that people won't do somet= hing.=A0 It is more typical for people to use any communication device in a= ny possible way...even if it isn't ideal for the communication.=A0 Othe= r factors often are more important, like being in a situation where a prefe= rred device isn't available (examples. A car.=A0 A remote location. No = wifi or connections. Not wanting to carry a larger device.)

And beyond that, new tech emerges constantly, some fail, some fail but c= ome back later ( like tablets, wearables, etc) and some devices get new loo= ks and UX such that they suddenly catch on....ipod to iphone to ipad...and = such pervasive popularity moves them from gadget to personal only to busine= ss use...which has happened with phones, the iphone inspired UX, and tablet= s....Linux was another success that also accelerated into wide acceptance w= hen it became, not just more reliable, but also more *general* user friendl= y....it made it easier for techies to convince non-tech finance types to bu= y in....

So my 2cents, uninformed in many other ways, is to recommend assuming th= e widest possible usage and scale, if possible.

I'll go back to lurking now.... ;)
CG

>
> ---------- Forwarded message ----------
> From:=A0"Jeremy Laurenson (jlaurens)" <jlaurens@cisco.com>
> To:=A0Tim Panton <tim@phon= efromhere.com>
> Cc:=A0"rtcweb@ietf.org >= ;> rtcweb@ietf.org" <rtcweb@ietf.org>
> Date:=A0Sun, 16 Feb 2014 14:57:26 +0000
> Subject:=A0Re: [rtcweb] UDP transport problem
> Why would we assume anything about the devices this stuff will run on = in the future? Technology change tells me we'll all be wrong and undere= stimate what's next. Assume WebRTC on everything, including my smarty r= ing. :-)
>
> Jeremy
>
> > On Feb 16, 2014, at 9:03 AM, "Tim Panton" <tim@phonefromhere.com> wrote:
> >
> >
> >> On 13 Feb 2014, at 23:50, cowwoc <cowwoc@bbs.darktech.org> wrote:
> >>
> >>> On 13/02/2014 6:00 PM, Dave Taht wrote:
> >>>> On Thu, Feb 13, 2014 at 5:51 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:<= br> > >>>>> On 13/02/2014 5:46 PM, Dave Taht wrote:
> >>>>> The biggest downside, as I see it, is targeting a= dvancements in the state
> >>>>> of
> >>>>> the art, at windows. 98% of the world or so run n= on-windows based cell
> >>>>> phones and tablets, and in terms of total users, = probably outnumber
> >>>>> the windows contingent at this point.
> >>>>>
> >>>>> SCTP and MPTCP are quite feasible on android and = IOS.
> >>>>
> >>>> It doesn't matter how many smartphones there are.= What matters is how many
> >>>> of them will be used to do meaningful video chat. The= screen real estate on
> >>>> these devices is way too small.
> >>> In my experience, everybody is using tablets and handheld= devices for
> >>> video chat.
> >>> It is a natural extension of the usage of the device to e= xtend it from
> >>> phone calls
> >>> to video calls.
> >>>
> >>> The lack of a working camera on most desktops is a hindra= nce, and the placement
> >>> of cameras on most laptops is not ideal.
> >>
> >> All laptops and tablets come with decent cameras. I will agre= e that WebRTC on tablets will be strong, but smartphones is really pushing = it. Most of the time I've seen people engage in video chat it was betwe= en family members; far less for business use. And in those cases, I've = seen people jump on tablets and laptops instead of having to deal with a ti= ny, underpowered smartphone for video. These are just personal observations= , not science, so please take them with a grain of salt.
> >>
> >> Gili
> >
> > Again, I disagree, I often use a smartphone for video, but only i= f I can airplay/chromecast the video to a suitable TV.
> >
> >
> > T.
> >
> >
> > Tim Panton - Web/VoIP consultant and implementor
> > www.westhawk.co.uk
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://= www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb
>

--047d7b3a8174c8733704f28be566-- From nobody Sun Feb 16 23:45: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 5C2A71A004C for ; Sun, 16 Feb 2014 23:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 iZ3u3Mta4B8U for ; Sun, 16 Feb 2014 23:45:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD631A0041 for ; Sun, 16 Feb 2014 23:45:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBE97354; Mon, 17 Feb 2014 07:45:34 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 07:45:25 +0000 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 07:45:29 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 15:45:24 +0800 From: "Lijing (Jessie)" To: "rtcweb@ietf.org" , "randell-ietf@jesup.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt Thread-Index: AQHPJy/M30Ze8LwI8UO/i8Fhdvp2Hpq5FWhQ Date: Mon, 17 Feb 2014 07:45:22 +0000 Message-ID: References: <20140211134715.20073.62978.idtracker@ietfa.amsl.com> In-Reply-To: <20140211134715.20073.62978.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.171.171] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BG_JOZzlgrf1DS5x00Fn6DMy5Jw Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 17 Feb 2014 07:45:40 -0000 Hi, One question about the implementation of data channel. Section 4 says: Req. 4: The application SHOULD be able to provide guidance as to the relative priority of each data channel relative to each other, and relative to the media streams. This will interact with the congestion control algorithms. It seems that for now there is no W3C API parameters to set the priority of= data channel. I wonder if the priority of the data channel isn't open to t= he application and is decided by the browser.=20 So I want to know how the application be able to provide guidance as to the= priority. Best Regards, Jessie From nobody Mon Feb 17 01:41: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 4BC331A042C for ; Mon, 17 Feb 2014 01:41:08 -0800 (PST) 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_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 j4j7GNsHm7I0 for ; Mon, 17 Feb 2014 01:41:06 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9A01A0392 for ; Mon, 17 Feb 2014 01:41:05 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-e5-5301d92e7f16 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 1A.31.04249.E29D1035; Mon, 17 Feb 2014 10:41:02 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.2.347.0; Mon, 17 Feb 2014 10:41:02 +0100 Message-ID: <5301D92E.40800@ericsson.com> Date: Mon, 17 Feb 2014 10:41:02 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMJMWRmVeSWpSXmKPExsUyM+Jvja7eTcZgg50rzCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRuO7v0wFM7gqVv1tZmpgXM3RxcjJISFgItH49TcrhC0mceHe erYuRi4OIYEjjBLdDbOgnOWMEj8a5rGDVPEKaErcvLAWzGYRUJX4P/sWM4jNJmAhcfNHIxuI LSoQLLHzwG9GiHpBiZMzn7CA2CIC6hKXH14A6xUWkJa4/nk9UC8H0GZxiZ7GIJAws4CexJSr LYwQtrxE89bZYOOFBLQlGpo6WCcw8s9CMnUWkpZZSFoWMDKvYuQoTi1Oyk03MtjECAyog1t+ W+xgvPzX5hCjNAeLkjjvx7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYT3Mt+ZhXzps5 3zDMa+X54AgPc4/u32m5HApvXmeHrs6Km2Ywa+pdm7b/XTrx2S27k9KkTx9oFy3+37OB0eGI vwavQ7s+U08PN5uwiwb/PrGsT6eeLdF6ujWzJN1ofUuu22zh/Hn8u29PC1la6vV1zd1TK0p4 q9//XufyrdLS+IRMuJAUA78SS3FGoqEWc1FxIgCJ7+kt9gEAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2qJpEyymFujKYSdsl8TO9wSFmwU Subject: [rtcweb] It is review time! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 17 Feb 2014 09:41:08 -0000 WG, In two weeks we will meet in London. I hope everyone prepares well by reviewing the new drafts. As you might have seen on: https://datatracker.ietf.org/wg/rtcweb/ Most of the WG documents where updated the last week. We are going to discuss many of them in the WG session. See draft agenda: http://www.ietf.org/mail-archive/web/rtcweb/current/msg11431.html That discussion will be much more productive if YOU have read the latest version. You can also greatly help the WG and the Authors by sending your review comments to mailing list. That way we can ensure that we discuss the most relevant open issues. It will also will greatly help improving the documents. So PLEASE post your reviews! We will not meet our goals of finishing all our core documents this year without your help! Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Feb 17 02:01: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 EBA431A03C9 for ; Mon, 17 Feb 2014 02:01:52 -0800 (PST) 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_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 OWYa7Ki8FpkG for ; Mon, 17 Feb 2014 02:01:50 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id EAFC11A03C5 for ; Mon, 17 Feb 2014 02:01:49 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-76-5301de0a4678 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 5B.F4.04249.A0ED1035; Mon, 17 Feb 2014 11:01:46 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.347.0; Mon, 17 Feb 2014 11:01:46 +0100 Message-ID: <5301DE0A.4010005@ericsson.com> Date: Mon, 17 Feb 2014 11:01:46 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: References: <20140214195131.12199.3422.idtracker@ietfa.amsl.com> In-Reply-To: <20140214195131.12199.3422.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyM+JvjS7XPcZgg/3bbCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvUV/9gL/spU/Oz/ydTA+EWsi5GTQ0LARGLukiNMELaYxIV7 69m6GLk4hASOMEocOTyfEcJZzigxYek9sCpeAW2JrW97mEFsFgFViVUdM8DibAIWEjd/NLKB 2KICwRI7D/xmhKgXlDg58wkLiC0iICrx+vE0VhBbWMBFYv+SWWC9QgIOErNu3mAHsTkFHCVa b74GqucAukhcoqcxCCTMLKAnMeVqCyOELS/RvHU2M0SrtkRDUwfrBEbBWUi2zULSMgtJywJG 5lWMHMWpxUm56UYGmxiBAXhwy2+LHYyX/9ocYpTmYFES5/341jlISCA9sSQ1OzW1ILUovqg0 J7X4ECMTB6dUA+M5zcgrLQuOZR84UuX3anmaxfENx0+ecGEO/3XrcfUijz6OhY8K+F0slZ8Y 6Ljt4FJKa1mgs6NyetDk9MsHO6onTVm4/oP1lq1cyQx3mUVOffB/cXxZoUFeGmPCJsfy2M0F L4tes9byhE7sW3xZsfd427pDlqXPjN5sdJ52P/tWkcKH2OP1Lw2UWIozEg21mIuKEwGuv7L3 DgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nv1RRMNPx4ac0vbf0MfMXgrx5oA Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-12.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, 17 Feb 2014 10:01:53 -0000 WG, This version is the authors attempt to make a version ready for WG last call. We list below the changes that we consider significant beyond editorial improvements. - Further clarified that draft-ietf-rtcweb-security-arch defines the crypto suits and key-management solution for the SAVPF profile. - Removed the discussion of the SHIM based approach (draft-westerlund- avtcore-transport-multiplexing) - Changed SLI and RPSI to RECOMMENDED to implement level based on WG mailing list discussion. - Clarified that the RTP packet stream association with MediaStramStracks is the one that MSID provides. - Removed Simulcast as open issue. We have removed the discussion of explicitly signaled simulcast and clarified the one that can be done using multiple mediaStreamTracks based on the same media source. These can be included in the same or different PeerConnections with different parameters for basic simulcast support. I still expect that when simulcast in RTP and SDP has been specified that adoption of that is considered for WebRTC. - Added an WebRTC API requirement regarding CSRC list handling. I recommend that people review these changes and provide feedback. The authors will continue to strive for a WG last call directly after WG meeting in London. Cheers Magnus On 2014-02-14 20:51, 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. > > 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-12.txt > Pages : 41 > Date : 2014-02-14 > > 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-12 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-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/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Feb 17 03:30: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 303761A03D3 for ; Mon, 17 Feb 2014 03:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 Z2tAyz0Pa9hl for ; Mon, 17 Feb 2014 03:30:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 000AD1A0125 for ; Mon, 17 Feb 2014 03:30:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDR06528; Mon, 17 Feb 2014 11:30:28 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 11:30:14 +0000 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 11:30:19 +0000 Received: from SZXEMA503-MBX.china.huawei.com ([169.254.5.104]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 19:30:08 +0800 From: "Liuyan (Scarlett)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt - the data channel's state and the SCTP association Thread-Index: AQHPK9Oc/rbk1aaTTk+rVISc1Uc90g== Date: Mon, 17 Feb 2014 11:30:08 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1730E7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1730E7@ESESSMB209.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.137.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EacSR8ovoF-YZMevCiugx8OYMrs Subject: [rtcweb] I-D Action: draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt - the data channel's state and the SCTP association X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 17 Feb 2014 11:30:33 -0000 Hi, Section 5.5.2 does say: "o As described in Section 4.2.2, if the SCTP association is not yet established, then the newly created data channels are in the Connecting state, else if the SCTP association is already established, then the newly created data channels are in the Open state." ..... It is not clear that if the SCTP association is failed to establish, how = to we deal with the newly created data channels. Furthermore, how long the valid duration of the connecting state of the n= ewly created data channels are before the SCTP association has not yet esta= blished ?=20 Section 5.5.3 does say: "5.2.3. Closing a data channel When the application requests the closing of a data channel that was externally negotiated, the browser always performs an in-band SSN reset for this channel. It is specific to the sub-protocol whether this closing must in addition be signaled to the peer via a new SDP offer/answer exchange. The application must also close any data channel that was externally negotiated, for which the stream identifiers are not listed in an incoming SDP offer." ... When there are multiple data channels with different sub-protocol per a = SCTP association,=20 Maybe it needs to identify how to close a single data channel, how to close= all data channels with the same sub-protocol and how to close a SCTP assoc= iation. Of course, closing a SCTP association can just set SCTP port number zero.:-= ) =20 Regards, Scarlett _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Feb 18 00:59: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 E76F51A0058 for ; Tue, 18 Feb 2014 00:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.76 X-Spam-Level: *** X-Spam-Status: No, score=3.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 CpRBoMZKJwVQ for ; Tue, 18 Feb 2014 00:59:40 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 11AA61A00A6 for ; Tue, 18 Feb 2014 00:59:39 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-c5-530320f86818 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id A4.70.04853.8F023035; Tue, 18 Feb 2014 09:59:36 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.2.347.0; Tue, 18 Feb 2014 09:59:35 +0100 Message-ID: <530320F7.4090300@ericsson.com> Date: Tue, 18 Feb 2014 09:59:35 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMJMWRmVeSWpSXmKPExsUyM+Jvje4PBeZgg80bJCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtdJNxgL5oVUzPlQ38D4w6GLkZNDQsBEovnHexYIW0ziwr31 bF2MXBxCAicYJdb+P8QK4SxnlLi/qJkdpIpXQFviyfpGZhCbRUBV4symTkYQm03AQuLmj0Y2 EFtUIFhi54HfjBD1ghInZz4B2yAioC5x+eEFsDnCAkkSy9e2AdVwAG0Wl+hpDAIJMwvoSUy5 2sIIYctLNG+dDbZKCGhtQ1MH6wRG/llIps5C0jILScsCRuZVjJLFqcXFuelGBnq56bkleqlF mcnFxfl5esWpmxiBAXdwy2+jHYwn99gfYpTmYFES573OWhMkJJCeWJKanZpakFoUX1Sak1p8 iJGJg1OqgTHHaXN4s15k2Iui5IPvCjW812cdMTPO9Xz7/Un9VMk90jIl57ckl+lOUDSKO7DA Va35/0e5aw6OmzZof55ldurdLQFTL2av3Ev3HR7vv7P8LMf/3DexNw9W9xoy7Njy11VeiD2A KcNgxa2/Fmu3Sz5e38tcIv1PWy/+DPMV5VXHk7LLTvNHnFBiKc5INNRiLipOBAAvrAmRBgIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/31j3JovsKWrXtdvXjBNmMKdesmg Subject: [rtcweb] Number of samples (ptime) to be supported by required codecs (draft-ietf-rtcweb-audio-05) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 18 Feb 2014 08:59:43 -0000 Hi, (as individual) I just reviewed the -05 of the audio draft and realized that it removed all discussion of what packetization times are expected to be supported by an implementation. For opus this is not that difficult as the range is limited to multiples of the audio frames it can produce. The current edit I think comes from Jean-Marc and Cullen's private discussion who's outcome was communicated to the list on the 2014-01-31. The main part of the message reads: > We keep the part about what happens with RTP in > draft-ietf-rtcweb-audio but move the parts about SDP off to JSEP. I > think that means all we need here is basically MUST implement G.711 & > Opus along with their RTP payload formats. > > The ranges of size of packets, frames and other things seem to be > adequately covered by the specs for the codecs and WebRTC is not > chaining theses codecs so seems good enough. The JSEP draft that is > pointing at all the parts of SDP that need to be supported can deal > with the ptime and maxptime in SDP. I didn't get to comment this immediately as I went on vacation. But here is my follow up on this thread. If you don't want to read what the existing specs says and background motivations, jump to the end and read from "Trying to conclude:" First of all lets investigate what the two specs says about packetization time. Opus: http://tools.ietf.org/id/draft-ietf-payload-rtp-opus-01.txt 4.2. Payload Structure The Opus encoder can be set to output encoded frames representing 2.5, 5, 10, 20, 40, or 60 ms of speech or audio data. Further, an arbitrary number of frames can be combined into a packet. The maximum packet length is limited to the amount of encoded data representing 120 ms of speech or audio data. Section 6.1 maxptime: the decoder's maximum length of time in milliseconds rounded up to the next full integer value represented by the media in a packet that can be encapsulated in a received packet according to Section 6 of [RFC4566]. Possible values are 3, 5, 10, 20, 40, and 60 or an arbitrary multiple of Opus frame sizes rounded up to the next full integer value up to a maximum value of 120 as defined in Section 4. If no value is specified, 120 is assumed as default. This value is a recommendation by the decoding side to ensure the best performance for the decoder. The decoder MUST be capable of accepting any allowed packet sizes to ensure maximum compatibility. ptime: the decoder's recommended length of time in milliseconds rounded up to the next full integer value represented by the media in a packet according to Section 6 of [RFC4566]. Possible values are 3, 5, 10, 20, 40, or 60 or an arbitrary multiple of Opus frame sizes rounded up to the next full integer value up to a maximum value of 120 as defined in Section 4. If no value is specified, 20 is assumed as default. If ptime is greater than maxptime, ptime MUST be ignored. This parameter MAY be changed during a session. This value is a recommendation by the decoding side to ensure the best performance for the decoder. The decoder MUST be capable of accepting any allowed packet sizes to ensure maximum compatibility. minptime: the decoder's minimum length of time in milliseconds rounded up to the next full integer value represented by the media in a packet that SHOULD be encapsulated in a received packet according to Section 6 of [RFC4566]. Possible values are 3, 5, 10, 20, 40, and 60 or an arbitrary multiple of Opus frame sizes rounded up to the next full integer value up to a maximum value of 120 as defined in Section 4. If no value is specified, 3 is assumed as default. This value is a recommendation by the decoding side to ensure the best performance for the decoder. The decoder MUST be capable to accept any allowed packet sizes to ensure maximum compatibility. Thus, I agree for Opus this is well-defined. An receiver MUST support any combination of frames that the encoder can produce up to a total of 120 ms. And it has well defined usage of ptime and maxptime and also defines a min ptime. Lets then look at G.711: This is the whole PCMA and PCMU payload format definition in RFC3551: 4.5.14 PCMA and PCMU PCMA and PCMU are specified in ITU-T Recommendation G.711. Audio data is encoded as eight bits per sample, after logarithmic scaling. PCMU denotes mu-law scaling, PCMA A-law scaling. A detailed description is given by Jayant and Noll [15]. Each G.711 octet SHALL be octet-aligned in an RTP packet. The sign bit of each G.711 octet SHALL correspond to the most significant bit of the octet in the RTP packet (i.e., assuming the G.711 samples are handled as octets on the host machine, the sign bit SHALL be the most significant bit of the octet as defined by the host machine format). The 56 kb/s and 48 kb/s modes of G.711 are not applicable to RTP, since PCMA and PCMU MUST always be transmitted as 8-bit samples. See Section 4.1 regarding silence suppression. This doesn't say anything about the packetization. Fortunately Section 4.2 of RFC 3551 do talk about this, and as the RTP/SAVPF profile used by WebRTC derives from RTP/AVP (RFC3551) this do apply. 4.2 Operating Recommendations The following recommendations are default operating parameters. Applications SHOULD be prepared to handle other values. The ranges given are meant to give guidance to application writers, allowing a set of applications conforming to these guidelines to interoperate without additional negotiation. These guidelines are not intended to restrict operating parameters for applications that can negotiate a set of interoperable parameters, e.g., through a conference control protocol. For packetized audio, the default packetization interval SHOULD have a duration of 20 ms or one frame, whichever is longer, unless otherwise noted in Table 1 (column "ms/packet"). The packetization interval determines the minimum end-to-end delay; longer packets introduce less header overhead but higher delay and make packet loss more noticeable. For non-interactive applications such as lectures or for links with severe bandwidth constraints, a higher packetization delay MAY be used. A receiver SHOULD accept packets representing between 0 and 200 ms of audio data. (For framed audio encodings, a receiver SHOULD accept packets with a number of frames equal to 200 ms divided by the frame duration, rounded up.) This restriction allows reasonable buffer sizing for the receiver. As can see this recommends that one per default support 20 ms, and that receivers are capable of handling up to 200 ms. So, for PCMA and PCMU the picture are less clear, there are recommendations, but no hard requirements. Also they are sample based codecs and thus can produce payloads of any length (bytes and samples). When it comes the signalling, we do have ptime and maxptime defined in the base-spec of SDP [RFC4566] a=ptime: This gives the length of time in milliseconds represented by the media in a packet. This is probably only meaningful for audio data, but may be used with other media types if it makes sense. It should not be necessary to know ptime to decode RTP or vat audio, and it is intended as a recommendation for the encoding/packetisation of audio. It is a media-level attribute, and it is not dependent on charset. a=maxptime: This gives the maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the packet represents. For frame-based codecs, the time SHOULD be an integer multiple of the frame size. This attribute is probably only meaningful for audio data, but may be used with other media types if it makes sense. It is a media-level attribute, and it is not dependent on charset. Note that this attribute was introduced after RFC 2327, and non-updated implementations will ignore this attribute. Thus, these can be used to provide a single recommended packetization interval and an upper limit if supported. The fact that ptime only can indicate a single rate becomes a potential issue as you can't determine a remote peer preferences for other rates, if an WebRTC endpoint likes to modify its rate due to congestion control reasons. Changing the packetization rate is one of the tools that give a most significant bit-rate change for audio, and it can even be applied without changing the encoding rate, something crucial for doing any bit-rate adaptation for G.711. For your notes, JSEP does currently do not discuss packetization times or the ptime or maxptime SDP parameter at all. Trying to conclude: I see an issue that we don't provide firmer requirements on what packetization intervals that should be supported by a WebRTC receiver. I would propose that we actually write into the audio draft in general that a WebRTC endpoint SHALL support receiving audio RTP payloads that contain up to 200 ms of audio if the RTP payload format supports it. When it comes to sending I would also like to provide some minimal requirements, these may need to be on codec basis, and I think it is G.711 that is lacking here. Thus, I think an WebRTC endpoint SHALL be capable of producing packetization times in the RTP payloads with the following amount of time: 10, 20, 40, 60 ms. I also think we should formalize the requirement to support the ptime and maxptime signalling to maximize the possibility for interop with any legacy systems. I do see a need for the audio draft to discuss the potential issues here that can affect interoperability. Cheers Magnus Westerlund (As individual) ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Feb 18 02:06: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 7C6CD1A0471 for ; Tue, 18 Feb 2014 02:06:20 -0800 (PST) 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 mgECw8_PDSVL for ; Tue, 18 Feb 2014 02:06:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A3C1A0652 for ; Tue, 18 Feb 2014 02:06:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140218100616.20178.25684.idtracker@ietfa.amsl.com> Date: Tue, 18 Feb 2014 02:06:16 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0QfY16wudh7iwU0pqLW8sOiCyWk Subject: [rtcweb] Milestones changed for rtcweb WG 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, 18 Feb 2014 10:06:20 -0000 Changed milestone "Send Use Cases document (draft-ietf-rtcweb-use-cases-and- requirements) to IESG for publication as Informational", set due date to February 2014 from October 2012. Changed milestone "Complete Overview (and hold for dependency resolution) (draft-ietf-rtcweb-overview)", set due date to February 2014 from October 2012. Changed milestone "Send Security and Privacy Problem Statement (draft-ietf- rtcweb-security) to IESG for publication as Informational", set due date to March 2014 from October 2012. Changed milestone "Send Media Transport (draft-ietf-rtcweb-rtp-usage) to IESG for publication as Proposed Standard", set due date to April 2014 from January 2013. Changed milestone "Audio Processing and Audio Codecs (draft-ietf-rtcweb-audio) to IESG for publication as Proposed Standard", set due date to April 2014 from January 2013. Changed milestone "Send Data Stream Transport for non-media data (draft-ietf- rtcweb-data-channel) to IESG for publication as Proposed Standard", set due date to May 2014 from May 2103. Changed milestone "Send Security Solution (draft-ietf-rtcweb-security-arch) to IESG for publication as Proposed Standard", set due date to June 2014 from January 2013. Changed milestone "Send Signalling Negotiation and NAT Traversal (draft-ietf- rtcweb-jsep) to IESG for publication as Proposed Standard", set due date to September 2014 from January 2013. Changed milestone "Send STUN Usage for Consent Freshness to IESG for publication as proposed standard", set due date to September 2014 from March 2014. Changed milestone "Video Processing and Video Codecs (draft-ietf-rtcweb-video) to IESG for publication as Proposed StandardVideo Processing and Video Codecs (draft-ietf-rtcweb-video) to IESG for publication as Proposed Standard", set due date to December 2014 from January 2013. URL: http://datatracker.ietf.org/wg/rtcweb/charter/ From nobody Tue Feb 18 02:10: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 7A3BD1A061F for ; Tue, 18 Feb 2014 02:10:30 -0800 (PST) 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 4KEPE3BjBA4i for ; Tue, 18 Feb 2014 02:10:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4622C1A065D for ; Tue, 18 Feb 2014 02:10:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140218101026.26100.32032.idtracker@ietfa.amsl.com> Date: Tue, 18 Feb 2014 02:10:26 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ipxDR9-RX4cCylKXjsHcOQRadkk Subject: [rtcweb] Milestones changed for rtcweb WG 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, 18 Feb 2014 10:10:30 -0000 Deleted milestone "Send Quality of Service markings of RTCWeb packets (draft- ietf-rtcweb-qos) to IESG for publication as Proposed Standard". URL: http://datatracker.ietf.org/wg/rtcweb/charter/ From nobody Tue Feb 18 02:59: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 3F9411A0477 for ; Tue, 18 Feb 2014 02:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 ZxBCS9b0IwhE for ; Tue, 18 Feb 2014 02:59:24 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DA7A21A032F for ; Tue, 18 Feb 2014 02:59:23 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-bc-53033d088d31 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 22.83.23809.80D33035; Tue, 18 Feb 2014 11:59:20 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.2.347.0; Tue, 18 Feb 2014 11:59:19 +0100 Message-ID: <53033D07.2010305@ericsson.com> Date: Tue, 18 Feb 2014 11:59:19 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> In-Reply-To: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> Content-Type: multipart/mixed; boundary="------------050202090301030409060809" X-Brightmail-Tracker: H4sIAAAAAAAAA2WSe0iTURjGOfu2b5+SepymL0YaE60sLUPSRE3rn1QCcRmigU2aF5oX5qUC KS+hpqMER7ohWDYRb6nL24pQh2uVw2YSTUmzlDQvYKBYTTO/HQmh/37vc57zvOe85zCUYILn xqRn5kpkmWKpkLblKuO3CnyZUEp0sv8JDmr/U8YPRxfU6l+cGJRgG3JNIk3Pl8hOhF21TWus GaSy207f1LdN8QtRiX8FsmEAB0CvepZP2AVM0x10BbJlBFiHQNfVySNFE4Ke+w8R67LDx+BF LbvAMFzsBYaOBFamcRBM/CyiWd6PRaAdtOzaHeGNco7LsjM+DONfTNZmTvgcVCq+ITZGgEOh dSuMRRscBmtLcSwCdgV5USzBSJh+7M7uo3AMlLeardmCnaMUFpfzqpCjak8r1R4bYT9QfLi7 yx7Qt1JHEU6C90VPef/rKdBgWbT6ATtA2YhxR2fH0IVAu9jJV1mPFABKvR/RtQga2iZ4pKhG MCnf4rAFF09SMFpSxCNRnvBxu4lmmYuF8GDGyPkX2/tdTxPTEahtNiHSwgHadZ5EdoKqzRaK sB2MKAw0uxdwH4LSHjlNgsYQbC8P76b2Iqhblu+miuBz5Q8rC/BtUM4PIGLSIDA1lvJV1hf0 hs2aauv4nPFBMKvGacLBcG99m0/YD94pSzjkDl4wbC6myOhD4WvzMu8ROtuC+BnidGnqjVMa tPM9h7otXv3o06izDh1guEJXu9WV87ECnCrOlVyXSLIlsiRZnlSSo0McxsatEKVQ3kOCW1fu RF3cpzEORBRkZ0W9NtsfPROYP7/QnJgRoX95vNglyz3v7Vq4vd9KXaQxKTgiu16+YDHUH9rQ pEC0unu21OeygnupeH0mujEgedXtd6vumdZjeixqQ1EYHr9WH5iQ7KShlqZiXnnFhKwbxud8 ny+JEpXVA3ElGZtCbk6a2N+HkuWI/wLmIPqFbAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uE_mDpV6h3mS4ebNZXVgwba8i2Y Subject: [rtcweb] Fwd: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 18 Feb 2014 10:59:29 -0000 --------------050202090301030409060809 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit WG, As one of the consumers of what RMCAT WG will produce it is important that you checks that they are considering valid requirements. Please review and send notice that you have done so to the RMCAT WG mailing list and provide any feedback you have on the document. Cheers Magnus Westerlund --------------050202090301030409060809 Content-Type: message/rfc822; name="[rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="[rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02.eml" X-Mozilla-Keys: Received: from sessmg10.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.37) with Microsoft SMTP Server id 14.2.347.0; Mon, 17 Feb 2014 15:53:16 +0100 X-AuditID: c1b4fb3e-b7faf8e000001605-c6-5302225b08bc Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by sessmg10.ericsson.net (Symantec Mail Security) with SMTP id 06.B8.05637.C5222035; Mon, 17 Feb 2014 15:53:16 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 303CD1A0510; Mon, 17 Feb 2014 06:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1392648797; bh=a51H18Obi3oqI+7Yp7ehzd6amm8g+n5YjQDzspMxiuE=; h=From:To:Date:Message-ID:Content-Type:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Sender; b=hRcvpWPQYtx8Y1p1VZc2LRKCUCl3V7V8p6XmBOgU24AEuvWwcqpkha03EvS/p+NJa /rmKNpeVrQK2L1SmLSiLjXnrJ/dtl5bdakSMCcSZNUs/Alh8zxK5t+mpXD2xcunkmk DxsRDXIYZHaMdMrYH6UKl+Qn7bTnXKqfYGErlKyA= X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8211A050B for ; Mon, 17 Feb 2014 06:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.45 X-Spam-Level: X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 z2tq4h0Etszy for ; Mon, 17 Feb 2014 06:53:13 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB611A0209 for ; Mon, 17 Feb 2014 06:53:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,861,1384329600"; d="asc'?scan'208";a="143392536" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 17 Feb 2014 06:53:10 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.211]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 06:53:10 -0800 From: "Eggert, Lars" To: rmcat WG Thread-Topic: WGLC for draft-ietf-rmcat-cc-requirements-02 Thread-Index: AQHPK+/5W0yOYNlYsEiKSPgfn46BpA== Date: Mon, 17 Feb 2014 14:53:09 +0000 Message-ID: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.20] Content-Type: multipart/signed; boundary="Apple-Mail=_60779BBE-3C12-4D23-9094-61BFA13B696A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/wrXJLPpr83OkC5dsBFKMcS0oNwg Subject: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rmcat-bounces@ietf.org Sender: rmcat X-Brightmail-Tracker: H4sIAAAAAAAAA1VTf0yMYRzved/33ntLL68r+jrSek0zcsrMjhGGMTMzN5uZjaNXd3Od270n mR/5MTWlOqzoZig5SokmP7KSW8LViKQwp2v5lZRY8iNy7z1X8t/n+3w+n+/n+3z3PAyp6KWV jJBoEcxGrYGnAygqrCZy6jqe0ESlnotQW6sdpPpKbRZSPylxEerbVd9odWVdP6l2/eih1dXO TnK+fOnPnkZ6JVobMCdWMOgTBPO0mA0BugtleTJTFpOYkZ4m24ty5KmIYYCbATl3VanI3wNH Q72rhE5FAYyCu46gv6HCV2QhaH1ZREgFxb0g4eGBfTJsmQBN/edpCVMcD5ktdQR2XEFws1yK kEST4ERBPcJxI6DYMQEfB4G1r5DEeDg8fv/d6wUpOrnssC+6AUHXvRI5Lq4hePr2N4EtGnid 1u2NVnB7IP/qRQqLShHUn0v2RtNcBPQdP0ZJOJgLhWZbA43xbDjU0y/HWAWPcg4Q+A4Tobp5 v3cmlpsLrQUd3nsiz2p6nUVeDcmFwIu2074hgsH9uJYeWN+fcrcPh4PrRwUpDURy2QhqXudT uOlIeJDTRuGmGkhz2mkrirQN6Wsb6rEN8WDRFLDnfiRtnl2SXCQcy0X4OAyufzpJYjwLSm58 kWM8Fy5d6vJZY6A1O092BvkXolGiIIrxcdFRKsGs3ySKW40qo2ApRZ7Xdufqr5gb6Jk72oHG MAQ/is0LJzSK4Ru3xu7QaUXdevM2gyA60FiG4kNYBeVepeDitBZhiyCYBPMAO45heGC3S86R ZiFOSNysN1j+0QTj70DABPLBbKKkYUWTNl7Ux2HeicKVIZjgJEK3zTjoHfgPT1CoMohFfn5+ ikBPbrze8j/fjkIYxAexSVKXQL3RMti93RNMeIKXVSAp2KL9Ryn3oqwVLpPz2qlGU3KLPTd2 TesC68E/z1JuarqqupUz37ybXijbfT8jqdJmDf0Zv/jMwrbPZfvO3ko22BMqX9VEJH3dX9Y8 +suYYZnPq45WXF4n29WbX0BEqpj2BylPOzsb3xQf3emesWjK8oRbR9i+jnRb0/gFI8qX2kvn CUs+yGNW5wW38JSo00ZPJs2i9i9+5kCkCgQAAA== Return-Path: rmcat-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: ESESSHC006.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 --Apple-Mail=_60779BBE-3C12-4D23-9094-61BFA13B696A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, we'd like to start the working group last call for = draft-ietf-rmcat-cc-requirements-02. Please send your feedback to the = list. We're letting this LC run until March 12 (after the London meeting), so = there will also be a chance to discuss any feedback there. Lars --Apple-Mail=_60779BBE-3C12-4D23-9094-61BFA13B696A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUwIiVdZcnpRveo1xAQJdGwQAh52tThAvEkGleEbojQGVUXc+QIe5TpN4 vdvWEo8BIeFHS/EUJysJ3q2e51yDSzAVV02Xetlzhk1g0wSkxigFvm9azXvKLwM2 pBRsyFTZiy2bOOwx2868fbZXwVUgXdI0fBq4j7QtJdqTCFD70Bbw4uriO0gbNE2s tJYCGQQxM+A= =Gn6H -----END PGP SIGNATURE----- --Apple-Mail=_60779BBE-3C12-4D23-9094-61BFA13B696A-- --------------050202090301030409060809-- From nobody Tue Feb 18 06:11: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 F20591A0673; Tue, 18 Feb 2014 06:11:29 -0800 (PST) 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 ZBU0wCsk5ZU7; Tue, 18 Feb 2014 06:11:22 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 396721A0491; Tue, 18 Feb 2014 06:11:22 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id q8so12298300lbi.14 for ; Tue, 18 Feb 2014 06:11:18 -0800 (PST) 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=+iRDEqmjrAdkGMw2OqGEqPq+ve2QuSJBbmQGHGJxiyI=; b=cS8/mWvwMmtBn5aWqhitlxdanjG1LsmbuMYZbQ51YTwkdt/lbd5hy216/QZCM+ttJY LH3uVOlsIEu2qcrMUihX4b5wDjaS6AMqPPaCElOteVi/38wzHRQN8x9DhYGpXlB9V7Dh qq3NziP16FDhQ2AecE74x0C8wUjoZeVQc0eqEhehmHqZ/PL6iN1fQ1ttXbcGuEUrCL5h oMfX0TLRR0zAHytnPS90dG7+yrrUzGu8cGiGYDsDdKv5USgqDnfrAdScXFCqwZZKWdeF YK1bPLU+Ob/3EltgYR3yw/utb7DJiHXhiLcR1w4gAWBihIWvTmjLgiVsNZ8wmB2LTWv2 ZwDQ== MIME-Version: 1.0 X-Received: by 10.152.1.3 with SMTP id 3mr1632700lai.58.1392732678668; Tue, 18 Feb 2014 06:11:18 -0800 (PST) Received: by 10.112.98.162 with HTTP; Tue, 18 Feb 2014 06:11:18 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D1730E7@ESESSMB209.ericsson.se> Date: Tue, 18 Feb 2014 08:11:18 -0600 Message-ID: From: Richard Ejzak To: "Liuyan (Scarlett)" Content-Type: multipart/alternative; boundary=089e013c6ae494471104f2aed8b7 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PH7AliJ0tGgSGKO2PrkerfQnLXI Cc: "rtcweb@ietf.org" , mmusic@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt - the data channel's state and the SCTP association X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 18 Feb 2014 14:11:30 -0000 --089e013c6ae494471104f2aed8b7 Content-Type: text/plain; charset=ISO-8859-1 Hi Scarlett, Please note that this document has been replaced by draft-ejzak-mmusic-data-channel-sdpneg-00 (this is noted in datatracker) and that discussion of the topic should be directed to the mmusic list (although there is some obvious overlap with the data channel discussion regarding external negotiation). I copied both groups for this email only - please respond only to mmusic. " It is not clear that if the SCTP association is failed to establish, how to we deal with the newly created data channels. Furthermore, how long the valid duration of the connecting state of the newly created data channels are before the SCTP association has not yet established ?" This issue is common to all forms of data channel negotiation and should be addressed by the core documents rather than this one. It appears that a data channel can be in the connecting state indefinitely until the peer connection is closed. "When there are multiple data channels with different sub-protocol per a SCTP association, Maybe it needs to identify how to close a single data channel, how to close all data channels with the same sub-protocol and how to close a SCTP association. Of course, closing a SCTP association can just set SCTP port number zero.:-) " The procedure describes how to close a single data channel. We did not see a need to have a special way to close all data channels with the same sub-protocol since they can just be closed individually. I don't see a compelling use case for this, but perhaps you have one? The document should point out that data channels terminate with the SCTP association and peer connection. Sometimes we forget to state the most obvious things! BR, Richard On Mon, Feb 17, 2014 at 5:30 AM, Liuyan (Scarlett) < scarlett.liuyan@huawei.com> wrote: > Hi, > > Section 5.5.2 does say: > > "o As described in Section 4.2.2, if the SCTP association is not > yet > established, then the newly created data channels are in the > Connecting state, else if the SCTP association is already > established, then the newly created data channels are in the Open > state." > ..... > It is not clear that if the SCTP association is failed to establish, how > to we deal with the newly created data channels. > Furthermore, how long the valid duration of the connecting state of the > newly created data channels are before the SCTP association has not yet > established ? > > Section 5.5.3 does say: > "5.2.3. Closing a data channel > > When the application requests the closing of a data channel that was > externally negotiated, the browser always performs an in-band SSN > reset for this channel. > > It is specific to the sub-protocol whether this closing must in > addition be signaled to the peer via a new SDP offer/answer exchange. > > The application must also close any data channel that was externally > negotiated, for which the stream identifiers are not listed in an > incoming SDP offer." > ... > When there are multiple data channels with different sub-protocol per a > SCTP association, > Maybe it needs to identify how to close a single data channel, how to > close all data channels with the same sub-protocol and how to close a SCTP > association. > Of course, closing a SCTP association can just set SCTP port number > zero.:-) > > Regards, > Scarlett > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e013c6ae494471104f2aed8b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Scarlett,
Please note that this document has been r= eplaced by draft-ejzak-mmusic-data-channel-sdpneg-00 (this is noted in data= tracker) and that discussion of the topic should be directed to the mmusic = list (although there is some obvious overlap with the data channel discussi= on regarding external negotiation). =A0I copied both groups for this email = only - please respond only to mmusic.

"=A0It is not clear that if the SCTP association is failed to establish, = how to we deal with the newly created data channels.
=A0 Furthe= rmore, how long the valid duration of the connecting state of the newly cre= ated data channels are before the SCTP association has not yet established = ?"

This issue is common to all forms of data channel negot= iation and should be addressed by the core documents rather than this one. = =A0It appears that a data channel can be in the connecting state indefinite= ly until the peer connection is closed.

"When there are multiple data channels with different sub-protoco= l per a SCTP association,
Maybe it needs to identify how to close a single dat= a channel, how to close all data channels with the same sub-protocol and ho= w to close a SCTP association.
Of course,= closing a SCTP association can just set SCTP port number zero.:-)&q= uot;

The procedure describes how to close a single= data channel. =A0We did not see a need to have a special way to close all = data channels with the same sub-protocol since they can just be closed indi= vidually. =A0I don't see a compelling use case for this, but perhaps yo= u have one? =A0The document should point out that data channels terminate w= ith the SCTP association and peer connection. =A0Sometimes we forget to sta= te the most obvious things!

BR, Richard=A0

On Mon, Feb 17, 2014 at 5:30 AM, Liuyan (S= carlett) <scarlett.liuyan@huawei.com> wrote:
Hi,

Section 5.5.2 does say:

=A0 =A0 =A0 =A0 "o =A0As described in Section 4.2.2, if the SCTP assoc= iation is not yet
=A0 =A0 =A0 established, then the newly created data channels are in the =A0 =A0 =A0 Connecting state, else if the SCTP association is already
=A0 =A0 =A0 established, then the newly created data channels are in the Op= en
=A0 =A0 =A0 state."
=A0 .....
=A0 It is not clear that if the SCTP association is failed to establish, ho= w to we deal with the newly created data channels.
=A0 Furthermore, how long the valid duration of the connecting state of the= newly created data channels are before the SCTP association has not yet es= tablished ?

Section 5.5.3 does say:
=A0 =A0 =A0 =A0"5.2.3. =A0Closing a data channel

=A0 =A0 =A0 When the application requests the closing of a data channel tha= t was
=A0 =A0 =A0 externally negotiated, the browser always performs an in-band S= SN
=A0 =A0 =A0 reset for this channel.

=A0 =A0 =A0 It is specific to the sub-protocol whether this closing must in=
=A0 =A0 =A0 addition be signaled to the peer via a new SDP offer/answer exc= hange.

=A0 =A0 =A0 The application must also close any data channel that was exter= nally
=A0 =A0 =A0 negotiated, for which the stream identifiers are not listed in = an
=A0 =A0 =A0 incoming SDP offer."
=A0 =A0...
=A0 =A0When there are multiple data channels with different sub-protocol pe= r a SCTP association,
Maybe it needs to identify how to close a single data channel, how to close= all data channels with the same sub-protocol and how to close a SCTP assoc= iation.
Of course, closing a SCTP association can just set SCTP port number zero.:-= )

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

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

--089e013c6ae494471104f2aed8b7-- From nobody Tue Feb 18 06:25: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 3C2171A01CB for ; Tue, 18 Feb 2014 06:25:22 -0800 (PST) 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 iGnXgQXg8sVv for ; Tue, 18 Feb 2014 06:25:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB861A067B for ; Tue, 18 Feb 2014 06:25:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140218142514.7984.11076.idtracker@ietfa.amsl.com> Date: Tue, 18 Feb 2014 06:25:14 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/u3EXYwkiq_WneOxR4UzVjUWgv8w Subject: [rtcweb] Milestones changed for rtcweb WG 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, 18 Feb 2014 14:25:22 -0000 Changed milestone "Send Specification of Transport Protocols and their NAT Traversal to IESG for publication as Proposed Standard", set state to active from review, accepting new milestone. Changed milestone "Send Overview (after dependencies are ready) to IESG for publication as Applicability Statement", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/rtcweb/charter/ From nobody Tue Feb 18 06:47: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 01E651A06A2 for ; Tue, 18 Feb 2014 06:47:02 -0800 (PST) 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 qAE8qxG7yUGh for ; Tue, 18 Feb 2014 06:46:59 -0800 (PST) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id CF0A71A01F5 for ; Tue, 18 Feb 2014 06:46:58 -0800 (PST) Received: by mail-yh0-f51.google.com with SMTP id t59so15641595yho.10 for ; Tue, 18 Feb 2014 06:46:55 -0800 (PST) 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=yk4qO/emuIEdFoXFs/PjiUe5IW8vsjQ7JWoMQzUFfp8=; b=NLUyzMzXRHkBPfSql9pCn9ZMtrky2NiBpTtRrs8YK3onVCvrYZUgzBPDygJFYPjxAG 2lzWJbmPU6dIuAMbAZx30GTean4wLL/tsiTabs/kN6dYmHXd5oimGGeJopazeGHNRU/c QslmuXRCWaqJe+LtmJISWvcA9vS0BpTETKCTn2/H0ZFXw/QVgtuB54OC3GzzNt8KXjQX CdfQ2+z20lgOPYCUzuXXs03JZyZVlXENVTYDFGRtem5d2B4W+eVS0fUddPsLMsvO1OcB 8/QMRfenj+OWJk7CCyUfXuirKKY7eZ4FQD+i4jdolIsfOoX6JS5TYpMQD/oHKs/pokoa Zeuw== MIME-Version: 1.0 X-Received: by 10.236.63.135 with SMTP id a7mr24649416yhd.84.1392734815454; Tue, 18 Feb 2014 06:46:55 -0800 (PST) Received: by 10.170.213.85 with HTTP; Tue, 18 Feb 2014 06:46:55 -0800 (PST) In-Reply-To: <52FCF6E5.1010006@ericsson.com> References: <52E8B4F8.4000900@ericsson.com> <52FCF6E5.1010006@ericsson.com> Date: Tue, 18 Feb 2014 08:46:55 -0600 Message-ID: From: Mary Barnes To: Magnus Westerlund Content-Type: multipart/alternative; boundary=089e01294412f110ba04f2af576e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5-BEjgS4-3z06sKGGvOdeMfZJnM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Updated Potential dates for WebRTC/RTCWEB joint Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 18 Feb 2014 14:47:02 -0000 --089e01294412f110ba04f2af576e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Are there plans to discuss any of the documents that are dependencies in the MMUSIC WG at this meeting? As I'm recalling, the initial agenda for the last interim had a number of MMUSIC WG documents, thus there was an agenda change to also organize part of the meeting as an MMUSIC WG interim. Thanks, Mary. On Thu, Feb 13, 2014 at 10:46 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > WG, > > We have received some feedback on the dates. After having done some > checking we propose to shift the interim meeting one day earlier to > reduce the overlap with the 3GPP meeting. Thus, the proposed dates for > the interim is 19-21 of May (Mon-Wed). > > If you are willing to host, please contact the WG chairs. > > Cheers > > Magnus, Ted and Cullen > > > On 2014-01-29 08:59, Magnus Westerlund wrote: > > WG, > > > > The chairs of this WG and the W3C are considering an joint interim > > meeting. The dates we chairs have arrived as feasible are May 20-22 > > (Tue-Thu). We are considering to split up the time between the two WGs > > across all three days. So please take note of these dates in your > > calendar now. > > > > The target region for this interim would be East Coast of North America= , > > but we have at this stage no host or set location. If you are willing t= o > > host, please contact the chairs. > > > > We haven't decided on this interim yet, and appreciate your input into > > holding one. The goals of the interim would be to advanced the state of > > the core documents we need to finish up. We expect that we will have > > some document that may have WG last call issues needing face to face > > time to speed up resolving them. We expect to have documents that are > > under development, like JSEP that will have thorny issues to deal with. > > Especially issues that interact with the API where we can benefit from > > having the W3C WG also present to come to joint conclusions. > > > > Cheers > > > > Magnus Westerlund > > (For the RTCWEB Chairs) > > > > ---------------------------------------------------------------------- > > Services, Media and Network features, Ericsson Research EAB/TXM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e01294412f110ba04f2af576e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Are there plans to discuss any of the documents that are d= ependencies in the MMUSIC WG at this meeting? =A0As I'm recalling, the = initial agenda for the last interim had a number of MMUSIC WG documents, th= us there was an agenda change to also organize part of the meeting as an MM= USIC WG interim. =A0

Thanks,
Mary.=A0


On Thu, Feb 13, 2014 at 10:46 AM, M= agnus Westerlund <magnus.westerlund@ericsson.com> wrote:
WG,

We have received some feedback on the dates. After having done some
checking we propose to shift the interim meeting one day earlier to
reduce the overlap with the 3GPP meeting. Thus, the proposed dates for
the interim is 19-21 of May (Mon-Wed).

If you are willing to host, please contact the WG chairs.

Cheers

Magnus, Ted and Cullen


On 2014-01-29 08:59, Magnus Westerlund wrote:
> WG,
>
> The chairs of this WG and the W3C are considering an joint interim
> meeting. The dates we chairs have arrived as feasible are May 20-22 > (Tue-Thu). We are considering to split up the time between the two WGs=
> across all three days. So please take note of these dates in your
> calendar now.
>
> The target region for this interim would be East Coast of North Americ= a,
> but we have at this stage no host or set location. If you are willing = to
> host, please contact the chairs.
>
> We haven't decided on this interim yet, and appreciate your input = into
> holding one. The goals of the interim would be to advanced the state o= f
> the core documents we need to finish up. We expect that we will have > some document that may have WG last call issues needing face to face > time to speed up resolving them. We expect to have documents that are<= br> > under development, like JSEP that will have thorny issues to deal with= .
> Especially issues that interact with the API where we can benefit from=
> having the W3C WG also present to come to joint conclusions.
>
> Cheers
>
> Magnus Westerlund
> (For the RTCWEB Chairs)
>
> ----------------------------------------------------------------------=
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------=
> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Phone =A0+46 10 7148287
> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------=
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>


--

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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

--089e01294412f110ba04f2af576e-- From nobody Tue Feb 18 07:19: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 6BB5D1A03DC for ; Tue, 18 Feb 2014 07:19:30 -0800 (PST) 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_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 Va5vR3N2fDSZ for ; Tue, 18 Feb 2014 07:19:26 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 395DA1A0684 for ; Tue, 18 Feb 2014 07:19:20 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-9a-530379f399d4 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 89.F5.04249.3F973035; Tue, 18 Feb 2014 16:19:15 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.2.347.0; Tue, 18 Feb 2014 16:19:15 +0100 Message-ID: <530379F3.5090102@ericsson.com> Date: Tue, 18 Feb 2014 16:19:15 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mary Barnes References: <52E8B4F8.4000900@ericsson.com> <52FCF6E5.1010006@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvje7nSuZgg00brC0+79/PbLH2Xzu7 A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXRsOcCY8F3jopVd88zNjDOYe9i5OSQEDCR uLP/FwuELSZx4d56ti5GLg4hgSOMEvPvnWeFcJYzSrRsuAvWwSugLXHr3z4mEJtFQFViw9l2 VhCbTcBC4uaPRjYQW1QgWGLngd+MEPWCEidnPgHbICKgI/Ht81uwGmYBdYk7i8+BzRQW8JWY v2kWE8SyCYwS27qmgQ3lFAiUmHXjHlCCA+g8cYmexiCIXj2JKVdbGCFseYnmrbOZQWwhoNsa mjpYJzAKzUKyehaSlllIWhYwMq9i5ChOLU7KTTcy2MQIDNeDW35b7GC8/NfmEKM0B4uSOO/H t85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhiX72KqYJA9VMwYsLbGw/CdDPeEF1p8m2qm FfbFfP3TqtzQWHepjuXXncl2OWXp1ozfS+eX+YTphf/7lWd1SsJwHruf9o1q4QuWTw+1eKzK 61mhoeyl/3dnhKtBX31O9KPXx9z3J1fl/jdP1thaK/9zpV6hwJstLhGcU3cvNm7/NUWejzVZ X4mlOCPRUIu5qDgRABH4sKAlAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FbFwIrJ0N8u-B6U0s6FhxhxBzTI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Updated Potential dates for WebRTC/RTCWEB joint Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 18 Feb 2014 15:19:30 -0000 On 2014-02-18 15:46, Mary Barnes wrote: > Are there plans to discuss any of the documents that are dependencies in > the MMUSIC WG at this meeting? As I'm recalling, the initial agenda for > the last interim had a number of MMUSIC WG documents, thus there was an > agenda change to also organize part of the meeting as an MMUSIC WG > interim. At this stage this is an RTCWEB/WEBRTC interim only. This WG part of the time we intended to focus on resolving any open issues with the WG's documents. We have asked the MMUSIC chairs about the interim meeting, which at the time we asked declined interest in a co-located interim meeting. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Feb 18 07:34: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 A76601A0238 for ; Tue, 18 Feb 2014 07:34:41 -0800 (PST) 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 46qVbk2CeH4y for ; Tue, 18 Feb 2014 07:34:35 -0800 (PST) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 832891A021B for ; Tue, 18 Feb 2014 07:34:35 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id f73so15606243yha.17 for ; Tue, 18 Feb 2014 07:34:32 -0800 (PST) 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=sz6xi0hLo5IUyi7/CJe8gDKG2U2q6hnauI8ouFEyMRI=; b=bl5o/jO+7TP1xSEBiPJe9JvQGKT5sCspmREJxemv6R9F9GanDte57G7vFB7m16/+jq mPPYepVyI0/rk8DgKXOsaQ2LNMTs3cGbJXyhCS34vCLdcxj9F5Ff3+rtF42jgoZW9eUa L2AU2XOBh34I3W/yD+0y/F8+XNfjZiw3wKzLeaboFu+lc1Afx6NI9w0aS2tnnaOITHjt q7Is8PJIGGluRUnh5CN6LYha3PC5lql1FzACHb5r855f1Xjz5mEB3PNrKqgafjfj1jpM 21ghKUFttK00uYT6nY1FPMQ/r5RRJAAHHVuv79IVz5BrPFTw7O5y1htGiIqlF0sZ7EIt WiGw== MIME-Version: 1.0 X-Received: by 10.236.23.71 with SMTP id u47mr3371235yhu.143.1392737672451; Tue, 18 Feb 2014 07:34:32 -0800 (PST) Received: by 10.170.213.85 with HTTP; Tue, 18 Feb 2014 07:34:32 -0800 (PST) In-Reply-To: <530379F3.5090102@ericsson.com> References: <52E8B4F8.4000900@ericsson.com> <52FCF6E5.1010006@ericsson.com> <530379F3.5090102@ericsson.com> Date: Tue, 18 Feb 2014 09:34:32 -0600 Message-ID: From: Mary Barnes To: Magnus Westerlund Content-Type: multipart/alternative; boundary=e89a8f64782d3b5b7504f2b002cf Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zHoQ4en1mJVURGGTDMDNl5_Wknk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Updated Potential dates for WebRTC/RTCWEB joint Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 18 Feb 2014 15:34:41 -0000 --e89a8f64782d3b5b7504f2b002cf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks! On Tue, Feb 18, 2014 at 9:19 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-02-18 15:46, Mary Barnes wrote: > > Are there plans to discuss any of the documents that are dependencies i= n > > the MMUSIC WG at this meeting? As I'm recalling, the initial agenda fo= r > > the last interim had a number of MMUSIC WG documents, thus there was an > > agenda change to also organize part of the meeting as an MMUSIC WG > > interim. > > At this stage this is an RTCWEB/WEBRTC interim only. This WG part of the > time we intended to focus on resolving any open issues with the WG's > documents. > > We have asked the MMUSIC chairs about the interim meeting, which at the > time we asked declined interest in a co-located interim meeting. > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --e89a8f64782d3b5b7504f2b002cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks!


On Tue, Feb 18, 2014 at 9:19 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
On 2014-02-18 15:46, Mary Ba= rnes wrote:
> Are there plans to discuss any of the documents that are dependencies = in
> the MMUSIC WG at this meeting? =A0As I'm recalling, the initial ag= enda for
> the last interim had a number of MMUSIC WG documents, thus there was a= n
> agenda change to also organize part of the meeting as an MMUSIC WG
> interim.

At this stage this is an RTCWEB/WEBRTC interim only. This WG part of = the
time we intended to focus on resolving any open issues with the WG's documents.

We have asked the MMUSIC chairs about the interim meeting, which at the
time we asked declined interest in a co-located interim meeting.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--e89a8f64782d3b5b7504f2b002cf-- From nobody Tue Feb 18 14: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 AD7131A0406 for ; Tue, 18 Feb 2014 14:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 1WWlLKWoAEdg for ; Tue, 18 Feb 2014 14:58:07 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id DF2CD1A026A for ; Tue, 18 Feb 2014 14:58:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 592AB7C4BAC for ; Tue, 18 Feb 2014 23:58:03 +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 8QwFOUl335ZB for ; Tue, 18 Feb 2014 23:58:02 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4FB9C7C4BA0 for ; Tue, 18 Feb 2014 23:58:02 +0100 (CET) Message-ID: <5303E578.3000207@alvestrand.no> Date: Tue, 18 Feb 2014 23:58:00 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <530320F7.4090300@ericsson.com> In-Reply-To: <530320F7.4090300@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/H_s7fbvxKqaB5w9fDCKIBynuMvs Subject: Re: [rtcweb] Number of samples (ptime) to be supported by required codecs (draft-ietf-rtcweb-audio-05) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 18 Feb 2014 22:58:10 -0000 I may be a little simple-minded, but if we have a recommendation that receivers MUST be able to receive all packetizations of G.711 and OPUS up to 200 ms per packet, and that receivers should signal this by sending "a=maxptime:200" in their SDP, what situations exist where interoperability is not going to be achieved? I mean - if a G.711 receiver is able to handle any packet size thrown at it, why do we need to put requirements on the sender (apart from "don't send bigger packets than the maxptime")? For interoperability with non-WebRTC endpoints? Of course, I do have a question, now that all the ptime and maxtime definitions have been put on the table: Is it true that ptime and maxptime only specify the SDP sender's declaration of his desires for incoming packet streams? That is, that there is nowhere specified what the sender intends to send? I think that is true for ptime in RFC 3264 offer/answer, and would assume that the same is true for maxptime. From nobody Tue Feb 18 15:36: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 EB2AC1A02BB for ; Tue, 18 Feb 2014 15:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] 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 iI5aux8GySFf for ; Tue, 18 Feb 2014 15:35:57 -0800 (PST) Received: from mork.alvestrand.no (unknown [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39E1A0470 for ; Tue, 18 Feb 2014 15:35:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 8FBB17C4BC5; Wed, 19 Feb 2014 00:35:50 +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 ITB0WV5phnDn; Wed, 19 Feb 2014 00:35:50 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id 68F5E7C4BAC; Wed, 19 Feb 2014 00:35:49 +0100 (CET) Message-ID: <5303EE53.1010405@alvestrand.no> Date: Wed, 19 Feb 2014 00:35:47 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Christer Holmberg , "rtcweb@ietf.org" References: <52FDC17E.8070708@alvestrand.no>, <52FE5B37.80409@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1735EE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1735EE@ESESSMB209.ericsson.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9LWj3fTdZAwej255jkpFLLb4pyA Subject: Re: [rtcweb] Stream control: [MMUSIC] msid-04 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 18 Feb 2014 23:36:02 -0000 One thing I did not add in my previous reply: If an offerer sets the direction of an m-line to sendrecv, and the answerer sets the direction to sendonly, the offerer will have no indication of whether the answerer intended the suspension of traffic to be temporary (msid-control: disable) or permanent (msid-control: reject or msid-control: stop). That was actually the main concern that drove the desire for a new mechanism. Once the new mechanism was in place, it seemed logical to be explicit about the other possible actions too, rather than relying on the sendrecv/sendonly/recvonly parameter. Harald From nobody Tue Feb 18 23:27: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 B93091A037D for ; Tue, 18 Feb 2014 23:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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, RP_MATCHES_RCVD=-0.548, 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 tmCenHbJd9wq for ; Tue, 18 Feb 2014 23:27:33 -0800 (PST) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0C16B1A0366 for ; Tue, 18 Feb 2014 23:27:32 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id pa12so14303veb.5 for ; Tue, 18 Feb 2014 23:27:29 -0800 (PST) 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=nUGqVTq5xZyn90m1FJWHyUbMnlNEetP1ti33BWOpzBg=; b=fKlmYROBdwZu0kkcr2O1jnGLM0c2raCHME7ORED9URdzvsMJK0DeImtMs6cuQ4ttxQ eJY5ESZWzJG2bVerPJ20qyu11tunb1fuW/iduJLej6fvF5WECGZjPSO1egcqk6Gn0LR/ XgxqwwYueSqXdGTScoM8MpmmoNSF+T7k72sdNxF6K+TNSm9wZ+1/sAq/d1/CCd9nPwa4 SCMBN8hrMH+PyXeSrCg1qUkzxFMsqIuor1HFawfwWxtKezra8nfDVsF6vn7qBDatAzCB oXvI5/GQTfHEgnkU8A2k+ns5MwqG+G/ai35V6ymUru+PJz9Wn0l1EeDyVWSy4U4Pq8p/ z66Q== 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=nUGqVTq5xZyn90m1FJWHyUbMnlNEetP1ti33BWOpzBg=; b=gALnCduQxYP+I4O/Km6c9PFW2Ri87XLjpMOyzDflsPE16R4HIzftpjFwAuQq3KYN7u 6vpR92uljfK2d1PnTf0pINA1MLfc9PxcyY+0uSgAokqcMkUiYhiLgmGMp8iTw8+NgfZQ GGKxXbKk8jRkX+DOygbyc/3pO7P0YBWfyQGBZNsAt4ktWbVjP10GnpiXIJ2qvCPS9wDd ayxZ3c2tOkZZrFrL5Z1JoPUql/TuxlSatVNgmZVnM22d1mytjov4S999L6WQfz7e3jAN +aReS47kXZyBVyirmx1a6mMhOVknJjCNz+u2AWdhlj5+nxvxuEXNxYOkVIrM5Ql+yTci JPug== X-Gm-Message-State: ALoCoQmz/PE5lY2K8ghizXQuBExZ5p+cNk0+kQBNVVUWqmi9I6YGXM2Z7jgafQi69+KXc6/XSbHc+jC3t3/OcjD3/6Zu6inJhCgqK1kIhFw+2RWIQYYB0RI0+xhnXhU+WCkGa1Wfndaur7qL41rXwWSLfakX5grPQjcwXnopUFvZWh5QQZvdxaCvu1QG46jNthCrfA3Pus5q X-Received: by 10.52.236.132 with SMTP id uu4mr323754vdc.47.1392794849605; Tue, 18 Feb 2014 23:27:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Tue, 18 Feb 2014 23:27:09 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1730E7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1730E7@ESESSMB209.ericsson.se> From: Justin Uberti Date: Tue, 18 Feb 2014 23:27:09 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e01183eb4419ce804f2bd52a2 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VKmkm1b9remDA7e3weFwQLvrTZU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - PeerConnection BUNDLE policy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 19 Feb 2014 07:27:36 -0000 --089e01183eb4419ce804f2bd52a2 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 14, 2014 at 6:22 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Section 4.1.1. defines, for the PeerConnection constructor, the > possibility to specify BUNDLE policy. > > However, I am missing the possibility to indicate whether, within a BUNDLE > group, the same port number shall be used or not. > > Section 5.2.1 does say: > > "o The port value is set to the port of the default ICE candidate > for > this m= section; if this m= section is not being bundled into > another m= section, the port value MUST be unique." > > ...but, it doesn't talk about the case when the port IS being bundled into > another m= section. Normally, in the initial Offer, the port value will be > unique also in that case, but if the PeerConnection is created due to > forking, and it is known that the remote peer supports BUNDLE, then > identical port values can be used already in the initial offer. > If a m= section is being bundled into another m= section, then the port number must be the same, as indicated in the BUNDLE WG draft. I did not include a policy option to force use of the same port; the closest thing would be to use a policy of "all", which will mark all lines except the first as bundle-only and achieve basically the same result, although it would require a second offer to update the bundle-only ports. If this is a problem we could consider adding another policy value. --089e01183eb4419ce804f2bd52a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Feb 14, 2014 at 6:22 AM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:
Hi,

Section 4.1.1. defines, for the PeerConnection constructor, the possibility= to specify BUNDLE policy.

However, I am missing the possibility to indicate whether, within a BUNDLE = group, the same port number shall be used or not.

Section 5.2.1 does say:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "o =C2=A0The port value is set to the port= of the default ICE candidate for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this m=3D section; if this m=3D section is not = being bundled into
=C2=A0 =C2=A0 =C2=A0 =C2=A0 another m=3D section, the port value MUST be un= ique."

...but, it doesn't talk about the case when the port IS being bundled i= nto another m=3D section. Normally, in the initial Offer, the port value wi= ll be unique also in that case, but if the PeerConnection is created due to= forking, and it is known that the remote peer supports BUNDLE, then identi= cal port values can be used already in the initial offer.

If a m=3D section is being bundled into an= other m=3D section, then the port number must be the same, as indicated in = the BUNDLE WG draft.=C2=A0

I did not include a= policy option to force use of the same port; the closest thing would be to= use a policy of "all", which will mark all lines except the firs= t as bundle-only and achieve basically the same result, although it would r= equire a second offer to update the bundle-only ports. If this is a problem= we could consider adding another policy value.

--089e01183eb4419ce804f2bd52a2-- From nobody Wed Feb 19 00:16: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 0D1A81A00AD for ; Wed, 19 Feb 2014 00:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 272lfyMvGLde for ; Wed, 19 Feb 2014 00:16:08 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3D91A0080 for ; Wed, 19 Feb 2014 00:16:07 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-54-530468437a1d Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D9.57.23809.34864035; Wed, 19 Feb 2014 09:16:03 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.2.347.0; Wed, 19 Feb 2014 09:16:02 +0100 Message-ID: <53046842.2010108@ericsson.com> Date: Wed, 19 Feb 2014 09:16:02 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Harald Alvestrand , References: <530320F7.4090300@ericsson.com> <5303E578.3000207@alvestrand.no> In-Reply-To: <5303E578.3000207@alvestrand.no> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZGfG3Rtc5gyXYYO0yIYtjfV1sFmv/tbM7 MHlcmXCF1WPJkp9MAUxRXDYpqTmZZalF+nYJXBmX/25lK9gjXHFg60W2BsYH/F2MnBwSAiYS 80/dYIOwxSQu3FsPZHNxCAkcYpRYveg3O0hCSGA5o0TjqtAuRg4OXgFtibXHjEHCLAKqEm+2 rGMGsdkELCRu/mgEmyMqECyx88BvRhCbV0BQ4uTMJywgtoiAvcTFOS/BbGGBQokju3pYIcb7 SPTt+g9mcwroSlx8+oARZJWEgLhET2MQSJhZQE9iytUWRghbXqJ562xmiFZtiYamDtYJjIKz kGybhaRlFpKWBYzMqxjZcxMzc9LLjTYxAsPx4JbfqjsY75wTOcQozcGiJM774a1zkJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQZGeXkf5ghuL4P7M9+JFdlUmQWzO75quMYcED3Z9oVefTvT bu6/t7KZZ1oanJ/opd5RbWyyXoJ/tWF7+/k/OydNY9r1ZjGn/xKlOJeWVr+A7KOzJh+48nSu 9Hr1koC2U1W/V/D27mtz37rifZL0e7cGKe4Lhxc5sups0LDVX77uXH5Y2/v0+41KLMUZiYZa zEXFiQChBnnRFQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dfFpmEONrtumz7ThoGg5S_PR-G0 Subject: Re: [rtcweb] Number of samples (ptime) to be supported by required codecs (draft-ietf-rtcweb-audio-05) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 19 Feb 2014 08:16:11 -0000 On 2014-02-18 23:58, Harald Alvestrand wrote: > I may be a little simple-minded, but if we have a recommendation that > receivers MUST be able to receive all packetizations of G.711 and OPUS > up to 200 ms per packet, and that receivers should signal this by > sending "a=maxptime:200" in their SDP, what situations exist where > interoperability is not going to be achieved? Interoperability is going to be achieve in the direction towards this endpoint. The question is if we achieve interoperability in the direction from that endpoint. > > I mean - if a G.711 receiver is able to handle any packet size thrown at > it, why do we need to put requirements on the sender (apart from "don't > send bigger packets than the maxptime")? For interoperability with > non-WebRTC endpoints? If the above endpoint would be to send 109 samples in each RTP payload then I think more than one of the current PCMA receivers would fall on its back. In an WebRTC to WebRTC case, interoperability would be achieved. However, if you talk about legacy interoperability (across a gateway) you want to avoid having to basically insert a jitter buffer and reconstitute the RTP payloads into something that that system supports. That is why I suggest that certain common sizes an WebRTC implementation MUST be capable of producing. > > Of course, I do have a question, now that all the ptime and maxtime > definitions have been put on the table: > > Is it true that ptime and maxptime only specify the SDP sender's > declaration of his desires for incoming packet streams? That is, that > there is nowhere specified what the sender intends to send? I think that > is true for ptime in RFC 3264 offer/answer, and would assume that the > same is true for maxptime. Yes, there are no attribute for its intended send direction unless the m= block is a sendonly/recvonly O/A exchange where the sendonly direction can kind of indicate it is preference for what it want/will send. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Feb 19 00:19: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 E4E9D1A043C for ; Wed, 19 Feb 2014 00:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.981, 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 TaBWMsK5ss43 for ; Wed, 19 Feb 2014 00:19:06 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1801A0080 for ; Wed, 19 Feb 2014 00:19:05 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-b1-530468f58a8c Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 28.3F.10875.5F864035; Wed, 19 Feb 2014 09:19:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Wed, 19 Feb 2014 09:19:01 +0100 From: Christer Holmberg To: 'Harald Alvestrand' , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Stream control: [MMUSIC] msid-04 submitted Thread-Index: AQHPKVPuF/VJzX0Fb0yVt/Xv3TzOfJq0+6GAgAAXm1SABo2kgIAAovSR Date: Wed, 19 Feb 2014 08:19:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1A9B80@ESESSMB209.ericsson.se> References: <52FDC17E.8070708@alvestrand.no>,<52FE5B37.80409@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1735EE@ESESSMB209.ericsson.se>, <5303EE53.1010405@alvestrand.no> In-Reply-To: <5303EE53.1010405@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1A9B80ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvje7XDJZgg3PvVS2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGU8+PeeuWCaRsXzz8eZGxgblLsYOTkkBEwk ZrxrZYGwxSQu3FvP1sXIxSEkcIhRYtXRmewQzhJGiUOz7jB1MXJwsAlYSHT/0wYxRQRCJRat 1AbpFRZwkLh3aCoziC0i4CgxZ+tyJgjbTWLKiZdgcRYBVYktC/vB4rwCvhKflu9hgRi/gVHi 5bqtbCAJTgFdiY7/x8AaGIEO+n5qDVgDs4C4xK0n85kgDhWQWLLnPDOELSrx8vE/VoiafInl qxpZIBYISpyc+YRlAqPwLCTts5CUzUJSBhE3kPjy/jaUrS2xbOFrZghbX6L7/WkmZPEFjOyr GNlzEzNz0ssNNzECY+Tglt+6OxhPnRM5xCjNwaIkzvvhrXOQkEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBsYpdxvOK8R5LDiyUKOxqmDRqv68LXzP2R6pxR2YxxDfNSHX1jlkYs6ee5ujQroS r3KLbbLe9af/1RoBlw3HHSzyusW8sgMrijQFbvFnNRswqa9Xr6hQ2ZQyqS7yf3/AJIma7OrH OtfbOf98uSBZqT9Nw1b1wZmkCckt/77O55LO59I2Kju2Q4mlOCPRUIu5qDgRALbkehRfAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JD_hlS3PjAvsSC94ZVcT87kCOWk Subject: Re: [rtcweb] Stream control: [MMUSIC] msid-04 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 19 Feb 2014 08:19:08 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1A9B80ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, If the indication is =93permanent=94, rather than using a new msid-control = attribute, could it be indicated by NOT including some information in the A= nswer? Regards, Christer Sent from Windows Mail From: 'Harald Alvestrand' Sent: =FDWednesday=FD, =FDFebruary=FD =FD19=FD, =FD2014 =FD1=FD:=FD35=FD = =FDAM To: Hans-Christer Holmberg, rtcweb@i= etf.org One thing I did not add in my previous reply: If an offerer sets the direction of an m-line to sendrecv, and the answerer sets the direction to sendonly, the offerer will have no indication of whether the answerer intended the suspension of traffic to be temporary (msid-control: disable) or permanent (msid-control: reject or msid-control: stop). That was actually the main concern that drove the desire for a new mechanism. Once the new mechanism was in place, it seemed logical to be explicit about the other possible actions too, rather than relying on the sendrecv/sendonly/recvonly parameter. Harald --_000_7594FB04B1934943A5C02806D1A2204B1D1A9B80ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

If the indication is =93permanent=94, rather than using a new msi= d-control attribute, could it be indicated by NOT including some informatio= n in the Answer?

Regards,

Christer

Sent from Windows Mail

From: 'Harald Alvestrand'
Sent: =FDWednesday=FD, =FDFebruary=FD =FD19=FD, =FD2014 =FD1=FD= :=FD35=FD =FDAM
To: Hans-Christer Holmberg, rtcweb@ietf.org

One thing I did not add in my previous r= eply:

If an offerer sets the direction of an m-line to sendrecv, and the
answerer sets the direction to sendonly, the offerer will have no
indication of whether the answerer intended the suspension of traffic to be temporary (msid-control: disable) or permanent (msid-control: reject
or msid-control: stop).

That was actually the main concern that drove the desire for a new
mechanism.
Once the new mechanism was in place, it seemed logical to be explicit
about the other possible actions too, rather than relying on the
sendrecv/sendonly/recvonly parameter.

          Harald

--_000_7594FB04B1934943A5C02806D1A2204B1D1A9B80ESESSMB209erics_-- From nobody Wed Feb 19 01:13: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 B49DB1A0396 for ; Wed, 19 Feb 2014 01:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.074 X-Spam-Level: X-Spam-Status: No, score=0.074 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 k8n1xxPuDBRt for ; Wed, 19 Feb 2014 01:13:07 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 33C851A037C for ; Wed, 19 Feb 2014 01:13:06 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee25304751496f-6f96f; Wed, 19 Feb 2014 17:10:45 +0800 (CST) X-RM-TRANSID: 2ee25304751496f-6f96f Received: from [10.2.54.51] (unknown[10.2.54.51]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee2530475146b8-0c303; Wed, 19 Feb 2014 17:10:45 +0800 (CST) X-RM-TRANSID: 2ee2530475146b8-0c303 From: =?utf-8?B?6b2Q5pe76bmP?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Feb 2014 17:14:45 +0800 Message-Id: <9BD45388-7675-4165-82D7-ED4BE518BDED@chinamobile.com> To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bY7VYGzNEykSBRLaG5loyUdXxqM Subject: [rtcweb] New Version Notification for draft-cheng-rtcweb-teleauth-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, 19 Feb 2014 09:13:14 -0000 Dear all, We have submit a draft about authentication for WebRTC telephony = terminal use-case.=20 Your attention and comments are welcome. A new version of I-D, draft-cheng-rtcweb-teleauth-00.txt has been successfully submitted by Minpeng Qi and posted to the IETF repository. Name: draft-cheng-rtcweb-teleauth Revision: 00 Title: Security Authentication of WebRTC Communication Service = for Telephony Terminal Document date: 2014-02-08 Group: Individual Submission Pages: 12 URL: = http://www.ietf.org/id/draft-cheng-rtcweb-teleauth-00.txt Status: = https://datatracker.ietf.org/doc/draft-cheng-rtcweb-teleauth Htmlized: = http://tools.ietf.org/html/draft-cheng-rtcweb-teleauth-00 Abstract The WebRTC use-cases and related requirements are defined in [draft-ietf-rtcweb-use-cases-and-requirements] that contains browser = to browser use-cases and browser-GW/server use-cases (e.g., telephony terminal). In the use-case of telephony terminal, it is necessary for telephony terminal to be able to attest his identity to the telephony operator. Unlike the current authentication specified in [draft-ietf-rtcweb-security] such as PKI based authentication and web based peer authentication WebRTC communication is directly controlled by the telephony operator, which poses new authentication methods, including re-using existence authentication mechanism of telephony operator and authentication by using web credentials. This document presents the security authentication of WebRTC communication for telephony terminal. BRs, Minpeng= From nobody Wed Feb 19 02:08: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 C0F511A00BF for ; Wed, 19 Feb 2014 02:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 OhOsP9uqILzi for ; Wed, 19 Feb 2014 02:08:37 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 52E591A00B1 for ; Wed, 19 Feb 2014 02:08:36 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-ba-5304829feaff Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 23.5E.04853.F9284035; Wed, 19 Feb 2014 11:08:32 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.2.347.0; Wed, 19 Feb 2014 11:08:31 +0100 Message-ID: <5304829E.20809@ericsson.com> Date: Wed, 19 Feb 2014 11:08:30 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" , Harald Alvestrand X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDJMWRmVeSWpSXmKPExsUyM+Jvje6CJpZgg/e/xCxO3DjNbLH2Xzu7 A5PHgk2lHkuW/GQKYIrisklJzcksSy3St0vgyrhy8xtLwS6zis5Xn1gbGLdqdzFyckgImEhM nPuSEcIWk7hwbz1bFyMXh5DACUaJjt7bzBDOckaJZ887WbsYOTh4BTQlTrXIgTSwCKhKXG+d zwJiswlYSNz80cgGYosKBEvsPPAbbCivgKDEyZlPwGpEBLwlZi89yQ5iCwMt3rBlDhvISAkB cYmexiCQMLOAnsSUqy2MELa8RPPW2cwgtpCAtkRDUwfrBEb+WUimzkLSMgtJywJG5lWMksWp xcW56UYGernpuSV6qUWZycXF+Xl6xambGIEheHDLb6MdjCf32B9ilOZgURLnvc5aEyQkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qBUdum5KuUFdv0nFt57dPzP+20PGLbq/Ph1DOjc0udXzws dL3kYmBWXCVvV3HZYNf/9dXfRd8cuj+l6eZln6lTmNceuhm7fvGnb3MeHbqvvj1M3/finzkH LuV+vGPo0H59goqb1d3uIgm7tHdh134ncWa9yWZcfbyvZrV2klBSmVSwxMFS/dWGCkosxRmJ hlrMRcWJAKe32ccPAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8_cQ4PEsdfYHqcn3Cg4yAhuU8_I Subject: [rtcweb] Comments on draft-ietf-rtcweb-transports-02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 19 Feb 2014 10:08:38 -0000 Hi, I have reviewed the Transports for RTCWEB (draft-ietf-rtcweb-transports-02) and have the following comments. 1. Section 1. This document focuses on the data transport protocos that are used by conforming implementations. Missing "l" in protocos. 2. Section 3.1: For both protocols, IPv4 and IPv6 support is assumed; applications MUST be able to utilize both IPv4 and IPv6 where available. What "applications" are intended in this sentence. I get a feeling that "applications" here could be replaced by "WebRTC implementations" 3. Section 3.1: For UDP, this specification assumes the ability to set the DSCP code point of the sockets opened on a per-packet basis, in order to achieve the prioritizations described in [I-D.dhesikan-tsvwg-rtcweb-qos] when multiple media types are multiplexed. It does not assume that the DSCP codepoints will be honored, and does assume that they may be zeroed or changed, since this is a local configuration issue. I wonder if this should be moved into 3.2 section instead. At least the part in 3.1 should focus on the DSCP setting part on the transport flow. The implications of it working or not should be moved to 3.2. A forward pointer to that second can be used instead. 4. Order of Section 3.2 and 3.3. I think the order should be swapped between 3.2. and 3.3. That way the Multiplexing section can provide definitions of all the stream concepts that exists in WebRTC and how they can be combined. More about this later. 5. Content of Section 3.2 This section needs to be expanded to start with a general discussion of how QoS can be applied to get a benefit. But, I think one need to be clear that it can't be assumed to be available in implementations or WebRTC based applications. It needs to also discuss flow-based QoS mechanism. What are the implications if that is what is available and what choices does one have to address this by configuring the multiplexing different. I think this is the logical place to take the main discussion of that, as it can address both RTP streams and the data channel together. Please consider pointers to appropriate discussion in Section 12.1.3 in draft-ietf-rtcweb-rtp-usage. I do note that writing this section appropriately is difficult until the content of draft-dhesikan-tsvwg-rtcweb-qos has firmed up. 6. Content of Section 3.3: I think this section should focus on making clear what different types of streams that exist in the WebRTC context, and what choices of multiplexing that are possible. Basically ensure that the full set of combinations are made clear. A. All RTP packet streams and data channel over a single UDP flow. B. All RTP packet streams over one UDP flow and the data channel over another UDP flow. C. The RTP packet streams over different UDP flows based on content type and separate data channel. D. Each RTP packet stream over its own UDP flow (RTP session) and the data channel over its own UDP flow. The above with the additional dimension, that each RTP sessions, RTCP can be in its own UDP flow. There is also a question if the data channel can be aggregated with only one RTP session, where there are multiple ones configured. The QoS related discussion of this can be moved to the QoS section to keep that focused. However, the discussion of the pro and cons with having one or more flow is good and could even be expanded to list reasons such as legacy interop over a gateway. 7. Section 3.3: RTCWEB implementations MUST support the ability to send and receive multiple SSRCs on the same transport, and MUST support the ability to send and receive multiple SSRCs on multiple simultaneous transports, including the ability to send and receive audio and video on the same transport. I think this sentence is restating what is already required by Section 4.1 in draft-ietf-rtcweb-rtp-usage: If you want to enforce this, I suggest to do that by reference to that text rather than using RFC 2119 normative statements. 8. Section 3.4: ICE [RFC5245] MUST be supported. The implementation MUST be a full ICE implementation, not ICE-Lite. In order to deal with situations where both parties are behind NATs which perform endpoint-dependent mapping (as defined in [RFC5128] section 2.4), TURN [RFC5766] MUST be supported. These paragraph implies STUN and TURN server configuration. Should that configuration question be discussed with the appropriate pointers to the API? 9. Section 3.4: In order to deal with firewalls that block all UDP traffic, TURN using TCP between the client and the server MUST be supported, and TURN using TLS between the client and the server MUST be supported. See [RFC5766] section 2.1 for details. I think the following part: "TURN using TLS between" should be changed over "TURN using TLS over TCP between" to make it clear that this is using TLS/TCP rather than TLS/FOO. 10. Section 3.4: TURN TCP candidates [RFC6062] SHOULD be supported; this allows applications to achieve peer-to-peer communication when both parties are behind UDP-blocking firewalls using a single TURN server. (In this case, one can also achieve communication using two TURN servers that use TCP between the server and the client, and UDP between the TURN servers.) My understanding of RFC6062 is that it allows one to establish a vanilla TCP connection on the far side of the TURN server as well as connecting that one to an almost vanilla TCP connection (just a initial TURN ConnectionBind request) that A establish to the TURN server, i.e. WebRTC-A -(Turn/TCP)-> TURN_Server -(TCP)-> WebRTC-B. The end-result is that a relayed vanilla TCP connection is established between the WebRTC endpoints (A and B). As the WebRTC transport so far defined only works with datagrams, i.e. DTLS or RTP/RTCP packets they can't be sent natively over a TCP byte stream. Thus, if this mode of operation is to be supported a framing is required on this leg. A possibility here could be RFC 4571 if one want to go this way. 11. Section 3.4: ICE-TCP candidates [RFC6544] MAY be supported; this may allow applications to communicate to peers with public IP addresses across UDP-blocking firewalls without using a TURN server. Also this option would need to use a framing of the datagrams. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Feb 19 03:07: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 4F0911A0584 for ; Wed, 19 Feb 2014 03:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 gzERDBltxdPs for ; Wed, 19 Feb 2014 03:07:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 923251A0466 for ; Wed, 19 Feb 2014 03:07:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBH14002; Wed, 19 Feb 2014 11:07:48 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Feb 2014 11:07:36 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Feb 2014 11:07:46 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 19 Feb 2014 19:07:38 +0800 From: "Lijing (Jessie)" To: "rtcweb@ietf.org" Thread-Topic: Comments on data channel related drafts Thread-Index: AQHPLWLMOA6HXUQ9mEaoGulYw8fFAw== Date: Wed, 19 Feb 2014 11:07:38 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.171.171] Content-Type: multipart/alternative; boundary="_000_A3045C90BB645147BC99159AA47ABAC7495EAD61SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ywEoujH5_np-2goUvcTUGhCoc24 Subject: [rtcweb] Comments on data channel related 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: Wed, 19 Feb 2014 11:07:56 -0000 --_000_A3045C90BB645147BC99159AA47ABAC7495EAD61SZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Several comments on data channel related drafts. Firstly, There are several "protocol" concepts appeared in different data c= hannel related drafts, and it seems there is no clear statement about the r= elationship between these concepts. draft-ietf-rtcweb-data-protocol has two protocol concept: 1. The protocol byte in data channel open message defined as the protocol = for the channel. 2. SCTP payload protocol identifier (PPID) WebRTC W3C API has one protocol concept, 3. Protocol defined as "Subprotocol name used for this channel" Q1: is the W3C API parameter "protocol" be the same as the protocol byte in= the data channel open message? In previous email discussion, Peter Thatcher said : "The PPID isn't exposed to the application. It's just used to distinguish text/binary/control. If an application uses different data channels with different protocols, it should use the SID to distinguis= h between them, not the PPID. In fact, even if it wanted to use the PPID, = it wouldn't be able to." Q2: if the answer of Q1 is yes. Then an application can distinguish differe= nt data channels with different protocols by the protocol byte in the data = channel open message. Is my understanding right? draft-ejzak-mmusic-data-channel-sdpneg provides a way to negotiate sub-prot= ocol parameters out of band. 4. Sub-protocol: The 'sub-protocol' parameter indicates which protocol the= client expects to exchange via the channel. example: a=3Ddcmap:5000 stream=3D2;label=3D"channel 2"; subprotocol=3D"BFCP= ";max_retr=3D3 Q3: is this "subprotocol" be the same concept as the protocol byte in the d= ata channel open message? And the W3C API "protocol" should be set as BFCP? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Secondly, in draft-ietf-rtcweb-data-channel-07, section 8 defines the follo= wing PPIDs +------------------------------------+-----------+-----------+ | Value | SCTP PPID | Reference | +------------------------------------+-----------+-----------+ | WebRTC String | 51 | [RFCXXXX] | | WebRTC Binary Partial (Deprecated) | 52 | [RFCXXXX] | | WebRTC Binary | 53 | [RFCXXXX] | | WebRTC String Partial (Deprecated) | 54 | [RFCXXXX] | +------------------------------------+-----------+-----------+ Q4: It is confusing what is the intention to define "WebRTC Binary Partial"= and "WebRTC String Partial". I guess these two PPIDs are provided to the a= pplication in the case when application supports fragmentation of large mes= sages. But, at the meantime, in this draft, section 6.6 also says: The usag= e of the PPIDs "WebRTC String Partial" and "WebRTC Binary Partial" is depre= cated. Why the usage is deprecated? Does this implies that SCTP layer is re= sponsible for fragmentation of large messages, and it is unnecessary for th= e upper application to implement the fragmentation of large messages? Q5: Since PPID 52 and 54 are defined, then how can the browser know whether= the data sent from the upper application layer is a part of a whole messag= e and the SCTP PPID should be signaled as Partial 52/54, or this is a whole= message and should be signaled as 51/54? Q6: if one side wants to send two messages, and the application split the f= irst big message to two packages, then the browser will send three SCTP pac= kages whose PPID are 54(part of first message), 51(part of first message), = 51(the whole second message) respectively. When the receiver side receives = these three SCTP packages, how can the receiver side know which two SCTP pa= ckages can be assembled to get the first big message? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The last question, which I have asked in previous email and have not receiv= ed any response until now, so I mention this question again. in draft-ietf-rtcweb-data-channel-07, Section 4 says: Req. 4: The application SHOULD be able to provide guidance as to the relative priority of each data channel relative to each other, and relative to the media streams. This will interact with the congestion control algorithms. And in draft-ietf-rtcweb-data-protocol-03, DATA_CHANNEL_OPEN Message is def= ined as below 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Channel Type | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reliability Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Length | Protocol Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ / | Label | / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ / | Protocol | / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Priority: 2 bytes (integer) The priority of the channel as described in [I-D.ietf-rtcweb-data-channel]. The higher the number, the lower the priority. Q7: It seems that for now there is no W3C API parameters to set the priorit= y of data channel. I wonder whether the priority of the data channel is ope= n to the application or is only decided by the browser. In other words, I w= ant to know how the application be able to provide guidance as to the prior= ity. Best Regards, Jessie --_000_A3045C90BB645147BC99159AA47ABAC7495EAD61SZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Several comments on data channe= l related drafts.

 

Firstly, There are several R= 20;protocol” concepts appeared in different data channel related draf= ts, and it seems there is no clear statement about the relationship between= these concepts.

 

draft-ietf-rtcweb-data-protocol has two protocol concept:

1= .  The protocol byte in da= ta channel open message defined as the protocol for the channel.=

2= .  SCTP payload protocol i= dentifier (PPID)

=  

WebRTC W3C API has one protocol= concept,

3= .  Protocol defined as = 220;Subprotocol name used for this channel”

=  

Q1: is the W3C API parameter “protocol” be the same = as the protocol byte in the data channel open message?

 

&n= bsp;

In previous email discussion, P= eter Thatcher said :

R= 20;The PPID isn't exposed to the application.&n= bsp; It's just used to

distinguish text/binary/cont= rol.    If an application uses different

data channels with different= protocols, it should use the SID to distinguish between them, not the PPID= .  In fact, even if it wanted to use the PPID, it wouldn't be able to.= ”

 

Q2: if the answer of Q1 is y= es. Then an application can distinguish different data channels with differ= ent protocols by the protocol byte in the data channel open message. Is my = understanding right?

 

draft-ejzak-mmusic-data-channel= -sdpneg provides a way to negotiate sub-protocol parameters out of band.

4= .  Sub-protocol: The 'sub-= protocol' parameter indicates which protocol the client expects to exchange= via the channel. 

example: a=3Ddcmap:5000 stream=3D2;label=3D"chann= el 2"; subprotocol=3D"BFCP";max_retr=3D3

 

Q3: is this “subprotocol” be the = same concept as the protocol byte in the data channel open message? And the= W3C API “protocol” should be set as BFCP?

 

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

 

Secondly, in draft-ietf-rtcweb-= data-channel-07, section 8 defines the following PPIDs

      +---------= ---------------------------+-----------+-----------+=

      | Value &= nbsp;           &nbs= p;            &= nbsp;   | SCTP PPID | Reference |

      +---------= ---------------------------+-----------+-----------+=

      | WebRTC Strin= g            &n= bsp;         | 51    = ;    | [RFCXXXX] |

      | WebRTC Binar= y Partial (Deprecated) | 52        | [RF= CXXXX] |

      | WebRTC Binar= y            &n= bsp;         | 53   =      | [RFCXXXX] |

      | WebRTC Strin= g Partial (Deprecated) | 54        | [RF= CXXXX] |

      +------------------------------------+-----------+= -----------+

&n= bsp;

Q4: It is confusing what is the= intention to define “WebRTC Binary Partial” and “WebRTC = String Partial”. I guess these two PPIDs are provided to the applicat= ion in the case when application supports fragmentation of large messages. But, at the meantime, in this draft, section 6.6 also says: The = usage of the PPIDs "WebRTC String Partial" and "WebRTC Binar= y Partial" is deprecated. Why the usage is deprecated? Does this impli= es that SCTP layer is responsible for fragmentation of large messages, and it is unnecessary for the upper application to impl= ement the fragmentation of large messages?

&n= bsp;

Q5: Since PPID 52 and 54 are de= fined, then how can the browser know whether the data sent from the upper a= pplication layer is a part of a whole message and the SCTP PPID should be s= ignaled as Partial 52/54, or this is a whole message and should be signaled as 51/54?

 

Q6: if one side wants to send t= wo messages, and the application split the first big message to two package= s, then the browser will send three SCTP packages whose PPID are 54(part of= first message), 51(part of first message), 51(the whole second message) respectively. When the receiver side receives= these three SCTP packages, how can the receiver side know which two SCTP p= ackages can be assembled to get the first big message?

 

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

 

The last question, which I have= asked in previous email and have not received any response until now, so I= mention this question again.

in draft-ietf-rtcweb-data-ch= annel-07, Section 4 says:

   Req. 4: &n= bsp; The application SHOULD be able to provide guidance as to

    &nbs= p;        the relative priority of each = data channel relative to each

    &nbs= p;        other, and relative to the med= ia streams.  This will

    &nbs= p;        interact with the congestion c= ontrol algorithms.

 

And in draft-ietf-rtcweb-dat= a-protocol-03, DATA_CHANNEL_OPEN Message is defined as below

0       &n= bsp;           1 &nb= sp;            =      2        &= nbsp;          3

    0 1 2 3 4 5 6 7 8 9 0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

   |  Message Type |  Cha= nnel Type |          &nbs= p; Priority           |

   +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

   |     &= nbsp;           &nbs= p;  Reliability Parameter       &nb= sp;            =   |

   +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

   |     &= nbsp;   Label Length       &nb= sp;  |       Protocol Length  =        |

   +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

   \     &= nbsp;            &nb= sp;            =             &nb= sp;            =        /

   |     &= nbsp;           &nbs= p;           Label &= nbsp;           &nbs= p;            &= nbsp;  |

   /     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       \

   +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

   \     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       /

   |     &= nbsp;           &nbs= p;          Protocol &nbs= p;            &= nbsp;            |

   /     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       \

   +-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+

Priority: 2 bytes (integer)=

      The priority of the channel as described in

      [I-D.ietf-rtcweb-data-channel].  The higher the number, the low= er

      the priority.

 

Q7: It seems that for now th= ere is no W3C API parameters to set the priority of data channel. I wonder = whether the priority of the data channel is open to the application or is o= nly decided by the browser. In other words, I want to know how the application be able to provide guidance as t= o the priority.

 

Best Regards,

 

Jessie

 

--_000_A3045C90BB645147BC99159AA47ABAC7495EAD61SZXEMA510MBXchi_-- From nobody Wed Feb 19 10:12: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 0B57D1A00B8 for ; Wed, 19 Feb 2014 10:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 cP76utX-1JRC for ; Wed, 19 Feb 2014 10:11:51 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id CF9271A01FB for ; Wed, 19 Feb 2014 10:11:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 1C4EE7C4E7F; Wed, 19 Feb 2014 19:11:47 +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 xdc4+I2GLsVA; Wed, 19 Feb 2014 19:11:46 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id E88407C4E63; Wed, 19 Feb 2014 19:11:45 +0100 (CET) Message-ID: <5304F3E0.1020206@alvestrand.no> Date: Wed, 19 Feb 2014 19:11:44 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Magnus Westerlund , rtcweb@ietf.org References: <530320F7.4090300@ericsson.com> <5303E578.3000207@alvestrand.no> <53046842.2010108@ericsson.com> In-Reply-To: <53046842.2010108@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PGEVRnB0M_LkOHzbaMaewynrrtQ Subject: Re: [rtcweb] Number of samples (ptime) to be supported by required codecs (draft-ietf-rtcweb-audio-05) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 19 Feb 2014 18:11:58 -0000 On 02/19/2014 09:16 AM, Magnus Westerlund wrote: > On 2014-02-18 23:58, Harald Alvestrand wrote: >> I may be a little simple-minded, but if we have a recommendation that >> receivers MUST be able to receive all packetizations of G.711 and OPUS >> up to 200 ms per packet, and that receivers should signal this by >> sending "a=maxptime:200" in their SDP, what situations exist where >> interoperability is not going to be achieved? > Interoperability is going to be achieve in the direction towards this > endpoint. The question is if we achieve interoperability in the > direction from that endpoint. So, given that there is nothing in the G.711 specification about which sample sizes a G.711 receiver has to support - the right approach seems to be to amend the G.711 MIME registration with this information. This is not a WebRTC issue; it is an absence of specification for the non-WebRTC devices that use G.711. The RTCWEB specifications can reasonably be expected to point to existing information about this issue; it is not reasonable (in my mind) that the RTCWEB WG decide what these values should be. -- Surveillance is pervasive. Go Dark. From nobody Wed Feb 19 10:12: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 4A4141A01FB for ; Wed, 19 Feb 2014 10:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] 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 gtvBqklhSzI7 for ; Wed, 19 Feb 2014 10:12:41 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 697FB1A00B8 for ; Wed, 19 Feb 2014 10:12:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C38847C4E7E; Wed, 19 Feb 2014 19:12:37 +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 axJHRHL5QWfQ; Wed, 19 Feb 2014 19:12:37 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id B8B817C4E63; Wed, 19 Feb 2014 19:12:36 +0100 (CET) Message-ID: <5304F413.1080208@alvestrand.no> Date: Wed, 19 Feb 2014 19:12:35 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Christer Holmberg , "rtcweb@ietf.org" References: <52FDC17E.8070708@alvestrand.no>, <52FE5B37.80409@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1735EE@ESESSMB209.ericsson.se>, <5303EE53.1010405@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1A9B80@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1A9B80@ESESSMB209.ericsson.se> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------040605080800050804080900" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/C7xifZ2d6YYq6sP5hxCSjUkdhz8 Subject: Re: [rtcweb] Stream control: [MMUSIC] msid-04 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 19 Feb 2014 18:12:43 -0000 This is a multi-part message in MIME format. --------------040605080800050804080900 Content-Type: text/plain; charset=windows-1256 Content-Transfer-Encoding: 8bit On 02/19/2014 09:19 AM, Christer Holmberg wrote: > Hi, > > If the indication is “permanent”, rather than using a new msid-control > attribute, could it be indicated by NOT including some information in > the Answer? Certainly, but then you have to include some information in the answer when the indication is not permanent. Which information were you thinking of utilizing as a signal? > > Regards, > > Christer > > Sent from Windows Mail > > *From:* 'Harald Alvestrand' > *Sent:* ýWednesdayý, ýFebruaryý ý19ý, ý2014 ý1ý:ý35ý ýAM > *To:* Hans-Christer Holmberg , > rtcweb@ietf.org > > One thing I did not add in my previous reply: > > If an offerer sets the direction of an m-line to sendrecv, and the > answerer sets the direction to sendonly, the offerer will have no > indication of whether the answerer intended the suspension of traffic to > be temporary (msid-control: disable) or permanent (msid-control: reject > or msid-control: stop). > > That was actually the main concern that drove the desire for a new > mechanism. > Once the new mechanism was in place, it seemed logical to be explicit > about the other possible actions too, rather than relying on the > sendrecv/sendonly/recvonly parameter. > > Harald > -- Surveillance is pervasive. Go Dark. --------------040605080800050804080900 Content-Type: text/html; charset=windows-1256 Content-Transfer-Encoding: 8bit
On 02/19/2014 09:19 AM, Christer Holmberg wrote:
Hi,

If the indication is “permanent”, rather than using a new msid-control attribute, could it be indicated by NOT including some information in the Answer?

Certainly, but then you have to include some information in the answer when the indication is not permanent.

Which information were you thinking of utilizing as a signal?



Regards,

Christer

Sent from Windows Mail

From: 'Harald Alvestrand'
Sent: ýWednesdayý, ýFebruaryý ý19ý, ý2014 ý1ý:ý35ý ýAM
To: Hans-Christer Holmberg, rtcweb@ietf.org

One thing I did not add in my previous reply:

If an offerer sets the direction of an m-line to sendrecv, and the
answerer sets the direction to sendonly, the offerer will have no
indication of whether the answerer intended the suspension of traffic to
be temporary (msid-control: disable) or permanent (msid-control: reject
or msid-control: stop).

That was actually the main concern that drove the desire for a new
mechanism.
Once the new mechanism was in place, it seemed logical to be explicit
about the other possible actions too, rather than relying on the
sendrecv/sendonly/recvonly parameter.

          Harald



-- 
Surveillance is pervasive. Go Dark.
--------------040605080800050804080900-- From nobody Wed Feb 19 10:47: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 A53E01A022E for ; Wed, 19 Feb 2014 10:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] 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 L_xNvSQDc-BQ for ; Wed, 19 Feb 2014 10:47:11 -0800 (PST) Received: from mork.alvestrand.no (unknown [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 11EAB1A015E for ; Wed, 19 Feb 2014 10:47:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 61D377C4E81; Wed, 19 Feb 2014 19:47:07 +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 AtFs9wqXjyEx; Wed, 19 Feb 2014 19:47:05 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id EE65B7C4E43; Wed, 19 Feb 2014 19:47:04 +0100 (CET) Message-ID: <5304FC27.807@alvestrand.no> Date: Wed, 19 Feb 2014 19:47:03 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Magnus Westerlund , "rtcweb@ietf.org" , Harald Alvestrand References: <5304829E.20809@ericsson.com> In-Reply-To: <5304829E.20809@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XoR5dJZIvt88U95PXFsZwa50qow Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 19 Feb 2014 18:47:13 -0000 On 02/19/2014 11:08 AM, Magnus Westerlund wrote: > Hi, > > I have reviewed the Transports for RTCWEB > (draft-ietf-rtcweb-transports-02) Thanks! > and have the following comments. > > 1. Section 1. > > This document focuses on the data > transport protocos that are used by conforming implementations. > > Missing "l" in protocos. Fixed. > > 2. Section 3.1: > For both protocols, IPv4 and IPv6 support is assumed; applications > MUST be able to utilize both IPv4 and IPv6 where available. > > What "applications" are intended in this sentence. I get a feeling that > "applications" here could be replaced by "WebRTC implementations" Javascript applications. I think I should add the word "application" to -overview's vocabulary; it is actually used in that meaning in that document (also in the forms "Web application" and "browser-based application". > > > 3. Section 3.1: > For UDP, this specification assumes the ability to set the DSCP code > point of the sockets opened on a per-packet basis, in order to > achieve the prioritizations described in > [I-D.dhesikan-tsvwg-rtcweb-qos] when multiple media types are > multiplexed. It does not assume that the DSCP codepoints will be > honored, and does assume that they may be zeroed or changed, since > this is a local configuration issue. > > I wonder if this should be moved into 3.2 section instead. At least the > part in 3.1 should focus on the DSCP setting part on the transport flow. > The implications of it working or not should be moved to 3.2. A forward > pointer to that second can be used instead. I think it fits better in 3.1 - this is about the assumptions that the specifcation makes about the parts of the system that it is not a specification for. > > 4. Order of Section 3.2 and 3.3. > > I think the order should be swapped between 3.2. and 3.3. That way the > Multiplexing section can provide definitions of all the stream concepts > that exists in WebRTC and how they can be combined. More about this later. > > 5. Content of Section 3.2 > > This section needs to be expanded to start with a general discussion of > how QoS can be applied to get a benefit. But, I think one need to be > clear that it can't be assumed to be available in implementations or > WebRTC based applications. I want to push back on this. It seems inappropriate that the RTCWEB QoS specification start off with a tutorial on what QoS is and how one can use it to gain a benefit. That material should be available elsewhere. (Recommendations?) > > It needs to also discuss flow-based QoS mechanism. What are the > implications if that is what is available and what choices does one have > to address this by configuring the multiplexing different. I do not want to discuss material for which there are no references. What particular flow-based mechanisms do you have in mind, and what are the relevant references? > I think this > is the logical place to take the main discussion of that, as it can > address both RTP streams and the data channel together. Please consider > pointers to appropriate discussion in Section 12.1.3 in > draft-ietf-rtcweb-rtp-usage. I do not think this document should repeat any material from rtp-usage, but rtp-usage does not consider any aspect of QoS marking for multiple streams using the same 5-tuple, nor does it say anything about flow-based or DPI-based mechanisms apart from noting their existence. Agree that the multiplexing aspect should be discussed somewhere, but I'm not sure where. > > I do note that writing this section appropriately is difficult until the > content of draft-dhesikan-tsvwg-rtcweb-qos has firmed up. True. > > 6. Content of Section 3.3: > > I think this section should focus on making clear what different types > of streams that exist in the WebRTC context, and what choices of > multiplexing that are possible. Basically ensure that the full set of > combinations are made clear. Isn't this material that really should be in draft-ietf-avtcore-rtp-multi-stream or draft-ietf-avtcore-multiplex-guidelines? Again, this seems the wrong draft for having a discussion of those issues. > > A. All RTP packet streams and data channel over a single UDP flow. > > B. All RTP packet streams over one UDP flow and the data channel over > another UDP flow. > > C. The RTP packet streams over different UDP flows based on content type > and separate data channel. > > D. Each RTP packet stream over its own UDP flow (RTP session) and the > data channel over its own UDP flow. > > The above with the additional dimension, that each RTP sessions, RTCP > can be in its own UDP flow. > > There is also a question if the data channel can be aggregated with only > one RTP session, where there are multiple ones configured. > > The QoS related discussion of this can be moved to the QoS section to > keep that focused. > > However, the discussion of the pro and cons with having one or more flow > is good and could even be expanded to list reasons such as legacy > interop over a gateway. > > 7. Section 3.3: > RTCWEB implementations MUST support the ability to send and receive > multiple SSRCs on the same transport, and MUST support the ability to > send and receive multiple SSRCs on multiple simultaneous transports, > including the ability to send and receive audio and video on the same > transport. > > I think this sentence is restating what is already required by Section > 4.1 in draft-ietf-rtcweb-rtp-usage: If you want to enforce this, I > suggest to do that by reference to that text rather than using RFC 2119 > normative statements. Yes, rtp-usage contains these requirements. I can delete it from here. Thanks! However, this removes the handle on which I hung the discussion of why one would want to multiplex or not, which I inserted because you requested it. This discussion also seems to be present in rtp-usage, so it seems appropriate to delete that too. > > > 8. Section 3.4: > ICE [RFC5245] MUST be supported. The implementation MUST be a full > ICE implementation, not ICE-Lite. > > In order to deal with situations where both parties are behind NATs > which perform endpoint-dependent mapping (as defined in [RFC5128] > section 2.4), TURN [RFC5766] MUST be supported. > > These paragraph implies STUN and TURN server configuration. Should that > configuration question be discussed with the appropriate pointers to the > API? This document has no pointers to the API at the moment, and I do not want to add them - it's a layering violation of sorts. We can add pointers to JSEP, which is kind of close to the API. But the main point seems to be that STUN and TURN servers MUST be configurable, both from the browser setup and from the (JS) application. I'm adding a sentence saying that. > > 9. Section 3.4: > In order to deal with firewalls that block all UDP traffic, TURN > using TCP between the client and the server MUST be supported, and > TURN using TLS between the client and the server MUST be supported. > See [RFC5766] section 2.1 for details. > > I think the following part: "TURN using TLS between" should be changed > over "TURN using TLS over TCP between" to make it clear that this is > using TLS/TCP rather than TLS/FOO. Done. > > 10. Section 3.4: > TURN TCP candidates [RFC6062] SHOULD be supported; this allows > applications to achieve peer-to-peer communication when both parties > are behind UDP-blocking firewalls using a single TURN server. (In > this case, one can also achieve communication using two TURN servers > that use TCP between the server and the client, and UDP between the > TURN servers.) > > My understanding of RFC6062 is that it allows one to establish a vanilla > TCP connection on the far side of the TURN server as well as connecting > that one to an almost vanilla TCP connection (just a initial TURN > ConnectionBind request) that A establish to the TURN server, i.e. > WebRTC-A -(Turn/TCP)-> TURN_Server -(TCP)-> WebRTC-B. > > The end-result is that a relayed vanilla TCP connection is established > between the WebRTC endpoints (A and B). As the WebRTC transport so far > defined only works with datagrams, i.e. DTLS or RTP/RTCP packets they > can't be sent natively over a TCP byte stream. Thus, if this mode of > operation is to be supported a framing is required on this leg. > > A possibility here could be RFC 4571 if one want to go this way. I added a 4571 reference, and a note saying this is up for discussion. If we frame RTP over TCP, we also have to decide what we do about the SCTP. > > 11. Section 3.4: > > ICE-TCP candidates [RFC6544] MAY be supported; this may allow > applications to communicate to peers with public IP addresses across > UDP-blocking firewalls without using a TURN server. > > Also this option would need to use a framing of the datagrams. Yep. Updated draft to be submitted once submission reopens. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From nobody Wed Feb 19 12:50: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 7B7481A04C1 for ; Wed, 19 Feb 2014 12:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.981, 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 FlNQ3PSWV2TG for ; Wed, 19 Feb 2014 12:50:42 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5D01A0418 for ; Wed, 19 Feb 2014 12:50:41 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-ee-5305191cf5e7 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EA.F9.23809.C1915035; Wed, 19 Feb 2014 21:50:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Wed, 19 Feb 2014 21:50:36 +0100 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Stream control: [MMUSIC] msid-04 submitted Thread-Index: AQHPKVPuF/VJzX0Fb0yVt/Xv3TzOfJq0+6GAgAAXm1SABo2kgIAAovSRgACVFICAADzpYg== Date: Wed, 19 Feb 2014 20:50:35 +0000 Message-ID: References: <52FDC17E.8070708@alvestrand.no>,<52FE5B37.80409@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1735EE@ESESSMB209.ericsson.se>, <5303EE53.1010405@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1A9B80@ESESSMB209.ericsson.se>, <5304F413.1080208@alvestrand.no> In-Reply-To: <5304F413.1080208@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_pi22myx9puvcw80lbn1s1ktu1392843033581emailandroidcom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvja6sJGuwQeNOLotjfV1sFmv/tbM7 MHlcmXCF1WPJkp9MAUxRXDYpqTmZZalF+nYJXBm336xgKXhoULH4y1fmBsazml2MnBwSAiYS Zx9fZ4WwxSQu3FvP1sXIxSEkcIhRYsmO+4xdjBxAzhJGicv6ICabgIVE9z9tkHIRgWCJ3ufv GUFsYQEHiXuHpjJDxB0l5mxdzgRhh0lMW3kdzGYRUJW4OfkwC4jNK+Am8av9ANSqqUwS185O YANJcAroSnzcsB/sHkage76fWgPWzCwgLnHryXwmiDsFJJbsOc8MYYtKvHz8jxWiJkfi6Y// UAsEJU7OfMIygVF4FpL2WUjKZiEpg4gbSHx5fxvK1pZYtvA1M4StL9H9/jQTsvgCRvZVjOy5 iZk56eVGmxiBEXJwy2/VHYx3zokcYpTmYFES5/3w1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA2M/+119T7OJdlnvip+LKT69XWO3yKs3g5M3+M8FWeFiqy/87YvrY9XEfoY+WMwUysJu 5pJ41FGMVept0OQOB5+asrX835cvnr+dJeXjt4pwNZ0J158/qUzb5sIqczqITesrI/uGzPIy A+9nEv7RhZ7BHdNYGuYkxH+uf3vbU/Pr9DPWnzR2KLEUZyQaajEXFScCAKHW/t1eAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/amcIpCq7jJNJT8Z6H461vu8hIe4 Subject: Re: [rtcweb] Stream control: [MMUSIC] msid-04 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 19 Feb 2014 20:50:48 -0000 --_000_pi22myx9puvcw80lbn1s1ktu1392843033581emailandroidcom_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, If the indication is NOT permanent, can't we use the existing direction att= ributes (sendrecv, sendonly etc)? Regards, Christer Sent from my Sony Ericsson Xperia arc S Harald Alvestrand wrote: On 02/19/2014 09:19 AM, Christer Holmberg wrote: Hi, If the indication is =93permanent=94, rather than using a new msid-control = attribute, could it be indicated by NOT including some information in the A= nswer? Certainly, but then you have to include some information in the answer when= the indication is not permanent. Which information were you thinking of utilizing as a signal? Regards, Christer Sent from Windows Mail From: 'Harald Alvestrand' Sent: =FDWednesday=FD, =FDFebruary=FD =FD19=FD, =FD2014 =FD1=FD:=FD35=FD = =FDAM To: Hans-Christer Holmberg, rtcweb@i= etf.org One thing I did not add in my previous reply: If an offerer sets the direction of an m-line to sendrecv, and the answerer sets the direction to sendonly, the offerer will have no indication of whether the answerer intended the suspension of traffic to be temporary (msid-control: disable) or permanent (msid-control: reject or msid-control: stop). That was actually the main concern that drove the desire for a new mechanism. Once the new mechanism was in place, it seemed logical to be explicit about the other possible actions too, rather than relying on the sendrecv/sendonly/recvonly parameter. Harald -- Surveillance is pervasive. Go Dark. --_000_pi22myx9puvcw80lbn1s1ktu1392843033581emailandroidcom_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable 
Hi,=0A=
=0A=
If the indication is NOT permanent, can't we use the existing direction att=
ributes (sendrecv, sendonly etc)?=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Harald Alvestrand <harald@alvestrand.no> wrote:=0A=
=0A=
On 02/19/2014 09:19 AM, Christer Holmberg wr= ote:
Hi,

If the indication is =93permanent=94, rather than using a new msi= d-control attribute, could it be indicated by NOT including some informatio= n in the Answer?

Certainly, but then you have to include some information in the answer when= the indication is not permanent.

Which information were you thinking of utilizing as a signal?



Regards,

Christer

Sent from Windows Mail

From: 'Harald Alvestrand'
Sent: =FDWednesday=FD, =FDFebruary=FD =FD19=FD, =FD2014 =FD1=FD= :=FD35=FD =FDAM
To: Hans-Christer Holmberg, rtcweb@ietf.org

One thing I did not add in my previous r= eply:

If an offerer sets the direction of an m-line to sendrecv, and the
answerer sets the direction to sendonly, the offerer will have no
indication of whether the answerer intended the suspension of traffic to be temporary (msid-control: disable) or permanent (msid-control: reject
or msid-control: stop).

That was actually the main concern that drove the desire for a new
mechanism.
Once the new mechanism was in place, it seemed logical to be explicit
about the other possible actions too, rather than relying on the
sendrecv/sendonly/recvonly parameter.

          Harald



--=20
Surveillance is pervasive. Go Dark.
--_000_pi22myx9puvcw80lbn1s1ktu1392843033581emailandroidcom_-- From nobody Wed Feb 19 16:22: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 3F2B71A05D2 for ; Wed, 19 Feb 2014 16:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] 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 37zDtcFPxqLp for ; Wed, 19 Feb 2014 16:22:47 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id D86821A0538 for ; Wed, 19 Feb 2014 16:22:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9067C7C4E79; Thu, 20 Feb 2014 01:22:42 +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 FP-t5Wf3R8c8; Thu, 20 Feb 2014 01:22:41 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id 293887C4DB5; Thu, 20 Feb 2014 01:22:40 +0100 (CET) Message-ID: <53054ACF.6030601@alvestrand.no> Date: Thu, 20 Feb 2014 01:22:39 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Christer Holmberg , "rtcweb@ietf.org" References: <52FDC17E.8070708@alvestrand.no>, <52FE5B37.80409@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1735EE@ESESSMB209.ericsson.se>, <5303EE53.1010405@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1A9B80@ESESSMB209.ericsson.se>, <5304F413.1080208@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------030909010605010002060504" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LB1ib24f9xaZQzUGC6wzpEh3RL8 Subject: Re: [rtcweb] Stream control: [MMUSIC] msid-04 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 20 Feb 2014 00:22:51 -0000 This is a multi-part message in MIME format. --------------030909010605010002060504 Content-Type: text/plain; charset=windows-1256 Content-Transfer-Encoding: 8bit On 02/19/2014 09:50 PM, Christer Holmberg wrote: > Hi, > > If the indication is NOT permanent, can't we use the existing direction attributes (sendrecv, sendonly etc)? We could - but how would we then indicate "permanent"? Omitting the direction attribute means the same as "sendrecv", if I'm not mistaken. So you can't have meant omitting that. So what were you suggesting? > Regards, > > Christer > > Sent from my Sony Ericsson Xperia arc S > > Harald Alvestrand wrote: > > On 02/19/2014 09:19 AM, Christer Holmberg wrote: >> Hi, >> >> If the indication is “permanent”, rather than using a new >> msid-control attribute, could it be indicated by NOT including some >> information in the Answer? > > Certainly, but then you have to include some information in the answer > when the indication is not permanent. > > Which information were you thinking of utilizing as a signal? > > >> >> Regards, >> >> Christer >> >> Sent from Windows Mail >> >> *From:* 'Harald Alvestrand' >> *Sent:* ýWednesdayý, ýFebruaryý ý19ý, ý2014 ý1ý:ý35ý ýAM >> *To:* Hans-Christer Holmberg , >> rtcweb@ietf.org >> >> One thing I did not add in my previous reply: >> >> If an offerer sets the direction of an m-line to sendrecv, and the >> answerer sets the direction to sendonly, the offerer will have no >> indication of whether the answerer intended the suspension of traffic to >> be temporary (msid-control: disable) or permanent (msid-control: reject >> or msid-control: stop). >> >> That was actually the main concern that drove the desire for a new >> mechanism. >> Once the new mechanism was in place, it seemed logical to be explicit >> about the other possible actions too, rather than relying on the >> sendrecv/sendonly/recvonly parameter. >> >> Harald >> > > > -- > Surveillance is pervasive. Go Dark. -- Surveillance is pervasive. Go Dark. --------------030909010605010002060504 Content-Type: text/html; charset=windows-1256 Content-Transfer-Encoding: 8bit
On 02/19/2014 09:50 PM, Christer Holmberg wrote:
Hi,

If the indication is NOT permanent, can't we use the existing direction attributes (sendrecv, sendonly etc)?

We could - but how would we then indicate "permanent"?

Omitting the direction attribute means the same as "sendrecv", if I'm not mistaken. So you can't have meant omitting that.

So what were you suggesting?


Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Harald Alvestrand <harald@alvestrand.no> wrote:
On 02/19/2014 09:19 AM, Christer Holmberg wrote:
Hi,

If the indication is “permanent”, rather than using a new msid-control attribute, could it be indicated by NOT including some information in the Answer?

Certainly, but then you have to include some information in the answer when the indication is not permanent.

Which information were you thinking of utilizing as a signal?



Regards,

Christer

Sent from Windows Mail

From: 'Harald Alvestrand'
Sent: ýWednesdayý, ýFebruaryý ý19ý, ý2014 ý1ý:ý35ý ýAM
To: Hans-Christer Holmberg, rtcweb@ietf.org

One thing I did not add in my previous reply:

If an offerer sets the direction of an m-line to sendrecv, and the
answerer sets the direction to sendonly, the offerer will have no
indication of whether the answerer intended the suspension of traffic to
be temporary (msid-control: disable) or permanent (msid-control: reject
or msid-control: stop).

That was actually the main concern that drove the desire for a new
mechanism.
Once the new mechanism was in place, it seemed logical to be explicit
about the other possible actions too, rather than relying on the
sendrecv/sendonly/recvonly parameter.

          Harald



-- 
Surveillance is pervasive. Go Dark.



-- 
Surveillance is pervasive. Go Dark.
--------------030909010605010002060504-- From nobody Thu Feb 20 08:05: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 839171A01EF for ; Thu, 20 Feb 2014 08:05:38 -0800 (PST) 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_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 xgpR2fFdQcZj for ; Thu, 20 Feb 2014 08:05:36 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id C990A1A01E3 for ; Thu, 20 Feb 2014 08:05:35 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-44-530627cbfa91 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 26.1E.04249.BC726035; Thu, 20 Feb 2014 17:05:31 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.2.347.0; Thu, 20 Feb 2014 17:05:30 +0100 Message-ID: <530627C7.30906@ericsson.com> Date: Thu, 20 Feb 2014 17:05:27 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" , EKR X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLJMWRmVeSWpSXmKPExsUyM+Jvje5pdbZgg0NzJCxWvD7HbrH2Xzu7 A5PHkiU/mTwmP25jDmCK4rJJSc3JLEst0rdL4Mq49WwSU8FM6YqzD+ayNTC+Fe1i5OSQEDCR uNCxkBXCFpO4cG89WxcjF4eQwBFGibutXcwQznJGiXtvPzKCVPEKaEr0f/nPAmKzCKhKLLj6 GaybTcBC4uaPRjYQW1QgWGLngd9Q9YISJ2c+AasXEbCWuLnsMViNsICRxLquVvYuRg6gzeIS PY1BIGFmAT2JKVdbGCFseYnmrbOZQWwhAW2JhqYO1gmM/LOQTJ2FpGUWkpYFjMyrGDmKU4uT ctONDDYxAoPs4JbfFjsYL/+1OcQozcGiJM778a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5O qQbGfQtK09pSz6cqbFdgPfvsk1LEtenbpDOmV53junFf4fOaPkv+nXu8xFsvm8/XYjrKvFyd M76fgdVQd3eOuCAfb3FO5fvNVc5HQsXXHoq2/xRiL+l2btXR/JbCd1f2HaxqeTqZ0SL29/1O oZqghr/6B/Lef+1YOjVJ78j21W6Nm24ms0w0XpmtxFKckWioxVxUnAgAtLhH2AACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3e1BBrsJXzHz9BZhgeTqyAstUqo Subject: [rtcweb] Comments on draft-ietf-rtcweb-security-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 20 Feb 2014 16:05:38 -0000 Hi, I have reviewed Security Considerations for WebRTC (draft-ietf-rtcweb-security-06) and have some comments. 1. Section 4.2.1: I noted this: There also needs to be some mechanism for the browser to verify that the target of the traffic continues to wish to receive it. Because ICE keepalives are indications, they will not work here, so some other mechanism is needed as described in [I-D.muthu-behave-consent-freshness]. Not that the current information is wrong, except that the reference should be to the WG version of the draft. However, this I think is the only part of the document I found which prevents another WG last call on this document, due to the open issue regarding method of communication consent refresh. 2. Section 4.2.2.: First sentence duplicated. 3. Section 4.2.2: When I read this section, my immediate question was, doesn't RTP need corresponding protection. To my understanding, the answer would be yes, but it is more difficult to inject data and get a certain plaintext even without the SRTP encryption scrambling the payload part. Still, that assumes that an JS application, can write the payload data itself. Secondly, it does assume that one MUST use encryption in SRTP. Thus, I wonder if it is worth spending a paragraph confirming the need, although reduced for masking also of RTP content, and that the same requirement exist for RTP. 4. Section 4.3.2.2: Once uses have checked the SAS once, key continuity is required to avoid them needing to check it on every call. I believe "uses" in above sentence should be "the user"? 5. Section 6. Please correct my last name. 6. General: I think the difficulty with this document is to determine if is missing something? It is providing the high level system security issues. Have we caught all relevant ones? I think we need a lot of eyes to check for that. And that requires thought and not being restricted by the document. I think a potential issue that isn't discussed in this document is the security threat of driving data volumes into a network beyond ones "fair" share. This would simply be to illustrate that communication consent is not sufficient, to protect other users of a shared network the WebRTC endpoint MUST prevent transmission of data volumes far outside of the fair share. 7. General: I noticed that some of the other WG documents may think they have outsourced their security consideration to this document. I want to bring this up as a general question and ensure that we have WG agreement on this. This document discusses general system security considerations to ensure that the whole thing we put together achieve security. Each component of the solution will have to discuss security considerations details around their components. As we plan to WG last call this document as soon as possible, we are running out of time to lift any security issues to this level. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Feb 20 09:13: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 5A2221A01AF for ; Thu, 20 Feb 2014 09:13:53 -0800 (PST) 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 2uDpw_FlB3tn for ; Thu, 20 Feb 2014 09:13:49 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 912C41A0211 for ; Thu, 20 Feb 2014 09:13:49 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id uy17so12088105igb.4 for ; Thu, 20 Feb 2014 09:13:44 -0800 (PST) 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=I/gkwcCqjsc+6V18tdLccIibj/j/4ZUyILILAClmhJI=; b=YZtShi0meaXAK7GXCoO+VDcQp8TBZ37Q2Qc7q5a0ZZo3A+g1tOuLIpNDJyja7ztwqp Jk54hyZhaHNMA8h3Z+Poz6tcgp0JAvfxwF/9OKaI15xtjnXKRivpCOAlZis1xmAH6URA w/Ll3ByUdhJ/B64yjhBQqQFsMmK/7dA6DX7RkzsVxM+2LCCBZ0XrRR1gQsyCLqNxTdex LzOF9TG0aOBeHF7LeMyfPvyWBLdslHWmwJK30oNtIPYphsQ4mcKAXEckRwBcT3tygmOs ALSGy0x7gspyzRK2zO0YO2GtwnoeOvQVJ+Lp5w+pXvIRa6smWMkCqUu30ZNckcju/xko vPnQ== MIME-Version: 1.0 X-Received: by 10.50.56.109 with SMTP id z13mr3307985igp.6.1392916424743; Thu, 20 Feb 2014 09:13:44 -0800 (PST) Received: by 10.42.237.206 with HTTP; Thu, 20 Feb 2014 09:13:44 -0800 (PST) In-Reply-To: <530627C7.30906@ericsson.com> References: <530627C7.30906@ericsson.com> Date: Thu, 20 Feb 2014 09:13:44 -0800 Message-ID: From: Ted Hardie To: Magnus Westerlund Content-Type: multipart/alternative; boundary=089e0158aa12b2df1304f2d9a0af Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/alLwXcKg5HG2o7GMfG8mQQFCKzU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 20 Feb 2014 17:13:53 -0000 --089e0158aa12b2df1304f2d9a0af Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 20, 2014 at 8:05 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I think a potential issue that isn't discussed in this document is the > security threat of driving data volumes into a network beyond ones > "fair" share. This would simply be to illustrate that communication > consent is not sufficient, to protect other users of a shared network > the WebRTC endpoint MUST prevent transmission of data volumes far > outside of the fair share. > > > Magnus, I'm not sure why you think that issue should be dealt with in this document. This document should deal with cases where a malicious script could send transmissions that are not intended or not welcome. Bbut managing network capacity for *intended* and *welcome* transmissions is not a security concern. It's a congestion management issue, at least as I see it. Am I missing something about your concern? Ted --089e0158aa12b2df1304f2d9a0af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 20, 2014 at 8:05 AM= , Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,

I think a potential issue that isn't discussed in this document is the<= br> security threat of driving data volumes into a network beyond ones
"fair" share. This would simply be to illustrate that communicati= on
consent is not sufficient, to protect other users of a shared network
the WebRTC endpoint MUST prevent transmission of data volumes far
outside of the fair share.



Magnus, I'm not sure why you think t= hat issue should be dealt with in this document.
This document should deal with cases where a malicious script could send tr= ansmissions
that are not intended or not welcome.=A0 Bbut man= aging network capacity for *intended*
and *welcome* transmissions is not a security concern.=A0 It's a conges= tion management
issue, at least as I see it.

Am I miss= ing something about your concern?

Ted
=A0
--089e0158aa12b2df1304f2d9a0af-- From nobody Thu Feb 20 12:31: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 5F65C1A0281 for ; Thu, 20 Feb 2014 12:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.981, 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 xTSCb8TkqtYf for ; Thu, 20 Feb 2014 12:31:31 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E02C31A0283 for ; Thu, 20 Feb 2014 12:31:27 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-99-5306661b2874 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 15.DC.23809.B1666035; Thu, 20 Feb 2014 21:31:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Thu, 20 Feb 2014 21:31:23 +0100 From: Christer Holmberg To: 'Harald Alvestrand' , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Stream control: [MMUSIC] msid-04 submitted Thread-Index: AQHPKVPuF/VJzX0Fb0yVt/Xv3TzOfJq0+6GAgAAXm1SABo2kgIAAovSRgACVFICAADzpYoAAKnyAgAFieno= Date: Thu, 20 Feb 2014 20:31:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1ACAA5@ESESSMB209.ericsson.se> References: <52FDC17E.8070708@alvestrand.no>,<52FE5B37.80409@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1735EE@ESESSMB209.ericsson.se>, <5303EE53.1010405@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1A9B80@ESESSMB209.ericsson.se>, <5304F413.1080208@alvestrand.no> , <53054ACF.6030601@alvestrand.no> In-Reply-To: <53054ACF.6030601@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1ACAA5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvja50GluwwcQpUhbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJWzG5jKnjvX3G5axdjA+Nply5GTg4JAROJ 00unskPYYhIX7q1nA7GFBA4xSpxYa9TFyAVkL2GUaNraBlTEwcEmYCHR/U8bxBQRCJVYtFIb pFxYwEHi3qGpzCC2iICjxJyty5kg7CSJi4fOMoLYLAKqEnfeTQYbzyvgK7Fp/RI2iPGfmSRm rf0O1swpoCvx8d1yFhCbEeie76fWgA1iFhCXuPVkPhPEnQISS/acZ4awRSVePv7HClGTL/Hv /zFGiAWCEidnPmGZwCg8C0n7LCRls5CUQcQNJL68vw1la0ssW/iaGcLWl+h+f5oJWXwBI/sq RvbcxMyc9HKjTYzACDm45bfqDsY750QOMUpzsCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8 iJGJg1OqgbHBTZnRuNDl1ALXqAMK96+vPLfy/nZl/WBR9iDxjGNiPqdyAuc1r5x7YE3a8ipm 4x07r5VeX2xlHFr/VCTA+J9Z+8Tzh6W27/p7fVfIi6JXvI0s6yf3tYWGqFlYfypen3J12hMZ oZNRvvr+7yWPzi/1a/t6WfaNg+DqJNYSy0vne2KW1qadmajEUpyRaKjFXFScCACU8gKZXgIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4t_GJYlmHR7Kllvvau9pjb_yAbk Subject: Re: [rtcweb] Stream control: [MMUSIC] msid-04 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 20 Feb 2014 20:31:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1ACAA5ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, My suggestion was to omit something else. But, at the moment I don=92t have= the drafts in front of me, so I can=92t suggest anything specific. Regards, Christer Sent from Windows Mail From: 'Harald Alvestrand' Sent: =FDThursday=FD, =FDFebruary=FD =FD20=FD, =FD2014 =FD2=FD:=FD22=FD =FD= AM To: Hans-Christer Holmberg, rtcweb@i= etf.org On 02/19/2014 09:50 PM, Christer Holmberg wrote: Hi, If the indication is NOT permanent, can't we use the existing direction att= ributes (sendrecv, sendonly etc)? We could - but how would we then indicate "permanent"? Omitting the direction attribute means the same as "sendrecv", if I'm not m= istaken. So you can't have meant omitting that. So what were you suggesting? Regards, Christer Sent from my Sony Ericsson Xperia arc S Harald Alvestrand wrote= : On 02/19/2014 09:19 AM, Christer Holmberg wrote: Hi, If the indication is =93permanent=94, rather than using a new msid-control = attribute, could it be indicated by NOT including some information in the A= nswer? Certainly, but then you have to include some information in the answer when= the indication is not permanent. Which information were you thinking of utilizing as a signal? Regards, Christer Sent from Windows Mail From: 'Harald Alvestrand' Sent: =FDWednesday=FD, =FDFebruary=FD =FD19=FD, =FD2014 =FD1=FD:=FD35=FD = =FDAM To: Hans-Christer Holmberg, rtcweb@i= etf.org One thing I did not add in my previous reply: If an offerer sets the direction of an m-line to sendrecv, and the answerer sets the direction to sendonly, the offerer will have no indication of whether the answerer intended the suspension of traffic to be temporary (msid-control: disable) or permanent (msid-control: reject or msid-control: stop). That was actually the main concern that drove the desire for a new mechanism. Once the new mechanism was in place, it seemed logical to be explicit about the other possible actions too, rather than relying on the sendrecv/sendonly/recvonly parameter. Harald -- Surveillance is pervasive. Go Dark. -- Surveillance is pervasive. Go Dark. --_000_7594FB04B1934943A5C02806D1A2204B1D1ACAA5ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

My suggestion was to omit something else. But, at the moment I don=92t= have the drafts in front of me, so I can=92t suggest anything specific.

Regards,

Christer

Sent from Windows Mail

From: 'Harald Alvestrand'
Sent: =FDThursday=FD, =FDFebruary=FD =FD20=FD, =FD2014 =FD2=FD:= =FD22=FD =FDAM
To: Hans-Christer Holmberg, rtcweb@ietf.org

On 02/19/2014 09:50 PM, Christer Holmberg wr= ote:
Hi,=0A=
=0A=
If the indication is NOT permanent, can't we use the existing direction att=
ributes (sendrecv, sendonly etc)?=0A=

We could - but how would we then indicate "permanent"?

Omitting the direction attribute means the same as "sendrecv", if= I'm not mistaken. So you can't have meant omitting that.

So what were you suggesting?


Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Harald Alvestrand <harald@alvestrand.no> wrote:=
=0A=
=0A=
On 02/19/2014 09:19 AM, Christer Holmberg wr= ote:
Hi,

If the indication is =93permanent=94, rather than using a new msi= d-control attribute, could it be indicated by NOT including some informatio= n in the Answer?

Certainly, but then you have to include some information in the answer when= the indication is not permanent.

Which information were you thinking of utilizing as a signal?



Regards,

Christer

Sent from Windows Mail

From: 'Harald Alvestrand'
Sent: =FDWednesday=FD, =FDFebruary=FD =FD19=FD, =FD2014 =FD1=FD= :=FD35=FD =FDAM
To: Hans-Christer Holmberg, rtcweb@ietf.org

One thing I did not add in my previous r= eply:

If an offerer sets the direction of an m-line to sendrecv, and the
answerer sets the direction to sendonly, the offerer will have no
indication of whether the answerer intended the suspension of traffic to be temporary (msid-control: disable) or permanent (msid-control: reject
or msid-control: stop).

That was actually the main concern that drove the desire for a new
mechanism.
Once the new mechanism was in place, it seemed logical to be explicit
about the other possible actions too, rather than relying on the
sendrecv/sendonly/recvonly parameter.

          Harald



-- =0A=
Surveillance is pervasive. Go Dark.=0A=



-- =0A=
Surveillance is pervasive. Go Dark.=0A=
--_000_7594FB04B1934943A5C02806D1A2204B1D1ACAA5ESESSMB209erics_-- From nobody Thu Feb 20 14: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 3BB6E1A02F0 for ; Thu, 20 Feb 2014 14:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548, 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 ipAW7pjsiv1J for ; Thu, 20 Feb 2014 14:13:28 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 554FA1A0105 for ; Thu, 20 Feb 2014 14:13:28 -0800 (PST) Received: from [192.168.1.103] (p508F07DB.dip0.t-ipconnect.de [80.143.7.219]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 17F601C0B2D71; Thu, 20 Feb 2014 23:13:22 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Thu, 20 Feb 2014 23:13:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9782EE1D-7FF3-4F6B-BCDF-37C143770E96@lurchi.franken.de> References: To: Lijing (Jessie) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vsolehyJq2wTbXo4BQgI6Mw623U Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on data channel related 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, 20 Feb 2014 22:13:32 -0000 On Feb 19, 2014, at 12:07 PM, Lijing (Jessie) = wrote: > Hi, > =20 > Several comments on data channel related drafts. > =20 > Firstly, There are several =93protocol=94 concepts appeared in = different data channel related drafts, and it seems there is no clear = statement about the relationship between these concepts. > =20 > draft-ietf-rtcweb-data-protocol has two protocol concept: > 1. The protocol byte in data channel open message defined as the = protocol for the channel. > 2. SCTP payload protocol identifier (PPID) > =20 > WebRTC W3C API has one protocol concept, > 3. Protocol defined as =93Subprotocol name used for this channel=94 > =20 > Q1: is the W3C API parameter =93protocol=94 be the same as the = protocol byte in the data channel open message? Correct. The DOMString protocol provided in the W3C API in negotiated in = the DATA_CHANNEL_OPEN message as the protocol field. Please note that the Protocol field in the = DATA_CHANNEL_OPEN message is not a byte, but a string. > =20 > =20 > In previous email discussion, Peter Thatcher said : > =93The PPID isn't exposed to the application. It's just used to > distinguish text/binary/control. If an application uses different > data channels with different protocols, it should use the SID to = distinguish between them, not the PPID. In fact, even if it wanted to = use the PPID, it wouldn't be able to.=94 Data channels are identified by the SID on the wire, which corresponds = to the id field in the W3C API. The JS API has no access to the PPID. > =20 > Q2: if the answer of Q1 is yes. Then an application can distinguish = different data channels with different protocols by the protocol byte in = the data channel open message. Is my understanding right? Not sure what the application is. The W3C API lets you distinguish the = data channels, since you have different objects for it. > =20 > draft-ejzak-mmusic-data-channel-sdpneg provides a way to negotiate = sub-protocol parameters out of band. > 4. Sub-protocol: The 'sub-protocol' parameter indicates which = protocol the client expects to exchange via the channel.=20 > example: a=3Ddcmap:5000 stream=3D2;label=3D"channel 2"; = subprotocol=3D"BFCP";max_retr=3D3 > =20 > Q3: is this =93subprotocol=94 be the same concept as the protocol byte = in the data channel open message? And the W3C API =93protocol=94 should = be set as BFCP? Again: there is no protocol byte... It is a string and is is the = subprotocol... > =20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > Secondly, in draft-ietf-rtcweb-data-channel-07, section 8 defines the = following PPIDs > +------------------------------------+-----------+-----------+ > | Value | SCTP PPID | Reference | > +------------------------------------+-----------+-----------+ > | WebRTC String | 51 | [RFCXXXX] | > | WebRTC Binary Partial (Deprecated) | 52 | [RFCXXXX] | > | WebRTC Binary | 53 | [RFCXXXX] | > | WebRTC String Partial (Deprecated) | 54 | [RFCXXXX] | > +------------------------------------+-----------+-----------+ > =20 > Q4: It is confusing what is the intention to define =93WebRTC Binary = Partial=94 and =93WebRTC String Partial=94. I guess these two PPIDs are = provided to the application in the case when application supports = fragmentation of large messages. But, at the meantime, in this draft, = section 6.6 also says: The usage of the PPIDs "WebRTC String Partial" = and "WebRTC Binary Partial" is deprecated. Why the usage is deprecated? = Does this implies that SCTP layer is responsible for fragmentation of = large messages, and it is unnecessary for the upper application to = implement the fragmentation of large messages? Section 6.6 explains it: The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary = Partial" is deprecated. They were used for a PPID based fragmentation = and reassembly of user messages belonging to reliable and ordered data = channels. > =20 > Q5: Since PPID 52 and 54 are defined, then how can the browser know = whether the data sent from the upper application layer is a part of a = whole message and the SCTP PPID should be signaled as Partial 52/54, or = this is a whole message and should be signaled as 51/54? The PPIDs 52 and 54 were intended to implement fragmentation/reassembly = inside the data channel implementation. This is how it is implemented in Firefox. There is now way to access it = from the JS API. However, the usage is deprecated and therefore you don't need to = implement it. > =20 > Q6: if one side wants to send two messages, and the application split = the first big message to two packages, then the browser will send three = SCTP packages whose PPID are 54(part of first message), 51(part of first = message), 51(the whole second message) respectively. When the receiver = side receives these three SCTP packages, how can the receiver side know = which two SCTP packages can be assembled to get the first big message? It worked only for ordered reliable data channels. So the sequence was = used. Once you got PPID 51, the message is complete. > =20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > The last question, which I have asked in previous email and have not = received any response until now, so I mention this question again. > in draft-ietf-rtcweb-data-channel-07, Section 4 says: > Req. 4: The application SHOULD be able to provide guidance as to > the relative priority of each data channel relative to = each > other, and relative to the media streams. This will > interact with the congestion control algorithms. > =20 > And in draft-ietf-rtcweb-data-protocol-03, DATA_CHANNEL_OPEN Message = is defined as below > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Type | Channel Type | Priority | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reliability Parameter | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Label Length | Protocol Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ / > | Label | > / \ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ / > | Protocol | > / \ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Priority: 2 bytes (integer) > The priority of the channel as described in > [I-D.ietf-rtcweb-data-channel]. The higher the number, the = lower > the priority. > =20 > Q7: It seems that for now there is no W3C API parameters to set the = priority of data channel. I wonder whether the priority of the data = channel is open to the application or is only decided by the browser. In = other words, I want to know how the application be able to provide = guidance as to the priority. You are right. The W3C API does not cover the priority yet. My = understanding is that this is missing and needs to be added. I expect that the priority = is settable via the JS API. Best regards Michael > =20 > Best Regards, > =20 > Jessie > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Feb 21 00:09: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 3590D1A04BD for ; Fri, 21 Feb 2014 00:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 1R-n6kqCNgeZ for ; Fri, 21 Feb 2014 00:09:00 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9F47E1A005B for ; Fri, 21 Feb 2014 00:08:59 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-77-53070996d0d6 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E7.62.10875.69907035; Fri, 21 Feb 2014 09:08:55 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.347.0; Fri, 21 Feb 2014 09:08:54 +0100 Message-ID: <53070996.9040707@ericsson.com> Date: Fri, 21 Feb 2014 09:08:54 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ted Hardie References: <530627C7.30906@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyM+Jvje50TvZggyVruSxWvD7HbrH2Xzu7 ReNcOwdmj52z7rJ7LFnyk8lj8uM25gDmKC6blNSczLLUIn27BK6MWWuvMBbsE6nYeJ63gXG9 QBcjJ4eEgInEob0fWCFsMYkL99azdTFycQgJHGKUuHl7J5SznFHiwOTt7CBVvALaEh+f32Hs YuTgYBFQleieYQ4SZhOwkLj5o5ENxBYVCJbYeeA3I0S5oMTJmU9YQGwRAWWJvVd2gNUwC1hL nJ2wCywuLGAv8eDucyaQkUICeRItB9JAwpwCgRIPW2aCbZIQEJfoaQyC6NSTmHK1hRHClpdo 3jqbGcQWAjqsoamDdQKj0Cwki2chaZmFpGUBI/MqRvbcxMyc9HLDTYzAsD245bfuDsZT50QO MUpzsCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTGqvb4v2WOWwcOOLbrGAhd/ rl464dHE3/+PTWcXvyGwdKLsRw+H/WeeKu4Sv2D48k56aqOOcsvqEpW2y1aF7otlV7/dxrqj QmiPjo7W2QPqv/4cnPfJ4ntlK+fJs6+eONl6Tr32ON3dkDdcMWq1tIff9VR73yOJy5osBGXe mAbN9fl3pNvwfJISS3FGoqEWc1FxIgCe+IJJKQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IQXO5dhVaaWve3S5wimuGcUrWZA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 21 Feb 2014 08:09:02 -0000 On 2014-02-20 18:13, Ted Hardie wrote: > On Thu, Feb 20, 2014 at 8:05 AM, Magnus Westerlund > > > wrote: > > Hi, > > I think a potential issue that isn't discussed in this document is the > security threat of driving data volumes into a network beyond ones > "fair" share. This would simply be to illustrate that communication > consent is not sufficient, to protect other users of a shared network > the WebRTC endpoint MUST prevent transmission of data volumes far > outside of the fair share. > > > > Magnus, I'm not sure why you think that issue should be dealt with in > this document. > This document should deal with cases where a malicious script could send > transmissions > that are not intended or not welcome. Bbut managing network capacity > for *intended* > and *welcome* transmissions is not a security concern. It's a > congestion management > issue, at least as I see it. > > Am I missing something about your concern? > My concern is that a malicious individual wants to DDoS a particular network. I buy AD time from on of the network or in any other way ensure that the mailicious JS identifies when each client is topologically right for me to connect it to another client to drive traffic through my targets network. Then I ensure these clients establish a peer connection and I try to blast as much traffic through the network as possible. From the point of the attack this doesn't matter if is real-time media or data traffic. The point is to drive as much traffic into the network as possible. From that perspective any traffic that is sent in the context of a peerconnection needs to be congestion controlled. That at least keeps the traffic down to a "fair" share. We are mitigating this attack, however what I was really wondering over is if the security considerations document should make note that lack of appropriate congestion control is a security vulnerability and enables certain type of load attacks. Does this make my concern clearer? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Feb 21 01:21: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 8AE041A0049 for ; Fri, 21 Feb 2014 01:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 Yj_yyLfthpWJ for ; Fri, 21 Feb 2014 01:21:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 323D31A0048 for ; Fri, 21 Feb 2014 01:21:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDU86080; Fri, 21 Feb 2014 09:21:18 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 09:20:59 +0000 Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 09:21:16 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Fri, 21 Feb 2014 17:21:10 +0800 From: "Lijing (Jessie)" To: Michael Tuexen Thread-Topic: [rtcweb] Comments on data channel related drafts Thread-Index: AQHPLWLMOA6HXUQ9mEaoGulYw8fFA5q+MQuAgAEsC4A= Date: Fri, 21 Feb 2014 09:21:10 +0000 Message-ID: References: <9782EE1D-7FF3-4F6B-BCDF-37C143770E96@lurchi.franken.de> In-Reply-To: <9782EE1D-7FF3-4F6B-BCDF-37C143770E96@lurchi.franken.de> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.171.171] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sOlt9OvTAPyWOUFZLmJmlpYJjg8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on data channel related 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, 21 Feb 2014 09:21:27 -0000 Hi, Thanks a lot to Michael's interpretation, and it is really helpful. Two more issues to be discussed: 1. I am still not quite sure what "PPID based fragmentation and reassembly = " is. Does it mean SCTP performs segmentation and reassembly based on the p= ath MTU? Or it refers to other method or protocols? 2. The priority of data channel involves two aspects, one aspect is priorit= y of one data channel compared with priority of other data channels, and th= e other aspect is priority of one data channel compared with audio and vide= o media stream tracks. If the data channel priority is settable via JS API,= then the audio and video priority should also be set via JS API in a way. = I think the priority should be set considering all the media types includin= g audio, video and data channel. BR, Jessie -----Original Message----- From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 Sent: Friday, February 21, 2014 6:13 AM To: Lijing (Jessie) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Comments on data channel related drafts On Feb 19, 2014, at 12:07 PM, Lijing (Jessie) wrote: > Hi, > =20 > Several comments on data channel related drafts. > =20 > Firstly, There are several "protocol" concepts appeared in different data= channel related drafts, and it seems there is no clear statement about the= relationship between these concepts. > =20 > draft-ietf-rtcweb-data-protocol has two protocol concept: > 1. The protocol byte in data channel open message defined as the protoco= l for the channel. > 2. SCTP payload protocol identifier (PPID) > =20 > WebRTC W3C API has one protocol concept, 3. Protocol defined as=20 > "Subprotocol name used for this channel" > =20 > Q1: is the W3C API parameter "protocol" be the same as the protocol byte = in the data channel open message? Correct. The DOMString protocol provided in the W3C API in negotiated in th= e DATA_CHANNEL_OPEN message as the protocol field. Please note that the Pro= tocol field in the DATA_CHANNEL_OPEN message is not a byte, but a string. > =20 > =20 > In previous email discussion, Peter Thatcher said : > "The PPID isn't exposed to the application. It's just used to > distinguish text/binary/control. If an application uses different > data channels with different protocols, it should use the SID to distingu= ish between them, not the PPID. In fact, even if it wanted to use the PPID= , it wouldn't be able to." Data channels are identified by the SID on the wire, which corresponds to t= he id field in the W3C API. The JS API has no access to the PPID. > =20 > Q2: if the answer of Q1 is yes. Then an application can distinguish diffe= rent data channels with different protocols by the protocol byte in the dat= a channel open message. Is my understanding right? Not sure what the application is. The W3C API lets you distinguish the data= channels, since you have different objects for it. > =20 > draft-ejzak-mmusic-data-channel-sdpneg provides a way to negotiate sub-pr= otocol parameters out of band. > 4. Sub-protocol: The 'sub-protocol' parameter indicates which protocol t= he client expects to exchange via the channel.=20 > example: a=3Ddcmap:5000 stream=3D2;label=3D"channel 2";=20 > subprotocol=3D"BFCP";max_retr=3D3 > =20 > Q3: is this "subprotocol" be the same concept as the protocol byte in the= data channel open message? And the W3C API "protocol" should be set as BFC= P? Again: there is no protocol byte... It is a string and is is the subprotoco= l... > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D > =20 > Secondly, in draft-ietf-rtcweb-data-channel-07, section 8 defines the fol= lowing PPIDs > +------------------------------------+-----------+-----------+ > | Value | SCTP PPID | Reference | > +------------------------------------+-----------+-----------+ > | WebRTC String | 51 | [RFCXXXX] | > | WebRTC Binary Partial (Deprecated) | 52 | [RFCXXXX] | > | WebRTC Binary | 53 | [RFCXXXX] | > | WebRTC String Partial (Deprecated) | 54 | [RFCXXXX] | > +------------------------------------+-----------+-----------+ > =20 > Q4: It is confusing what is the intention to define "WebRTC Binary Partia= l" and "WebRTC String Partial". I guess these two PPIDs are provided to the= application in the case when application supports fragmentation of large m= essages. But, at the meantime, in this draft, section 6.6 also says: The us= age of the PPIDs "WebRTC String Partial" and "WebRTC Binary Partial" is dep= recated. Why the usage is deprecated? Does this implies that SCTP layer is = responsible for fragmentation of large messages, and it is unnecessary for = the upper application to implement the fragmentation of large messages? Section 6.6 explains it: The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary Partial" = is deprecated. They were used for a PPID based fragmentation and reassembly= of user messages belonging to reliable and ordered data channels. > =20 > Q5: Since PPID 52 and 54 are defined, then how can the browser know wheth= er the data sent from the upper application layer is a part of a whole mess= age and the SCTP PPID should be signaled as Partial 52/54, or this is a who= le message and should be signaled as 51/54? The PPIDs 52 and 54 were intended to implement fragmentation/reassembly ins= ide the data channel implementation. This is how it is implemented in Firefox. There is now way to access it fro= m the JS API. However, the usage is deprecated and therefore you don't need to implement = it. > =20 > Q6: if one side wants to send two messages, and the application split the= first big message to two packages, then the browser will send three SCTP p= ackages whose PPID are 54(part of first message), 51(part of first message)= , 51(the whole second message) respectively. When the receiver side receive= s these three SCTP packages, how can the receiver side know which two SCTP = packages can be assembled to get the first big message? It worked only for ordered reliable data channels. So the sequence was used= . Once you got PPID 51, the message is complete. > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D > =20 > The last question, which I have asked in previous email and have not rece= ived any response until now, so I mention this question again. > in draft-ietf-rtcweb-data-channel-07, Section 4 says: > Req. 4: The application SHOULD be able to provide guidance as to > the relative priority of each data channel relative to each > other, and relative to the media streams. This will > interact with the congestion control algorithms. > =20 > And in draft-ietf-rtcweb-data-protocol-03, DATA_CHANNEL_OPEN Message is d= efined as below > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Type | Channel Type | Priority | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reliability Parameter | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Label Length | Protocol Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ / > | Label | > / \ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ / > | Protocol | > / \ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Priority: 2 bytes (integer) > The priority of the channel as described in > [I-D.ietf-rtcweb-data-channel]. The higher the number, the lower > the priority. > =20 > Q7: It seems that for now there is no W3C API parameters to set the prior= ity of data channel. I wonder whether the priority of the data channel is o= pen to the application or is only decided by the browser. In other words, I= want to know how the application be able to provide guidance as to the pri= ority. You are right. The W3C API does not cover the priority yet. My understandin= g is that this is missing and needs to be added. I expect that the priority= is settable via the JS API. Best regards Michael > =20 > Best Regards, > =20 > Jessie > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Feb 21 05:21: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 B82D01A00E2 for ; Fri, 21 Feb 2014 05:21:06 -0800 (PST) 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_DE=0.35] 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 hQQfGpMlqr9S for ; Fri, 21 Feb 2014 05:21:03 -0800 (PST) Received: from mailms.fh-muenster.de (mail.fh-muenster.de [212.201.120.190]) by ietfa.amsl.com (Postfix) with ESMTP id 751841A00B8 for ; Fri, 21 Feb 2014 05:21:02 -0800 (PST) Received: from [192.168.1.200] (p508F101C.dip0.t-ipconnect.de [80.143.16.28]) (Authenticated sender: tuexen) by mailms.fh-muenster.de (Postfix) with ESMTPSA id 8967628174D; Fri, 21 Feb 2014 14:20:54 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Fri, 21 Feb 2014 14:20:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0693106D-71EA-4580-8CA2-E070F28E464A@lurchi.franken.de> References: <9782EE1D-7FF3-4F6B-BCDF-37C143770E96@lurchi.franken.de> To: Lijing (Jessie) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vcEdNJf0Fb8dpNG-82idW5F2Ngo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on data channel related 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, 21 Feb 2014 13:21:07 -0000 On Feb 21, 2014, at 10:21 AM, Lijing (Jessie) = wrote: > Hi, >=20 > Thanks a lot to Michael's interpretation, and it is really helpful. >=20 > Two more issues to be discussed: > 1. I am still not quite sure what "PPID based fragmentation and = reassembly " is. Does it mean SCTP performs segmentation and reassembly = based on the path MTU? Or it refers to other method or protocols? SCTP performs fragmentation and reassembly as an internal mechanism. = This is not related to the use of the PPID. The "PPID based fragmentation and reassembly" is implemented on top of = SCTP, but below the JS API. So it is NOT done by the Javascript application. When using NDATA, the PPID stuff is not necessary, since fragmentation = and reassembly will be done by SCTP without monopolizing any stream. >=20 > 2. The priority of data channel involves two aspects, one aspect is = priority of one data channel compared with priority of other data = channels, and the other aspect is priority of one data channel compared = with audio and video media stream tracks. If the data channel priority = is settable via JS API, then the audio and video priority should also be = set via JS API in a way. I think the priority should be set considering = all the media types including audio, video and data channel. I agree completely. And there is currently also no way of specifying a = priority for the media streams. However, this is an issue for W3C... Best regards Michael >=20 > BR, > Jessie > -----Original Message----- > From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 > Sent: Friday, February 21, 2014 6:13 AM > To: Lijing (Jessie) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Comments on data channel related drafts >=20 > On Feb 19, 2014, at 12:07 PM, Lijing (Jessie) = wrote: >=20 >> Hi, >>=20 >> Several comments on data channel related drafts. >>=20 >> Firstly, There are several "protocol" concepts appeared in different = data channel related drafts, and it seems there is no clear statement = about the relationship between these concepts. >>=20 >> draft-ietf-rtcweb-data-protocol has two protocol concept: >> 1. The protocol byte in data channel open message defined as the = protocol for the channel. >> 2. SCTP payload protocol identifier (PPID) >>=20 >> WebRTC W3C API has one protocol concept, 3. Protocol defined as=20 >> "Subprotocol name used for this channel" >>=20 >> Q1: is the W3C API parameter "protocol" be the same as the protocol = byte in the data channel open message? > Correct. The DOMString protocol provided in the W3C API in negotiated = in the DATA_CHANNEL_OPEN message as the protocol field. Please note that = the Protocol field in the DATA_CHANNEL_OPEN message is not a byte, but a = string. >>=20 >>=20 >> In previous email discussion, Peter Thatcher said : >> "The PPID isn't exposed to the application. It's just used to >> distinguish text/binary/control. If an application uses different >> data channels with different protocols, it should use the SID to = distinguish between them, not the PPID. In fact, even if it wanted to = use the PPID, it wouldn't be able to." > Data channels are identified by the SID on the wire, which corresponds = to the id field in the W3C API. > The JS API has no access to the PPID. >>=20 >> Q2: if the answer of Q1 is yes. Then an application can distinguish = different data channels with different protocols by the protocol byte in = the data channel open message. Is my understanding right? > Not sure what the application is. The W3C API lets you distinguish the = data channels, since you have different objects for it. >>=20 >> draft-ejzak-mmusic-data-channel-sdpneg provides a way to negotiate = sub-protocol parameters out of band. >> 4. Sub-protocol: The 'sub-protocol' parameter indicates which = protocol the client expects to exchange via the channel.=20 >> example: a=3Ddcmap:5000 stream=3D2;label=3D"channel 2";=20 >> subprotocol=3D"BFCP";max_retr=3D3 >>=20 >> Q3: is this "subprotocol" be the same concept as the protocol byte in = the data channel open message? And the W3C API "protocol" should be set = as BFCP? > Again: there is no protocol byte... It is a string and is is the = subprotocol... >>=20 >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =3D=3D >>=20 >> Secondly, in draft-ietf-rtcweb-data-channel-07, section 8 defines the = following PPIDs >> +------------------------------------+-----------+-----------+ >> | Value | SCTP PPID | Reference | >> +------------------------------------+-----------+-----------+ >> | WebRTC String | 51 | [RFCXXXX] | >> | WebRTC Binary Partial (Deprecated) | 52 | [RFCXXXX] | >> | WebRTC Binary | 53 | [RFCXXXX] | >> | WebRTC String Partial (Deprecated) | 54 | [RFCXXXX] | >> +------------------------------------+-----------+-----------+ >>=20 >> Q4: It is confusing what is the intention to define "WebRTC Binary = Partial" and "WebRTC String Partial". I guess these two PPIDs are = provided to the application in the case when application supports = fragmentation of large messages. But, at the meantime, in this draft, = section 6.6 also says: The usage of the PPIDs "WebRTC String Partial" = and "WebRTC Binary Partial" is deprecated. Why the usage is deprecated? = Does this implies that SCTP layer is responsible for fragmentation of = large messages, and it is unnecessary for the upper application to = implement the fragmentation of large messages? > Section 6.6 explains it: >=20 > The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary = Partial" is deprecated. They were used for a PPID based fragmentation = and reassembly of user messages belonging to reliable and ordered data = channels. >>=20 >> Q5: Since PPID 52 and 54 are defined, then how can the browser know = whether the data sent from the upper application layer is a part of a = whole message and the SCTP PPID should be signaled as Partial 52/54, or = this is a whole message and should be signaled as 51/54? > The PPIDs 52 and 54 were intended to implement = fragmentation/reassembly inside the data channel implementation. > This is how it is implemented in Firefox. There is now way to access = it from the JS API. > However, the usage is deprecated and therefore you don't need to = implement it. >>=20 >> Q6: if one side wants to send two messages, and the application split = the first big message to two packages, then the browser will send three = SCTP packages whose PPID are 54(part of first message), 51(part of first = message), 51(the whole second message) respectively. When the receiver = side receives these three SCTP packages, how can the receiver side know = which two SCTP packages can be assembled to get the first big message? > It worked only for ordered reliable data channels. So the sequence was = used. Once you got PPID 51, the message is complete. >>=20 >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =3D=3D=3D >>=20 >> The last question, which I have asked in previous email and have not = received any response until now, so I mention this question again. >> in draft-ietf-rtcweb-data-channel-07, Section 4 says: >> Req. 4: The application SHOULD be able to provide guidance as to >> the relative priority of each data channel relative to = each >> other, and relative to the media streams. This will >> interact with the congestion control algorithms. >>=20 >> And in draft-ietf-rtcweb-data-protocol-03, DATA_CHANNEL_OPEN Message = is defined as below >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Message Type | Channel Type | Priority | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reliability Parameter | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Label Length | Protocol Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> \ / >> | Label | >> / \ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> \ / >> | Protocol | >> / \ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Priority: 2 bytes (integer) >> The priority of the channel as described in >> [I-D.ietf-rtcweb-data-channel]. The higher the number, the = lower >> the priority. >>=20 >> Q7: It seems that for now there is no W3C API parameters to set the = priority of data channel. I wonder whether the priority of the data = channel is open to the application or is only decided by the browser. In = other words, I want to know how the application be able to provide = guidance as to the priority. > You are right. The W3C API does not cover the priority yet. My = understanding is that this is missing and needs to be added. I expect = that the priority is settable via the JS API. >=20 > Best regards > Michael >>=20 >> Best Regards, >>=20 >> Jessie >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 From nobody Fri Feb 21 08:27: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 2395C1A04B6 for ; Fri, 21 Feb 2014 08:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 aJHXXuHeFgg3 for ; Fri, 21 Feb 2014 08:27:45 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E7C4C1A048B for ; Fri, 21 Feb 2014 08:27:44 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-06-53077e7c81a7 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 55.32.10875.C7E77035; Fri, 21 Feb 2014 17:27:40 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.2.347.0; Fri, 21 Feb 2014 17:27:39 +0100 Message-ID: <53077E7B.1070900@ericsson.com> Date: Fri, 21 Feb 2014 17:27:39 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" , X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNJMWRmVeSWpSXmKPExsUyM+JvjW5NHXuwQcstMYurM5YwW6z9187u wOSxZMlPJo8vlz+zBTBFcdmkpOZklqUW6dslcGX0925nLtjkULFkcj97A+M/oy5GDg4JAROJ 3j/VXYycQKaYxIV769m6GLk4hAQOMUrseHSFGcJZzijRsn4nG0gVr4C2xKd1RxhBbBYBVYkr Vz8zg9hsAhYSN380gtWICgRL7DzwmxGiXlDi5MwnLCC2iECUxLT3t8HiwgJmEht2TWOCOEJc oqcxCCTMLKAnMeVqCyOELS/RvHU22HghoLUNTR2sExj5ZyGZOgtJyywkLQsYmVcxsucmZuak lxtuYgQG2MEtv3V3MJ46J3KIUZqDRUmc98Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jA73QibaPWMXnyHNsHhO9vyqu8GZBnmmk/os91wMSlupfP9j++95r06XssSdTvn48Wl3UM6p 1NOFnGX/dJZ0H+zKbFyQIpxhsGTnabd5YU23vz6ymi50fMLk73O1dA90SRdO6NMoWFa8tu9+ wfZfVRk3LuutnyI0614crwxD8lP9e4eWVjYpKiqxFGckGmoxFxUnAgDBRM73/gEAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uzsHvuJp85MQI1wvXw3D3TjxvAI Subject: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 21 Feb 2014 16:27:48 -0000 Hi, (as individual) I have reviewed the WebRTC Data Channels draft (draft-ietf-rtcweb-data-channel-07) and have some comments. 1. Section 1: Non-media data types in the context of WebRTC are handled by using SCTP [RFC4960] encapsulated in DTLS [RFC6347]. There are many places in this draft where "media data" is a reference to the RTP transport media. I would suggest to review this and consider to change this to "RTP Transport media", or "RTP media". The reason is that I expect also real-time media to flow over the data channel. 2. Section 1: As the other SCTP extensions are discussed in the introduction, I wonder why NADA and PR-Policy isn't. 3. Section 1: Section 5 arguments SCTP over DTLS over UDP; "arguments" looks strange in the above sentence fragment. 4. Section 3.1: Note that at any time there may be no media channels, or all media channels may be inactive, and that there may also be reliable data channels in use. "no media channels" is a bit strange here as we not really call anything regarding RTP channels. I would suggest to change this to "RTP Packet Streams" or "RTP Stream". 5. Section 3.2: U-C 7: Proxy browsing, where a browser uses data channels of a PeerConnection to send and receive HTTP/HTTPS requests and data, for example to avoid local Internet filtering or monitoring. >From a data channel perspective this doesn't look strange at all, however I get the shivers from the security implications of this. To my understanding Peer A using Peer B to proxy browse must have B fetch all elements that A needs into its sandbox and then transfer it to A over the PeerConnections Data Channel. Thus, all you do are revealed to B, massive privacy consideration. Or am I missing someway that A can tunnel its HTTP request through B without having B see the content of those requests, I am especially concerned with HTTPS. If this use case is going to stay, I do want some security consideration discussion around it. 6. Section 5: " o The congestion control is modifiable for integration with media stream congestion control." As this statement is only partial correct. There is no current mechanism to negotiate congestion control, nor does it exist any alternative defined SCTP congestion control. Thus, I would like to have this sentence modified. I am however not certain to what the authors consider important. It is the fact that it is possible in the future to define a new CC algorithm and use that? 7. Section 5: o provides privacy for the SCTP control information. Is "privacy" really the right word here? Either being explicit, "source authentication, integrity and confidentiality" or something like "security"? 8. section 5: DTLS implementations used for this stack SHOULD support controlling fields of the IP layer like the Don't Fragment (DF)-bit in case of IPv4 and the Differentiated Services Code Point (DSCP) field required for supporting [I-D.ietf-rtcweb-qos]. First of all this reference must be changed. What I am currently uncertain of is what it should point on, most likely draft-dhesikan-tsvwg-rtcweb-qos-04. But, I am not yet certain how the scope is going to be divided between that document and draft-ietf-rtcweb-transports. 9. Section 5: The initial Path MTU at the IP layer MUST NOT exceed 1200 bytes for IPv4 and 1280 for IPv6. I have to say that I think MUST NOT in the above is to strict. I think SHOULD NOT is appropriate. The reason is that a deployment may actually know that a larger initial MTU is better. This value may also change due to how the networks develop in the future. 10. Section 5: Since SCTP does not support the negotiation of a congestion control algorithm yet, alternate congestion controls SHOULD either only require a different sender side behavior using existing information carried in the association or need also specify a negotiation of of a congestion control algorithm. First of all I don't like the SHOULD in this sentence. Secondly, I think we need to get a good agreement and statement what to do with SCTP's congestion control algorithm in the future. I don't like this statement saying basically agree on anything and use that. I think the IETF specification should specify something to use that we know is safe to deploy. Thus, I would strongly prefer this to simply to be changed to say that: We know we want a new congestion control that better can handle interaction the the RTP packet streams and its congestion control, but that will not be initially available. Thus use the specified congestion control and consider these issues. And if a new CC algo becomes available that can be used and should be negotiated between the endpoints somehow. 11. Section 6.1: Once support for message interleaving as currently being discussed in [I-D.ietf-tsvwg-sctp-ndata] is available, it SHOULD be supported. I don't know why you have formulated this, so awkward? NDATA is currently listed as a normative reference. This document is going to hand in the RFC-editor queue until it becomes available or an AD orders some rewriting. Thus, why not simply write a simpler statement making clear that one SHOULD support it. I would also note that there are disagreement between this and the text in Section 6.6.: To overcome this limitation, [I-D.ietf-tsvwg-sctp-ndata] defines an extension to support message interleaving. Once this extension is available, it MUST be used. Thus pick the level of requirement and then simply state that with the motivation why. Personally I think SHOULD would be acceptable. There are clear motivation why (in 6.6) why one SHOULD implelement it, and the basic functionality is still there if it is not supported and its usage will be negotiated as SCTP association creation. 12. Section 6.2: Additionally, the negotiation SHOULD include some type of congestion control selection. Another congestion control statement that I am not happy with. See issue 10. There is no default and it is also not clear on what to really negotiate. 13. Section 6.3: SCTP defines a stream as a unidirectional logical channel existing within an SCTP association one to another SCTP endpoint. The "one" looks spurious. 14. Section 6.4: These priorities MUST NOT be strict priorities. Ok, this is one part of the agreement from the earlier meeting. There was also agreement on using weighted fair queuing to solve the priorities. The inter stream priority handling needs much firmer specification. 15. Section 6.5: "This can be based on the DTLS role (the client picks even stream identifiers, the server odd stream identifiers) or done in a different way." This is very unclear and you can't know what will happen. I think it would be better to say: Unless otherwise defined or negotiated, the streams are picked based on th DTLS role. ... 16. Section 6.5: "In addition to choosing a stream, the application SHOULD also inform the protocol of the options to use for sending messages." So what is the application, and what is the protocol in this sentence? 17. Section 7. I find this insufficient. I would this section to answer the following questions: 1. Any security issues that arise from the combination of mechanism. 2. Any significant issue that one needs to know about the behavior of the mechanisms, any of the normative specs that should be highlighted? 3. Clarification on what security properties one achieve with the defined mechanism. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Feb 21 09: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 8A1FF1A02D0 for ; Fri, 21 Feb 2014 09:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.797 X-Spam-Level: X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FREEMAIL_FROM=0.001, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 fnfczqqlxbZt for ; Fri, 21 Feb 2014 09:34:02 -0800 (PST) Received: from mail-wg0-x233.google.com (unknown [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 089AC1A01DC for ; Fri, 21 Feb 2014 09:34:01 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id n12so2709929wgh.18 for ; Fri, 21 Feb 2014 09:33:57 -0800 (PST) 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=V4WZH1KYk62iVfQJu4SN7BbQU4+4ePAi7VajdpDk4WM=; b=gAIhJFNeQOO4Yfir3/n78C6pW4zbGiKXn4x9g+V90eLbmEbgTJQ+nrq54q1Mn0n+3n rFVOiWDLBdrXhtjHjBkSdj2d83eK4/oOZMm/YrfPel3dStsAASw9GDeRRM/POOeN+7Xd eZ9VloGEie3VKUFtNwJHB/DIBsL9UAhTQF1/YiHynJBJXh1iTddern73muLUqnEs3s1I 3Xzh4d4LqKQGA+OvNG9V7K+L2OXbxuD1/Zo1aWn40L+9G0U1K8uvx3uAien0cb5DSf8z 0kd0xmXlPGC4GHiTCIXDjy2ai8377WvUEyeE5ifnt09FgVB4dGd0B69RvnAxg3KJhaS+ 98Ow== MIME-Version: 1.0 X-Received: by 10.194.110.41 with SMTP id hx9mr8428107wjb.28.1393004037356; Fri, 21 Feb 2014 09:33:57 -0800 (PST) Received: by 10.227.10.196 with HTTP; Fri, 21 Feb 2014 09:33:57 -0800 (PST) In-Reply-To: <530627C7.30906@ericsson.com> References: <530627C7.30906@ericsson.com> Date: Fri, 21 Feb 2014 09:33:57 -0800 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XfdUbPhYDW2CmIkXEcYIgMZXXpU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 21 Feb 2014 17:34:03 -0000 On 20 February 2014 08:05, Magnus Westerlund wrote: > When I read this section, my immediate question was, doesn't RTP need > corresponding protection. To my understanding, the answer would be yes, > but it is more difficult to inject data and get a certain plaintext even > without the SRTP encryption scrambling the payload part. Still, that > assumes that an JS application, can write the payload data itself. > Secondly, it does assume that one MUST use encryption in SRTP. Yes, with WebAudio, I can construct an SRTP packet that contains ciphertext that I can control, assuming that I know the session keys (yes), and I'm prepared to do a lot of work. SRTP doesn't have the IV per-packet that DTLS does. What you can't do is make it look like a non-SRTP packet, the first byte, length and MAC would be extremely difficult to control (for the MAC, that's more or less the point...), if not impossible. So the question is, is there an intermediary that might be tricked into interpreting an SRTP packet in a way that might have negative consequences. When masking was added to websockets, it was because the confusion was demonstrated as being possible: intermediaries were searching for HTTP requests and responses in ways that were easily exploited and then caching the results. To a large extent, that attack relied on the fact that TCP is a stream-based protocol - it didn't matter where the request appeared. In this case, the mapping of SRTP onto UDP doesn't really lead to intermediaries looking for goodies inside packets. I'm not going to say that there is a risk, but I think that I'd be willing to take the risk given the plethora of mitigating circumstances here. From nobody Fri Feb 21 17:03: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 531601A032A for ; Fri, 21 Feb 2014 17:03:06 -0800 (PST) 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 XCX4ALWiiAtl for ; Fri, 21 Feb 2014 17:03:04 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0B84F1A030A for ; Fri, 21 Feb 2014 17:03:03 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id rl12so1908371iec.15 for ; Fri, 21 Feb 2014 17:03:00 -0800 (PST) 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=tUP63XwQv+XzLNhuHhzjAyvHZBROGybJS9KMMb9jWKI=; b=Ge6keScWOl5A6HlGj/hovRXcGOMBlpPIGTzurdG6xwJ5H+mCOyNNlbq06ZjC4x3X+u q4U5Dz+IPqNcwcGEDMEOzCSgI9+0fvo1FWY3qHyBEQJ52/dEMp9YQItBepV9UU1W1KcK Zkzv4IdtFGFTucIDSUU8p49TuFQsn04GPRpXapUv/ejsQmzJJSfQpHWrqAVks1fNDNKZ Kg4XMGUjJymsaX2mAccDqQiyD2OePGb82KdMay8C+SzgIOIyX4/2pCqAp+yNjc5RT1q3 5VW7oStJWQCOQix7xTTk0uLM0gSJYj5BG9GJk4FM6us3UHE7Dtr+REZCpczQQrL1bEtW RvTw== MIME-Version: 1.0 X-Received: by 10.42.228.65 with SMTP id jd1mr5102878icb.62.1393030979907; Fri, 21 Feb 2014 17:02:59 -0800 (PST) Received: by 10.42.237.206 with HTTP; Fri, 21 Feb 2014 17:02:59 -0800 (PST) In-Reply-To: <53070996.9040707@ericsson.com> References: <530627C7.30906@ericsson.com> <53070996.9040707@ericsson.com> Date: Fri, 21 Feb 2014 17:02:59 -0800 Message-ID: From: Ted Hardie To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a1132e4ccb7f6a004f2f44c4b Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HxRSAC2smZYi_0EXWrYXmHPV0_s Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 22 Feb 2014 01:03:06 -0000 --001a1132e4ccb7f6a004f2f44c4b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Feb 21, 2014 at 12:08 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-02-20 18:13, Ted Hardie wrote: > > On Thu, Feb 20, 2014 at 8:05 AM, Magnus Westerlund > > = > > > wrote: > > > > Hi, > > > > I think a potential issue that isn't discussed in this document is > the > > security threat of driving data volumes into a network beyond ones > > "fair" share. This would simply be to illustrate that communication > > consent is not sufficient, to protect other users of a shared netwo= rk > > the WebRTC endpoint MUST prevent transmission of data volumes far > > outside of the fair share. > > > > > > > > Magnus, I'm not sure why you think that issue should be dealt with in > > this document. > > This document should deal with cases where a malicious script could sen= d > > transmissions > > that are not intended or not welcome. Bbut managing network capacity > > for *intended* > > and *welcome* transmissions is not a security concern. It's a > > congestion management > > issue, at least as I see it. > > > > Am I missing something about your concern? > > > > My concern is that a malicious individual wants to DDoS a particular > network. I buy AD time from on of the network or in any other way ensure > that the mailicious JS identifies when each client is topologically > right for me to connect it to another client to drive traffic through my > targets network. Then I ensure these clients establish a peer connection > and I try to blast as much traffic through the network as possible. Sorry for my apparent failure to understand here, but we're still dealing with traffic to which the parties consent, right? That is, you're thinking of malicious JS that sends channels worth of nonsense to blast the network while something the user cares about happens? (Two-player flappy bird but with a terrabit of nonsense screaming in the background?) > From > the point of the attack this doesn't matter if is real-time media or > data traffic. The point is to drive as much traffic into the network as > possible. From that perspective any traffic that is sent in the context > of a peerconnection needs to be congestion controlled. That at least > keeps the traffic down to a "fair" share. > > We are mitigating this attack, however what I was really wondering over > is if the security considerations document should make note that lack of > appropriate congestion control is a security vulnerability and enables > certain type of load attacks. > > So my take as an individual is that congestion control is a known desirable property, and that we're addressing its lack as we can. Adding that note t= o the security document doesn't seem to me to add much to this story. Ted > Does this make my concern clearer? > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --001a1132e4ccb7f6a004f2f44c4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 21, 2014 at 12:08 A= M, Magnus Westerlund <magnus.westerlund@ericsson.com><= /span> wrote:
O= n 2014-02-20 18:13, Ted Hardie wrote:
> On Thu, Feb 20, 2014 at 8:05 AM, Magnus Westerlund
> <magnus.wes= terlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>>
> wrote:
>
> =A0 =A0 Hi,
>
> =A0 =A0 I think a potential issue that isn't discussed in this doc= ument is the
> =A0 =A0 security threat of driving data volumes into a network beyond = ones
> =A0 =A0 "fair" share. This would simply be to illustrate tha= t communication
> =A0 =A0 consent is not sufficient, to protect other users of a shared = network
> =A0 =A0 the WebRTC endpoint MUST prevent transmission of data volumes = far
> =A0 =A0 outside of the fair share.
>
>
>
> Magnus, I'm not sure why you think that issue should be dealt with= in
> this document.
> This document should deal with cases where a malicious script could se= nd
> transmissions
> that are not intended or not welcome. =A0Bbut managing network capacit= y
> for *intended*
> and *welcome* transmissions is not a security concern. =A0It's a > congestion management
> issue, at least as I see it.
>
> Am I missing something about your concern?
>

My concern is that a malicious individual wants to DDoS a parti= cular
network. I buy AD time from on of the network or in any other way ensure that the mailicious JS identifies when each client is topologically
right for me to connect it to another client to drive traffic through my targets network. Then I ensure these clients establish a peer connection and I try to blast as much traffic through the network as possible.

Sorry for my apparent failure to understand here, but we're still = dealing with
traffic to which the parties consent, right?=A0 That is, you're thinkin= g of malicious
JS that sends channels worth of nonsense to blast the network= while something
the user cares about happens? (Two-player flappy bird but with a terrabit o= f nonsense
screaming in the background?)

=A0
From
the point of the attack this doesn't matter if is real-time media or data traffic. The point is to drive as much traffic into the network as
possible. From that perspective any traffic that is sent in the context
of a peerconnection needs to be congestion controlled. That at least
keeps the traffic down to a "fair" share.

We are mitigating this attack, however what I was really wondering over
is if the security considerations document should make note that lack of appropriate congestion control is a security vulnerability and enables
certain type of load attacks.


So my take as an individual is that congestion control is a= known desirable
property, and that we're addressing its lack as we = can.=A0 Adding that note to
the security document doesn't seem to me to add much to this story.
=
= Ted


=A0
Does this make my concern clearer?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--001a1132e4ccb7f6a004f2f44c4b-- From nobody Fri Feb 21 17:14: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 A34681A032A for ; Fri, 21 Feb 2014 17:14:49 -0800 (PST) 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 42BEw6OVtAfW for ; Fri, 21 Feb 2014 17:14:47 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9BC1A032E for ; Fri, 21 Feb 2014 17:14:47 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id u56so3130555wes.31 for ; Fri, 21 Feb 2014 17:14:43 -0800 (PST) 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=EaSpQMHFrjSFVqzqTdWKEuEc2fEPENk2pSoshclfkx0=; b=ULIFPPPAnJYFh2Km564N36KOLdr7pdUikSl5KjEfeyRitlrsPKOnwRC927QBZnli82 94IvJ9LT95FKvxLbSQiDeGYXtfB7OmkZWlPI6p/AQ9Q7BKz4sGeal+YqqciTSEZOz/vO nre7T2BPHr/WG1ezjLnb/1b1L9cSQzHTTtqLj99xaDUhVYBwJ20e7+Wwr02FMbI8XKaX WoP1HdpxLZk4OIW/emb0BoiyVL6eicGoVyeyJIr/Z1JWAu/GTN1VnyA5L2YeOaRNElUL tZj7X1TKBFqnFnhdSP+eos1hI3NDwox3vnc/RrxfeTL8rB0z6/aKoYnpjdTlnBsgnB1W M+sg== MIME-Version: 1.0 X-Received: by 10.194.110.41 with SMTP id hx9mr9747347wjb.28.1393031682964; Fri, 21 Feb 2014 17:14:42 -0800 (PST) Received: by 10.227.10.196 with HTTP; Fri, 21 Feb 2014 17:14:42 -0800 (PST) In-Reply-To: References: <530627C7.30906@ericsson.com> <53070996.9040707@ericsson.com> Date: Fri, 21 Feb 2014 17:14:42 -0800 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/40J3d3LNtuDd5hW2AFBSAMqXt6g Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 22 Feb 2014 01:14:49 -0000 On 21 February 2014 17:02, Ted Hardie wrote: > Sorry for my apparent failure to understand here, but we're still dealing > with > traffic to which the parties consent, right? That is, you're thinking of > malicious > JS that sends channels worth of nonsense to blast the network while > something > the user cares about happens? (Two-player flappy bird but with a terrabit of > nonsense > screaming in the background?) Maybe Magnus is looking for the mechanism described in http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00, which might allow for control below the limit that the congestion control permits. I basically abandoned this, because it's small potatoes. It's trivial to revoke consent if you notice a misbehaving peer and then you only have to wait until the consent timer runs out on the sender. 30s. From nobody Sat Feb 22 16: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 B11E71A0213 for ; Sat, 22 Feb 2014 16:20:13 -0800 (PST) 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 9ATzmDkjlh7q for ; Sat, 22 Feb 2014 16:20:12 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id AF73F1A020F for ; Sat, 22 Feb 2014 16:20:11 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta15.westchester.pa.mail.comcast.net with comcast id VcFV1n0050ldTLk5FcL6Me; Sun, 23 Feb 2014 00:20:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id VcL61n00M3ZTu2S01cL6Ny; Sun, 23 Feb 2014 00:20:06 +0000 Message-ID: <53093EB6.5080500@alum.mit.edu> Date: Sat, 22 Feb 2014 19:20:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393114807; bh=JAqBtS+m6Ro8KnA6bWEbf/9NqwELCLM7nrEwXBcnAkA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GohEMtF9eMUnobd6NwCQSP1vrJEtTIJaCyfRv8pTtd39td5a44C6rQC73qnRfmWy/ oPifg4+VoXcjR4cXE5avq1mHh7n6/cuwzq+7uQwXs/e4YH1vEvg45bb3Dc1cGPzeo9 dx4GmIWwBdfgyqYW9B3eIEaIEh2fvDlaOILbeEzz5Cqc/hb2BWb+TQZXSP0VGoyJqK PhExgo1eph6aLDHHEpmCA7u+HFb34v8VA+LoLkymzE/QP36orXsExzes8K8anaCRp8 +LsURpzqT3KjchVGLAYXcLRoySZKeL9GbvYTwXcConHTs+K39CmU15dnKMx785xFJJ Ezp6YYylkvHJg== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HFf-OY4P4ke8iTsdxAvgsfaEbk0 Subject: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 23 Feb 2014 00:20:14 -0000 (Catching up before the meeting) Here are some comments on the latest version. There don't necessarily relate to recent changes. Rather they come from my perspective trying to use this for CLUE, whether using a webrtc endpoint or not. * Section 5: This section says: Each SCTP user message contains a so called Payload Protocol Identifier (PPID) that is passed to SCTP by its upper layer and sent to its peer. This value can be used to multiplex multiple protocols over a single SCTP association. The sender provides for each protocol a specific PPID and the receiver can demultiplex the messages based on the received PPID. The PPID is used to distinguish UTF-8 encoded user data and binary encoded userdata. The Data Channel Establishment Protocol defined in [I-D.ietf-rtcweb-data-protocol] uses also a specific PPID to be distinguished from user data. The language has proved extremely confusing to several people who haven't followed the development and discussion of this from the beginning. It is because of the extreme ambiguity in the use of "protocol". While I guess we can't rename PPID, the other language could be clarified. The problem is that we have SCTP protocol, "WebRTC Data Channel Establishment Protocol", and within the DATA_CHANNEL_OPEN message of the WebRTC Data Channel Establishment Protocol we have a "Protocol" field. We also have layering of protocols and implementations. So it isn't clear above who "sender" and "receiver" above apply to. (Could be code that is calling the SCTP stack, or code that is calling the "data channel stack", or the browser, or a javascript application on top of browser. IIUC, javascript users don't have any visibility to the PPID. But others implementing data channels may. How about: Each SCTP user message contains a so called Payload Protocol Identifier (PPID) that is passed to SCTP by the data channel layer and sent to its peer. This value is used to multiplex WebRTC Data Channel Establishment Protocol messages (defined in [I-D.ietf-rtcweb- data-protocol]) with messages containing user data on a data channel. The PPID is also used to distinguish UTF-8 encoded user data and binary encoded user data. Also in this section is Figure 2 that shows layering. I'm unclear if "WEBRTC DATA" in intended to include rtcweb-data-protocol or not. That is defined in a separate draft, is mandatory to support but optional to use. So it could go either way. Might be good to clarify: +---------+ |CHANNEL | |PROTOCOL | +---------+ |DATA | |CHANNEL | +---------+ | SCTP | +-----------------------+ | STUN | SRTP | DTLS | +-----------------------+ | ICE | +-----------------------+ | UDP1 | UDP2 | ... | +-----------------------+ * Section 6.5 This section contains: Data channels can be opened by using internal or external negotiation. The details are out of scope of this document. A simple protocol for internal negotiation is specified in [I-D.ietf-rtcweb-data-protocol] and MUST be supported. But internal and external negotiation are not defined in this document. I *thought* that internal negotiation was by definition negotiation by use of rtcweb-data-protocol. (draft-ejzak-mmusic-data-channel-sdpneg-00 thinks so too, but calls it "in-band negotiation".) There should be a good definition of these terms, or reference to one. And more discussion if there can be other kinds of internal negotiation. (If so, how would one be chosen?) * Section 6.6: Say: All data sent on a Channel in both directions MUST be sent over the underlying stream using the reliability defined when the Channel was opened unless the options are changed, or per-message options are specified by a higher level. Is the recipient to consider it an error if messages are received with options different from those defined for the channel? Also, is it an error if messages are received with a PPID that isn't specified in Section 8? (And what about PPID 50?) How are such channel errors to be treated? Thanks, Paul From nobody Sat Feb 22 19:07: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 82FA41A0285 for ; Sat, 22 Feb 2014 19:07:08 -0800 (PST) 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 RMwjMNpnh1P0 for ; Sat, 22 Feb 2014 19:07:07 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id CB28B1A0281 for ; Sat, 22 Feb 2014 19:07:06 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta15.westchester.pa.mail.comcast.net with comcast id Veus1n0071wpRvQ5Ff72sp; Sun, 23 Feb 2014 03:07:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id Vf711n00R3ZTu2S3ef72qJ; Sun, 23 Feb 2014 03:07:02 +0000 Message-ID: <530965D5.9090105@alum.mit.edu> Date: Sat, 22 Feb 2014 22:07:01 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393124822; bh=WLrFjvM17cDtN3qP/Gjo5g0rDe0hiOmzXaxXydjUihA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=G1LB6vuyGk4d/8IUzpne43qkYJlTE5sMgrjjFV2KDsGElXvYkXxhFx+PHwegr8bhS PU1UyOeNvEmpIpAg5D86SI267Mys+xaI1X5rWOtdwmjduc0sHr7PhnKdFTizb94UPD cikGlP9XKfzHd1HrfxXk37zxT+XMQlXJ2dvqK9l+filGFO+LB4wQT8C05dPzs9+xzl j5GPDZZdsPMPsFhH5uhqj9inEMd38/qz0531Ss42BSsAsi/SW6mWbMPqWSiX+ZUMv+ L5QbsReugvWtpipxgEkfLbweeHOmdZwpLlA2SfrIHlnbSHotUKnwQXt2A5OcU/IzdZ yWg8Ie+kZqqWg== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BPouNVYuaTTc2Rgh07eCRXKgMko Subject: [rtcweb] Comments on draft-ietf-rtcweb-data-protocol-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 23 Feb 2014 03:07:08 -0000 A few comments on this draft: * Section 5.1: DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel provides a partial reliable in-order bi-directional Communication channel. User messages might not be transmitted or retransmitted after a specified life-time given in milli- seconds in the Reliability Parameter. This life-time starts when providing the user message to the Javascript engine. The last sentence above is troubling. This protocol won't always be used via Javascript. Can we please have a definition that doesn't depend on that? Is the timing being done by SCTP, or are you assuming that a data channel layer on top of SCTP is doing this? Is it specific to SCEP, or is it still applicable when the channel has been established via external negotiation? Does use of this option imply that retransmission continues until this time limit is reached? Or might it stop after some implementation defined number of retransmissions? The description of the reliability parameter says: This field is ignored if a reliable channel is used. IMO folk wisdom says that some specific value (e.g., 0) should be prescribed to be used in such cases. That makes things more deterministic and provides more flexibility in extending the protocol in the future. The name "Protocol" (and "Protocol Length") here is troublesome, because it is ambiguous with other sorts of uses. (See my comment about this point earlier today wrt draft-ietf-rtcweb-data-channel-07.) Others (including draft-ejzak-mmusic-data-channel-sdpneg-00 and websockets) call this "subprotocol". Using that would make it a little less confusing. Also, ISTM that all of these things are applicable to externally negotiated channels, and so ought to be defined by draft-ietf-rtcweb-data-channel. (But of course their use in the DATA_CHANNEL_OPEN message belongs here.) * Section 8.4: ISTM there ought to be a template of the minimum information that the specification for a registered (sub)protocol MUST (SHOULD?) include. E.g., - what Channel Type(s) are valid for this (sub)protocol - A contact for more information about this protocol Thanks, Paul From nobody Sun Feb 23 01:55: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 E79441A0433 for ; Sun, 23 Feb 2014 01:55:15 -0800 (PST) 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_82=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 KHR1oEYIede0 for ; Sun, 23 Feb 2014 01:55:13 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0FD1A002B for ; Sun, 23 Feb 2014 01:55:12 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id z12so3797214wgg.5 for ; Sun, 23 Feb 2014 01:55:07 -0800 (PST) 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=tge0Nf3DpV+z8rH0AVt/lvrmdBWpuWEmQ8PCqSjSSoI=; b=gZwLskQ/+AN9FTdVu4uh5dOQ0G5anz+XsTiUBIxt4Adon6BIaRloIoVdun7DGbnkLz HSfGMuL/AHpGkbZ8roevuDjGna5fOKgeEy4ACrAr0wrEmLXgcGKN3B3la7dt8GNjFBzS XV1QzzxB53Uyi1uAoOhhwWK79HxoIPrcJqvb+CmPnFeob17981WOrtt4eyMdhO0T1DMX XnkUycUDctuSR/9LNm9IQm9Dpooqj7ah/9GAwt3rVMTg2vnVaFaUoNIMJ20vtWJbc9/E vNRwpQV9zd0jWjkRFYnQq28TEIEhDNa2QE2PxviWISVCFsrUPaMRBnY9vmqzjs4Oa674 9+SQ== X-Received: by 10.180.106.40 with SMTP id gr8mr9375541wib.31.1393149307557; Sun, 23 Feb 2014 01:55:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.87.165 with HTTP; Sun, 23 Feb 2014 01:54:47 -0800 (PST) In-Reply-To: <53077E7B.1070900@ericsson.com> References: <53077E7B.1070900@ericsson.com> From: Barry Dingle Date: Sun, 23 Feb 2014 20:54:47 +1100 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=f46d044519a9989f7a04f30fd90f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nekTNB4pJCJflZAa7jc023VlsMo Cc: "rtcweb@ietf.org" , draft-ietf-rtcweb-data-channel@tools.ietf.org Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 23 Feb 2014 09:55:16 -0000 --f46d044519a9989f7a04f30fd90f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In reference to your first *Section 1 comments*, I agree that we need to clearly differentiate the SRTP media and the SCTP media. (Note - SRTP - not RTP !) I agree that there could be real-time media that can be sent over SCTP Channels are still meet the criteria for 'real-time' as being 'received within a few hundred milliseconds of being generated' - see WebRTC Overview section 2.4. Maybe we need to differentiate the Channel types - and then refer to the data going over those Channels. For instance,if we define "SRTP Channels" and "SCTP Channels", we could then refer to 'SRTP Channel media' which would have a specific meaning. The best place for the definition of SRTP Channel and SCTP Channel is probably in the WebRTC Overview document. Cheers, /Barry Dingle On Sat, Feb 22, 2014 at 3:27 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > (as individual) > > I have reviewed the WebRTC Data Channels draft > (draft-ietf-rtcweb-data-channel-07) and have some comments. > > 1. Section 1: > Non-media data types in the context of WebRTC are handled by using > SCTP [RFC4960] encapsulated in DTLS [RFC6347]. > > There are many places in this draft where "media data" is a reference to > the RTP transport media. I would suggest to review this and consider to > change this to "RTP Transport media", or "RTP media". The reason is that > I expect also real-time media to flow over the data channel. > > 2. Section 1: > As the other SCTP extensions are discussed in the introduction, I wonder > why NADA and PR-Policy isn't. > > 3. Section 1: > Section 5 arguments SCTP over DTLS over UDP; > > "arguments" looks strange in the above sentence fragment. > > 4. Section 3.1: > Note that > at any time there may be no media channels, or all media > channels may be inactive, and that there may also be reliable > data channels in use. > > "no media channels" is a bit strange here as we not really call anything > regarding RTP channels. I would suggest to change this to "RTP Packet > Streams" or "RTP Stream". > > 5. Section 3.2: > U-C 7: Proxy browsing, where a browser uses data channels of a > PeerConnection to send and receive HTTP/HTTPS requests and > data, for example to avoid local Internet filtering or > monitoring. > > >From a data channel perspective this doesn't look strange at all, > however I get the shivers from the security implications of this. To my > understanding Peer A using Peer B to proxy browse must have B fetch all > elements that A needs into its sandbox and then transfer it to A over > the PeerConnections Data Channel. Thus, all you do are revealed to B, > massive privacy consideration. Or am I missing someway that A can tunnel > its HTTP request through B without having B see the content of those > requests, I am especially concerned with HTTPS. > > If this use case is going to stay, I do want some security consideration > discussion around it. > > 6. Section 5: > " o The congestion control is modifiable for integration with media > stream congestion control." > > As this statement is only partial correct. There is no current mechanism > to negotiate congestion control, nor does it exist any alternative > defined SCTP congestion control. Thus, I would like to have this > sentence modified. I am however not certain to what the authors consider > important. It is the fact that it is possible in the future to define a > new CC algorithm and use that? > > 7. Section 5: > o provides privacy for the SCTP control information. > > Is "privacy" really the right word here? Either being explicit, "source > authentication, integrity and confidentiality" or something like > "security"? > > 8. section 5: > > DTLS implementations used for this stack SHOULD support controlling > fields of the IP layer like the Don't Fragment (DF)-bit in case of > IPv4 and the Differentiated Services Code Point (DSCP) field required > for supporting [I-D.ietf-rtcweb-qos]. > > First of all this reference must be changed. What I am currently > uncertain of is what it should point on, most likely > draft-dhesikan-tsvwg-rtcweb-qos-04. But, I am not yet certain how the > scope is going to be divided between that document and > draft-ietf-rtcweb-transports. > > 9. Section 5: > > The initial Path MTU > at the IP layer MUST NOT exceed 1200 bytes for IPv4 and 1280 for > IPv6. > > I have to say that I think MUST NOT in the above is to strict. I think > SHOULD NOT is appropriate. The reason is that a deployment may actually > know that a larger initial MTU is better. This value may also change due > to how the networks develop in the future. > > 10. Section 5: > > Since SCTP does not support the > negotiation of a congestion control algorithm yet, alternate > congestion controls SHOULD either only require a different sender > side behavior using existing information carried in the association > or need also specify a negotiation of of a congestion control > algorithm. > > First of all I don't like the SHOULD in this sentence. > > Secondly, I think we need to get a good agreement and statement what to > do with SCTP's congestion control algorithm in the future. I don't like > this statement saying basically agree on anything and use that. I think > the IETF specification should specify something to use that we know is > safe to deploy. Thus, I would strongly prefer this to simply to be > changed to say that: We know we want a new congestion control that > better can handle interaction the the RTP packet streams and its > congestion control, but that will not be initially available. Thus use > the specified congestion control and consider these issues. And if a new > CC algo becomes available that can be used and should be negotiated > between the endpoints somehow. > > 11. Section 6.1: > Once support for message interleaving as currently being discussed in > [I-D.ietf-tsvwg-sctp-ndata] is available, it SHOULD be supported. > > I don't know why you have formulated this, so awkward? NDATA is > currently listed as a normative reference. This document is going to > hand in the RFC-editor queue until it becomes available or an AD orders > some rewriting. Thus, why not simply write a simpler statement making > clear that one SHOULD support it. > > I would also note that there are disagreement between this and the text > in Section 6.6.: > > To overcome this > limitation, [I-D.ietf-tsvwg-sctp-ndata] defines an extension to > support message interleaving. Once this extension is available, it > MUST be used. > > Thus pick the level of requirement and then simply state that with the > motivation why. Personally I think SHOULD would be acceptable. There are > clear motivation why (in 6.6) why one SHOULD implelement it, and the > basic functionality is still there if it is not supported and its usage > will be negotiated as SCTP association creation. > > 12. Section 6.2: > Additionally, > the negotiation SHOULD include some type of congestion control > selection. > > Another congestion control statement that I am not happy with. See issue > 10. There is no default and it is also not clear on what to really > negotiate. > > 13. Section 6.3: > > SCTP defines a stream as a unidirectional logical channel existing > within an SCTP association one to another SCTP endpoint. > > The "one" looks spurious. > > 14. Section 6.4: > These priorities MUST NOT be strict priorities. > > Ok, this is one part of the agreement from the earlier meeting. There > was also agreement on using weighted fair queuing to solve the > priorities. The inter stream priority handling needs much firmer > specification. > > 15. Section 6.5: > "This can be based on the DTLS role (the client picks > even stream identifiers, the server odd stream identifiers) or done > in a different way." > > This is very unclear and you can't know what will happen. I think it > would be better to say: Unless otherwise defined or negotiated, the > streams are picked based on th DTLS role. ... > > 16. Section 6.5: > "In addition to choosing a stream, the application SHOULD also > inform the protocol of the options to use for sending messages." > > So what is the application, and what is the protocol in this sentence? > > 17. Section 7. > > I find this insufficient. I would this section to answer the following > questions: > > 1. Any security issues that arise from the combination of mechanism. > 2. Any significant issue that one needs to know about the behavior of > the mechanisms, any of the normative specs that should be highlighted? > 3. Clarification on what security properties one achieve with the > defined mechanism. > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d044519a9989f7a04f30fd90f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In reference to your first Section 1 comments= , I agree that we need to clearly differentiate the SRTP media and the = SCTP media. (Note - SRTP - not RTP !)

I agree that there = could be real-time media that can be sent over SCTP Channels are still meet= the criteria for 'real-time' as being 'received within a few h= undred milliseconds of being generated' - see WebRTC Overview section 2= .4.

Maybe we need to differentiate the Channel types - and then refer= to the data going over those Channels. For instance,if we define "SRT= P Channels" and "SCTP Channels", we could then refer to '= ;SRTP Channel media' which would have a specific meaning.

The best place for the definition of SRTP Channel and SCTP Channe= l is probably in the WebRTC Overview document.

Cheers,
/Barry Dingle



On Sat, Feb 22, 2014 at 3:27 AM, Magnus = Westerlund <magnus.westerlund@ericsson.com> wro= te:
Hi,
(as individual)

I have reviewed the WebRTC Data Channels draft
(draft-ietf-rtcweb-data-channel-07) and have some comments.

1. Section 1:
Non-media data types in the context of WebRTC are handled by using
=C2=A0 =C2=A0SCTP [RFC4960] encapsulated in DTLS [RFC6347].

There are many places in this draft where "media data" is a refer= ence to
the RTP transport media. I would suggest to review this and consider to
change this to "RTP Transport media", or "RTP media". T= he reason is that
I expect also real-time media to flow over the data channel.

2. Section 1:
As the other SCTP extensions are discussed in the introduction, I wonder why NADA and PR-Policy isn't.

3. Section 1:
Section 5 arguments SCTP over DTLS over UDP;

"arguments" looks strange in the above sentence fragment.

4. Section 3.1:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Note that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at any time there may be no media = channels, or all media
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0channels may be inactive, and that= there may also be reliable
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data channels in use.

"no media channels" is a bit strange here as we not really call a= nything
regarding RTP channels. I would suggest to change this to "RTP Packet<= br> Streams" or "RTP Stream".

5. Section 3.2:
=C2=A0 =C2=A0U-C 7: =C2=A0Proxy browsing, where a browser uses data channel= s of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PeerConnection to send and receive= HTTP/HTTPS requests and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data, for example to avoid local I= nternet filtering or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0monitoring.

>From a data channel perspective this doesn't look strange at all, however I get the shivers from the security implications of this. To my
understanding Peer A using Peer B to proxy browse must have B fetch all
elements that A needs into its sandbox and then transfer it to A over
the PeerConnections Data Channel. Thus, all you do are revealed to B,
massive privacy consideration. Or am I missing someway that A can tunnel its HTTP request through B without having B see the content of those
requests, I am especially concerned with HTTPS.

If this use case is going to stay, I do want some security consideration discussion around it.

6. Section 5:
" =C2=A0 o =C2=A0The congestion control is modifiable for integration = with media
=C2=A0 =C2=A0 =C2=A0 stream congestion control."

As this statement is only partial correct. There is no current mechanism to negotiate congestion control, nor does it exist any alternative
defined SCTP congestion control. Thus, I would like to have this
sentence modified. I am however not certain to what the authors consider important. It is the fact that it is possible in the future to define a
new CC algorithm and use that?

7. Section 5:
=C2=A0 =C2=A0o =C2=A0provides privacy for the SCTP control information.

Is "privacy" really the right word here? Either being explicit, &= quot;source
authentication, integrity and confidentiality" or something like "= ;security"?

8. section 5:

=C2=A0 =C2=A0DTLS implementations used for this stack SHOULD support contro= lling
=C2=A0 =C2=A0fields of the IP layer like the Don't Fragment (DF)-bit in= case of
=C2=A0 =C2=A0IPv4 and the Differentiated Services Code Point (DSCP) field r= equired
=C2=A0 =C2=A0for supporting [I-D.ietf-rtcweb-qos].

First of all this reference must be changed. What I am currently
uncertain of is what it should point on, most likely
draft-dhesikan-tsvwg-rtcweb-qos-04. But, I am not yet certain how the
scope is going to be divided between that document and
draft-ietf-rtcweb-transports.

9. Section 5:

The initial Path MTU
=C2=A0 =C2=A0at the IP layer MUST NOT exceed 1200 bytes for IPv4 and 1280 f= or
=C2=A0 =C2=A0IPv6.

I have to say that I think MUST NOT in the above is to strict. I think
SHOULD NOT is appropriate. The reason is that a deployment may actually
know that a larger initial MTU is better. This value may also change due to how the networks develop in the future.

10. Section 5:

Since SCTP does not support the
=C2=A0 =C2=A0negotiation of a congestion control algorithm yet, alternate =C2=A0 =C2=A0congestion controls SHOULD either only require a different sen= der
=C2=A0 =C2=A0side behavior using existing information carried in the associ= ation
=C2=A0 =C2=A0or need also specify a negotiation of of a congestion control<= br> =C2=A0 =C2=A0algorithm.

First of all I don't like the SHOULD in this sentence.

Secondly, I think we need to get a good agreement and statement what to
do with SCTP's congestion control algorithm in the future. I don't = like
this statement saying basically agree on anything and use that. I think
the IETF specification should specify something to use that we know is
safe to deploy. Thus, I would strongly prefer this to simply to be
changed to say that: We know we want a new congestion control that
better can handle interaction the the RTP packet streams and its
congestion control, but that will not be initially available. Thus use
the specified congestion control and consider these issues. And if a new CC algo becomes available that can be used and should be negotiated
between the endpoints somehow.

11. Section 6.1:
=C2=A0 =C2=A0Once support for message interleaving as currently being discu= ssed in
=C2=A0 =C2=A0[I-D.ietf-tsvwg-sctp-ndata] is available, it SHOULD be support= ed.

I don't know why you have formulated this, so awkward? NDATA is
currently listed as a normative reference. This document is going to
hand in the RFC-editor queue until it becomes available or an AD orders
some rewriting. Thus, why not simply =C2=A0write a simpler statement making=
clear that one SHOULD support it.

I would also note that there are disagreement between this and the text
in Section 6.6.:

To overcome this
=C2=A0 =C2=A0limitation, [I-D.ietf-tsvwg-sctp-ndata] =C2=A0defines an exten= sion to
=C2=A0 =C2=A0support message interleaving. =C2=A0Once this extension is ava= ilable, it
=C2=A0 =C2=A0MUST be used.

Thus pick the level of requirement and then simply state that with the
motivation why. Personally I think SHOULD would be acceptable. There are clear motivation why (in 6.6) why one SHOULD implelement it, and the
basic functionality is still there if it is not supported and its usage
will be negotiated as SCTP association creation.

12. Section 6.2:
=C2=A0Additionally,
=C2=A0 =C2=A0the negotiation SHOULD include some type of congestion control=
=C2=A0 =C2=A0selection.

Another congestion control statement that I am not happy with. See issue 10. There is no default and it is also not clear on what to really
negotiate.

13. Section 6.3:

=C2=A0 =C2=A0SCTP defines a stream as a unidirectional logical channel exis= ting
=C2=A0 =C2=A0within an SCTP association one to another SCTP endpoint.

The "one" looks spurious.

14. Section 6.4:
These priorities MUST NOT be strict priorities.

Ok, this is one part of the agreement from the earlier meeting. There
was also agreement on using weighted fair queuing to solve the
priorities. The inter stream priority handling needs much firmer
specification.

15. Section 6.5:
"This can be based on the DTLS role (the client picks
=C2=A0 =C2=A0even stream identifiers, the server odd stream identifiers) or= done
=C2=A0 =C2=A0in a different way."

This is very unclear and you can't know what will happen. I think it would be better to say: Unless otherwise defined or negotiated, the
streams are picked based on th DTLS role. =C2=A0...

16. Section 6.5:
"In addition to choosing a stream, the application SHOULD also
=C2=A0 =C2=A0inform the protocol of the options to use for sending messages= ."

So what is the application, and what is the protocol in this sentence?

17. Section 7.

I find this insufficient. I would this section to answer the following
questions:

1. Any security issues that arise from the combination of mechanism.
2. Any significant issue that one needs to know about the behavior of
the mechanisms, any of the normative specs that should be highlighted?
3. Clarification on what security properties one achieve with the
defined mechanism.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Phone= =C2=A0+46 10 7148287
F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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

--f46d044519a9989f7a04f30fd90f-- From nobody Mon Feb 24 02:05: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 16A2D1A0439 for ; Mon, 24 Feb 2014 02:05:08 -0800 (PST) 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, 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 M6BFNP0T0h53 for ; Mon, 24 Feb 2014 02:05:05 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DF7121A0865 for ; Mon, 24 Feb 2014 02:05:04 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-39-530b194f1ad8 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 6F.DA.04249.F491B035; Mon, 24 Feb 2014 11:05:03 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.347.0; Mon, 24 Feb 2014 11:05:02 +0100 Message-ID: <530B194F.4040909@ericsson.com> Date: Mon, 24 Feb 2014 11:05:03 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Thomson , Ted Hardie References: <530627C7.30906@ericsson.com> <53070996.9040707@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+Jvja6/JHewwb/jRhbXzvxjtFj7r53d onGunQOzx85Zd9k9liz5yRTAFMVlk5Kak1mWWqRvl8CV0f54JVPBI5GK+Rua2RsYvwp0MXJw SAiYSBzbn9/FyAlkiklcuLeerYuRi0NI4AijxNWHX1khnOWMEm82rWAGaeAV0JY43eUK0sAi oCqx/9dxRhCbTcBC4uaPRjYQW1QgWGLngd9gcV4BQYmTM5+wgNgiAn4SN7uPg9nMAuoSdxaf YwexhQXsJR7cfc4EYgsJzGCS2HcKrJdTIFBi0559zBB3ikv0NAZBtGpKtG7/zQ5hy0s0b53N DNGqLdHQ1ME6gVFoFpLNs5C0zELSsoCReRUjR3FqcVJuupHBJkZgwB7c8ttiB+PlvzaHGKU5 WJTEeT++dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFiV4GJheEzZ4ESQbsOTLyGatv1z dYOqfhus+7rS6Lz02sT7TxVf//z54c8xEwGFzWFzzoizrg46+2L6m9e6ilrnjsx+/NDycu07 ZtZ5Aarpoj/uZu6puDt5zdyVlpLz7YJ4dXJK58jwZZiIv7h8Zn+wi/J7k7UBU+VKT/9+66lg +KzWRuBS0GElluKMREMt5qLiRADNh/+rJgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/r9p8FlwuwIXJG7dZnDTDjpXO7zc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 10:05:08 -0000 On 2014-02-22 02:14, Martin Thomson wrote: > On 21 February 2014 17:02, Ted Hardie wrote: >> Sorry for my apparent failure to understand here, but we're still dealing >> with >> traffic to which the parties consent, right? That is, you're thinking of >> malicious >> JS that sends channels worth of nonsense to blast the network while >> something >> the user cares about happens? (Two-player flappy bird but with a terrabit of >> nonsense >> screaming in the background?) Yes, that would be the attack. And the target of the attack is the networks in the middle, not the endpoints, they are simply tools for this. > > > Maybe Magnus is looking for the mechanism described in > http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00, > which might allow for control below the limit that the congestion > control permits. I basically abandoned this, because it's small > potatoes. It's trivial to revoke consent if you notice a misbehaving > peer and then you only have to wait until the consent timer runs out > on the sender. 30s. > > My position is that the above mitigation is unlikely to have significant impact on this attack. This as it is difficult to know what values to set. They vary over time and depending on network attachment, what services the user tries to use etc. There are two reasons I wanted this attack to be considered. First, it provides a clear requirement on having congestion control as first level mitigation. Secondly, I think this could become a significant issue as data channel PeerConnections can be opened without user consent. A malicious JS that is sufficient well spread with a well working find and connect could establish a large mesh of peer connections that could come close to saturate each endpoints local access link, resulting in very heavy loads on the network, even with congestion control. With congestion control you can likely prevent congestion collapse, but you should be fully capable of driving a network into a state of "mostly useless", especially a network suffering from buffer bloat inside of the ingress nodes. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Feb 24 05:18: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 3B1721A0852 for ; Mon, 24 Feb 2014 05:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, 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 GzpqGqBBJdB6 for ; Mon, 24 Feb 2014 05:18:33 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 285391A0471 for ; Mon, 24 Feb 2014 05:18:32 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-53-530b46a749ea Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 46.55.10875.7A64B035; Mon, 24 Feb 2014 14:18:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 14:18:29 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8A== Date: Mon, 24 Feb 2014 13:18:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1B4DA3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvje4KN+5gg87N3BZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr40T7YqaC5WYVjZuPsjQwzjDoYuTkkBAwkXi6bCkLhC0mceHe erYuRi4OIYFDjBLnTkxggnCWMEo87XkB5HBwsAlYSHT/0wZpEBFQl7j88AI7iC0sECBx4OIl doh4qMT7K/OZIGw9iaNP/7GC2CwCqhKb3n5jBLF5BXwlul+uBlvMCLT4+6k1YPXMAuISHw5e Z4Y4SEBiyZ7zULaoxMvHEHMkBJQk1h7ezgJRny/R/G8iE8RMQYmTM5+wTGAUmoVk1CwkZbOQ lEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjOy5iZk56eWGmxiBYX9wy2/dHYynzokc YpTmYFES5/3w1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2OTy7d9uWUNz3Mc5k6b/MQy +vykCA/Rqtarr180vFDOYFEweX3m9fPD56UkD2m4PdvDyinjZRC7rOncv91vWi9sUlE74eOz ILf1XYhDdLNJtGswr6VCb6PEX/0p7b8KWFrMGj7aff3ItMPN4LyDk9CO6glrTa94/tvTbn6q mVP2MedXwSNxd5VYijMSDbWYi4oTAevZlwRJAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MRTpMEOFWPB9tgKf43IbuUxtnc4 Subject: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 13:18:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1B4DA3ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg: Q1: Instead of defining a new SDP webrtc-DataChannel attribute, would it be pos= sible to define the parameters as extension parameters to the SDP sctpmap a= ttribute (yes, I know the ABNF currently does not allow that)? Example: a=3Dsctpmap:1000 webrtc-datachannel 1;stream=3D6;subprotocol=3D"CLUE" I am not saying this would be good or bad - at this point I just want to un= derstand whether it would work. Q2: Would it be possible, for subprotocol values, use the same IANA registry/va= lues as for the WebRTC Data Channel Protocol? Q3: It would be good to clarify, if only one data channel is requested (or, eve= n required), that the stream value must be the same in the Offer and Answer= . Q4: I have issues with the max_retr, max_time and unordered parameters. First, they seem to specify SENDING capabilities, rather than RECEIVING cap= abilities. Second, they seem to describe characteristics associated with the subprotoc= ol, in which case they could be specified in the associated subprotocol spe= cification. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D1B4DA3ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

A few questions on  draft-= ejzak-dispatch-webrtc-data-channel-sdpneg:

 

Q1:

 

Instead of defining a new SDP w= ebrtc-DataChannel attribute, would it be possible to define the parameters = as extension parameters to the SDP sctpmap attribute (yes, I know the ABNF = currently does not allow that)?

 

Example:

 

a=3Dsctpmap:1000 webrtc-datachannel 1;stream=3D6;subprotocol=3D”CLUE= "

 

I am not saying this would be g= ood or bad – at this point I just want to understand whether it would= work.

 

 

Q2:

 

Would it be possible, for subpr= otocol values, use the same IANA registry/values as for the WebRTC Data Cha= nnel Protocol?

 

 

Q3:

 

It would be good to clarify, if= only one data channel is requested (or, even required), that the stream va= lue must be the same in the Offer and Answer.

 

 

Q4:

 

I have issues with the max_retr= , max_time and unordered parameters.

 

First, they seem to specify SEN= DING capabilities, rather than RECEIVING capabilities.

 

Second, they seem to describe c= haracteristics associated with the subprotocol, in which case they could be= specified in the associated subprotocol specification.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D1B4DA3ESESSMB209erics_-- From nobody Mon Feb 24 06:07: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 2DE4C1A0453 for ; Mon, 24 Feb 2014 06:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 TBWZJ6-MuNZV for ; Mon, 24 Feb 2014 06:07:49 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9501A088E for ; Mon, 24 Feb 2014 06:07:48 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id gl10so2796238lab.28 for ; Mon, 24 Feb 2014 06:07:47 -0800 (PST) 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=gIxr0b7Kfek1E9SmZyx6JJK/g5IVf1kg+tqq//re1os=; b=s6ihGno0EQ5UqPevqizZVR8+F4MoySDj6Zp0P8NU/L6FqNrzd2253BQvpUzeW0aOCH 40pnYs8iNHj3f3EEWXiMZZxsBIakvVbZDVdI7pUa3mkt0VwHT9rEEed5dovku6wc3CEU NPCODh/f1ql9gaB1PVJms7nJAlMbCgCJuV5P/dFHT0p52wVosY9IyI9+8cXQ8rA04c71 PbAJrEqZKY0KAgolWDFVsohOji4pCcW/T8HhfRqqBgz+zlhkw1yVqfcphGBkDru6fev1 7DQBDSVaX6FxBmBXf53CIQnypkXqjVFhYXjra3lULGy+YHvSKFp1sk+zVI7o0THcsOyJ 74pA== MIME-Version: 1.0 X-Received: by 10.112.155.202 with SMTP id vy10mr11560863lbb.31.1393250867304; Mon, 24 Feb 2014 06:07:47 -0800 (PST) Received: by 10.112.98.132 with HTTP; Mon, 24 Feb 2014 06:07:47 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> Date: Mon, 24 Feb 2014 08:07:47 -0600 Message-ID: From: Richard Ejzak To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e01228d68075bf004f3277f8e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JUjaH6Sz0EjMhZpwRkBP3fZYr9k Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 14:07:53 -0000 --089e01228d68075bf004f3277f8e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 24, 2014 at 7:18 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg: > > > > *Q1:* > > > > Instead of defining a new SDP webrtc-DataChannel attribute, would it be > possible to define the parameters as extension parameters to the SDP > sctpmap attribute (yes, I know the ABNF currently does not allow that)? > > > > Example: > > > > *a=sctpmap:1000 webrtc-datachannel 1;stream=6;subprotocol="CLUE"* > > > > I am not saying this would be good or bad - at this point I just want to > understand whether it would work. > It might work, but you would still need a different mechanism to negotiate multiple data channels. Why bother with two different formats when one will do? > > > > > *Q2:* > > > > Would it be possible, for subprotocol values, use the same IANA > registry/values as for the WebRTC Data Channel Protocol? > This is really more a question for the data channel design itself. A decision has been made to use the PPID for framing rather than protocol identification. There is some discussion of this in another thread. > > > > > *Q3:* > > > > It would be good to clarify, if only one data channel is requested (or, > even required), that the stream value must be the same in the Offer and > Answer. > I thought this also came up in an earlier thread and that it is documented (or should be documented) in the core data channel docs. My understanding is that the stream id is always the same in both directions for a particular data channel. > > > > *Q4:* > > > > I have issues with the max_retr, max_time and unordered parameters. > > > > First, they seem to specify SENDING capabilities, rather than RECEIVING > capabilities. > > > > Second, they seem to describe characteristics associated with the > subprotocol, in which case they could be specified in the associated > subprotocol specification. > This should be a topic for discussion in London. As it is currently written, these parameters are of the "take it or leave it" variety, i.e., the answerer either accepts the options listed in the offer or rejects the data channel outright. This is true for the in-band control protocol (please correct me if I am wrong on this), so we adopted the same approach for the SDP-negotiated case. Some have suggested that we should allow more flexibility in negotiation of these parameters when using SDP. If there is general agreement that it should be done this way, I see no problem with defining parameter negotiation rules for SDP in the next version of the draft. BR, Richard > > > Regards, > > > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e01228d68075bf004f3277f8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 24, 2014 at 7:18 AM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:

Hi,

 

A few questions on  draft-= ejzak-dispatch-webrtc-data-channel-sdpneg:

 

Q1:=

 

Instead of defining a new SDP w= ebrtc-DataChannel attribute, would it be possible to define the parameters = as extension parameters to the SDP sctpmap attribute (yes, I know the ABNF = currently does not allow that)?

 

Example:

 

a=3Dsctpmap:1000 webrtc-datachannel 1;stream=3D6;subprotocol=3D”CLUE= "

 

I am not saying this would be g= ood or bad – at this point I just want to understand whether it would= work.


It might work= , but you would still need a different mechanism to negotiate multiple data= channels.  Why bother with two different formats when one will do?
 

 

 

Q2:=

 

Would it be possible, for subpr= otocol values, use the same IANA registry/values as for the WebRTC Data Cha= nnel Protocol?


This = is really more a question for the data channel design itself.  A decis= ion has been made to use the PPID for framing rather than protocol identifi= cation.  There is some discussion of this in another thread.
 

 

 

Q3:=

 

It would be good to clarify, if= only one data channel is requested (or, even required), that the stream va= lue must be the same in the Offer and Answer.


I thought this also came up in an earlier thread and th= at it is documented (or should be documented) in the core data channel docs= .  My understanding is that the stream id is always the same in both d= irections for a particular data channel.   

=

 

 

Q4:=

 

I have issues with the max_retr= , max_time and unordered parameters.

 

First, they seem to specify SEN= DING capabilities, rather than RECEIVING capabilities.

 

Second, they seem to describe c= haracteristics associated with the subprotocol, in which case they could be= specified in the associated subprotocol specification.


This should be a topic for discussion in L= ondon.  As it is currently written, these parameters are of the "= take it or leave it" variety, i.e., the answerer either accepts the op= tions listed in the offer or rejects the data channel outright.  This = is true for the in-band control protocol (please correct me if I am wrong o= n this), so we adopted the same approach for the SDP-negotiated case.  = ;Some have suggested that we should allow more flexibility in negotiation o= f these parameters when using SDP.  If there is general agreement that= it should be done this way, I see no problem with defining parameter negot= iation rules for SDP in the next version of the draft.

BR, Richard

 

 

Regards,=

 

Christer


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


--089e01228d68075bf004f3277f8e-- From nobody Mon Feb 24 06:20: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 B399F1A0874 for ; Mon, 24 Feb 2014 06:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, 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 HwTYoolJB-mQ for ; Mon, 24 Feb 2014 06:20:48 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3CB1A036A for ; Mon, 24 Feb 2014 06:20:48 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-7a-530b553e5403 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 90.70.10875.E355B035; Mon, 24 Feb 2014 15:20:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 15:18:46 +0100 From: Christer Holmberg To: Richard Ejzak Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6A= Date: Mon, 24 Feb 2014 14:18:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvja59KHewwbspbBbPehtYLdb+a2d3 YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDI+3NnHXrBVqqLl4TmmBsYW0S5GTg4JAROJ fX23GCFsMYkL99azdTFycQgJHGKUuHj0EhOEs4RRYsXRF+xdjBwcbAIWEt3/tEEaRAS0Jba9 fMACYjMLqEvcWXyOHcQWFoiV2H10PSNETZzEowfb2CFsK4mF7duZQMawCKhKnFxWAmLyCvhK NPR4Q2yawijx+/1dJpByToFAiWenjjCD2IxAt30/tYYJYpW4xIeD15khbhaQWLLnPJQtKvHy 8T9WCFtJYu3h7VCn6UncmDqFDcLWlli28DVYPa+AoMTJmU9YJjCKzUIydhaSlllIWmYhaVnA yLKKkT03MTMnvdxwEyMwQg5u+a27g/HUOZFDjNIcLErivB/eOgcJCaQnlqRmp6YWpBbFF5Xm pBYfYmTi4JRqYEzcJ3RvspbHW7OkK6yWa50mm80+Ns/Q8UY/Z90Tm72PitlPf9S++CVcpCFD P6f87rfnt/OrLzooHtm+5nq2+pFjPrbl0d+df6WsujK/xrnm0TseqcmMyY8e1s30uHyhPWve iXM/prFmrPVeXMup7bBKc6F7SfGRn33H5/DV++4zmfU/82fSi1dKLMUZiYZazEXFiQAnCCxk XgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NQZd2sgaO_4XT3OQ3S0_oPH9QvY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 14:20:51 -0000 Hi, >>Q1: >> >>=A0Instead of defining a new SDP webrtc-DataChannel attribute, would it b= e possible to define the parameters as extension parameters to the SDP sctp= map attribute (yes, I know the ABNF currently does not allow that)? >> >>Example: >>=20 >> a=3Dsctpmap:1000 webrtc-datachannel 1;stream=3D6;subprotocol=3D= "CLUE" >> >> I am not saying this would be good or bad - at this point I just want to= understand whether it would work. > > It might work, but you would still need a different mechanism to negotiat= e multiple data channels. =A0Why bother with two different formats when one= will do? I am sure the syntax could be defined so that you could define multiple cha= nnels. Or, you could use multiple sctpmap attributes. Anyway, that is a syntax question, so we don't need to spend time on it now= . =A0 >> Q2: >>=A0 >> Would it be possible, for subprotocol values, use the same IANA registry= /values as for the WebRTC Data Channel Protocol? > > This is really more a question for the data channel design itself. =A0A d= ecision has been made to use the PPID for framing rather than protocol iden= tification. =A0There is some discussion of this in another thread. I am not talking about the PPID - I am talking about the Protocol field in = the DATA_CHANNEL_OPEN message, which (afaik) specifies the same thing as th= e subprotocol parameter in your draft. =A0 >> Q3: >>=A0 >> It would be good to clarify, if only one data channel is requested (or, = even required), that the stream value must be the same in the Offer and Ans= wer. > > I thought this also came up in an earlier thread and that it is documente= d (or should be documented) in the core data channel docs. =A0My understand= ing is that the stream id is always the same in both directions for a parti= cular data channel. =A0=A0 Correct. But, there should be an Offer/Answer procedure section in your dra= ft, which shall say that the stream number must be the same. You can then r= eference to the data channel doc for justification. =A0 >> Q4: >> >> I have issues with the max_retr, max_time and unordered parameters. >>=A0 >> First, they seem to specify SENDING capabilities, rather than RECEIVING = capabilities.=20 >>=A0 >> Second, they seem to describe characteristics associated with the subpro= tocol, in which case they could be specified in the associated subprotocol = specification. > > This should be a topic for discussion in London. =A0As it is currently wr= itten, these parameters are of the "take it or leave it" variety, i.e., the= answerer either accepts the options listed > in the offer or rejects the data channel outright. =A0This is true for th= e in-band control protocol (please correct me if I am wrong on this), so we= adopted the same approach for the=20 > SDP-negotiated case. =A0Some have suggested that we should allow more fle= xibility in negotiation of these parameters when using SDP. =A0If there is = general agreement that it should be > done this way, I see no problem with defining parameter negotiation rules= for SDP in the next version of the draft. The difference is that your draft is based on Offer/Answer, which is about = indicating receiving capabilities (yes, I know we have broken that rule in = the past). Regards, Christer =A0 From nobody Mon Feb 24 06: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 1A1E61A002D for ; Mon, 24 Feb 2014 06:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 3_iJwRZ0PQOB for ; Mon, 24 Feb 2014 06:58:32 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B8BD01A0011 for ; Mon, 24 Feb 2014 06:58:31 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id e16so5821446lan.40 for ; Mon, 24 Feb 2014 06:58:30 -0800 (PST) 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=5uRILwZ/Zwf4ZKN24PqAcs7M/ew+e8oQlCJrWVN2c3M=; b=xSROo0UAFJ5zjUC7/WZU9yPGYWgcSGgdJw0xf0qiUHPZziyDDRKASJyTKNr1ZowHZB HZYBX6p5kc6xSkMB04Xq8a3Ihp+vp8nYdLBq1EuIzzLszdCtOE19XVAHPsf4uf7Jj/qT e2RqwpZU+/fh23zte1mN0nxdXm54JXKRT2vs4evj25Fv1H0sfyZHeAoyLKKbxcMOov30 N8uZTysivEBiHrddCYyV8uJeZNrVuQfIUfBTyDslKqmDs6zYbrhWCC0aYFVdVCGSE+z9 Pw1NSya5YuLmGk3gZWkFQr2+WfGNQp+qFnEshN/JwyHNmQp5DTkFnjYNhkL3v2lg/fkx WphQ== MIME-Version: 1.0 X-Received: by 10.152.1.3 with SMTP id 3mr12497831lai.58.1393253910506; Mon, 24 Feb 2014 06:58:30 -0800 (PST) Received: by 10.112.98.132 with HTTP; Mon, 24 Feb 2014 06:58:30 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> Date: Mon, 24 Feb 2014 08:58:30 -0600 Message-ID: From: Richard Ejzak To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e013c6ae46aef8f04f32834ed Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HHt1jlp-wYkZD2X37eZR4R8t88A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 14:58:34 -0000 --089e013c6ae46aef8f04f32834ed Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 24, 2014 at 8:18 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > >> Q2: > >> > >> Would it be possible, for subprotocol values, use the same IANA > registry/values as for the WebRTC Data Channel Protocol? > > > > This is really more a question for the data channel design itself. A > decision has been made to use the PPID for framing rather than protocol > identification. There is some discussion of this in another thread. > > I am not talking about the PPID - I am talking about the Protocol field in > the DATA_CHANNEL_OPEN message, which (afaik) specifies the same thing as > the subprotocol parameter in your draft. > This issue did come up in another thread, and the answer is yes. It should probably be documented in the core data channel specs and just referenced here. > > > >> Q3: > >> > >> It would be good to clarify, if only one data channel is requested (or, > even required), that the stream value must be the same in the Offer and > Answer. > > > > I thought this also came up in an earlier thread and that it is > documented (or should be documented) in the core data channel docs. My > understanding is that the stream id is always the same in both directions > for a particular data channel. > > Correct. But, there should be an Offer/Answer procedure section in your > draft, which shall say that the stream number must be the same. You can > then reference to the data channel doc for justification. > Since there is no disagreement over how it should work, we can clarify as necessary in a subsequent draft. > > > >> Q4: > >> > >> I have issues with the max_retr, max_time and unordered parameters. > >> > >> First, they seem to specify SENDING capabilities, rather than RECEIVING > capabilities. > >> > >> Second, they seem to describe characteristics associated with the > subprotocol, in which case they could be specified in the associated > subprotocol specification. > > > > This should be a topic for discussion in London. As it is currently > written, these parameters are of the "take it or leave it" variety, i.e., > the answerer either accepts the options listed > > in the offer or rejects the data channel outright. This is true for the > in-band control protocol (please correct me if I am wrong on this), so we > adopted the same approach for the > > SDP-negotiated case. Some have suggested that we should allow more > flexibility in negotiation of these parameters when using SDP. If there is > general agreement that it should be > > done this way, I see no problem with defining parameter negotiation > rules for SDP in the next version of the draft. > > The difference is that your draft is based on Offer/Answer, which is about > indicating receiving capabilities (yes, I know we have broken that rule in > the past). > There are many examples of attributes that use different negotiation models than this. The only requirement is that the semantics of the negotiation be defined in the document defining the attribute. BR, Richard --089e013c6ae46aef8f04f32834ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 24, 2014 at 8:18 AM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:

Hi,

>> Q2:
>>=A0
>> Would it be possible, for subprotocol values, use the same IANA re= gistry/values as for the WebRTC Data Channel Protocol?
>
> This is really more a question for the data channel design itself. =A0= A decision has been made to use the PPID for framing rather than protocol i= dentification. =A0There is some discussion of this in another thread.

I am not talking about the PPID - I am talking about the Protocol fie= ld in the DATA_CHANNEL_OPEN message, which (afaik) specifies the same thing= as the subprotocol parameter in your draft.

This issue did come up in another thread, and the answer is yes.= =A0It should probably be documented in the core data channel specs and jus= t referenced here.
=A0

=A0
>> Q3:
>>=A0
>> It would be good to clarify, if only one data channel is requested= (or, even required), that the stream value must be the same in the Offer a= nd Answer.
>
> I thought this also came up in an earlier thread and that it is docume= nted (or should be documented) in the core data channel docs. =A0My underst= anding is that the stream id is always the same in both directions for a pa= rticular data channel. =A0=A0

Correct. But, there should be an Offer/Answer procedure section in yo= ur draft, which shall say that the stream number must be the same. You can = then reference to the data channel doc for justification.

Since there is no disagreement over how it should work,= we can clarify as necessary in a subsequent draft.
=A0

=A0
>> Q4:
>>
>> I have issues with the max_retr, max_time and unordered parameters= .
>>=A0
>> First, they seem to specify SENDING capabilities, rather than RECE= IVING capabilities.
>>=A0
>> Second, they seem to describe characteristics associated with the = subprotocol, in which case they could be specified in the associated subpro= tocol specification.
>
> This should be a topic for discussion in London. =A0As it is currently= written, these parameters are of the "take it or leave it" varie= ty, i.e., the answerer either accepts the options listed
> in the offer or rejects the data channel outright. =A0This is true for= the in-band control protocol (please correct me if I am wrong on this), so= we adopted the same approach for the
> SDP-negotiated case. =A0Some have suggested that we should allow more = flexibility in negotiation of these parameters when using SDP. =A0If there = is general agreement that it should be
> done this way, I see no problem with defining parameter negotiation ru= les for SDP in the next version of the draft.

The difference is that your draft is based on Offer/Answer, which is = about indicating receiving capabilities (yes, I know we have broken that ru= le in the past).

There are many example= s of attributes that use different negotiation models than this. =A0The onl= y requirement is that the semantics of the negotiation be defined in the do= cument defining the attribute.

BR, Richard
=A0
--089e013c6ae46aef8f04f32834ed-- From nobody Mon Feb 24 07:22: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 6045D1A0104 for ; Mon, 24 Feb 2014 07:21:55 -0800 (PST) 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, 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 neddLGGZep_y for ; Mon, 24 Feb 2014 07:21:50 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 835EB1A0100 for ; Mon, 24 Feb 2014 07:21:49 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-ef-530b638cb3af Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 0E.EF.04249.C836B035; Mon, 24 Feb 2014 16:21:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 16:21:48 +0100 From: Christer Holmberg To: Richard Ejzak Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw Date: Mon, 24 Feb 2014 15:21:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+JvjW5PMnewwfpHChbPehtYLdb+a2d3 YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIO3nnMUnBbuuLU9zXsDYxzxLoYOTkkBEwk WpfdYIawxSQu3FvP1sXIxSEkcIRR4tzmFSwQzhJGienv5rN2MXJwsAlYSHT/0wZpEBHQltj2 8gELiM0soC5xZ/E5dhBbWCBWYvfR9YwQNXESjx5sY4ew3SS6/h4Aq2cRUJU427QazOYV8JWY 03MHavF8Jom5e9eA7eIUCJR4tCEXpIYR6Ljvp9YwQewSl/hw8DrU0QISS/ach7JFJV4+/scK YStJrD28Heo2PYkbU6ewQdjaEssWvmaG2CsocXLmE5YJjGKzkIydhaRlFpKWWUhaFjCyrGLk KE4tTspNNzLYxAiMkoNbflvsYLz81+YQozQHi5I478e3zkFCAumJJanZqakFqUXxRaU5qcWH GJk4OKUaGMUuML6aeLo9kXtBlUR5o83jm4tu3DQX9og5baRXuf3bt8Rj537YTxQMNbYR3a8l vyRw3aJeo2f5qxlbNDZMiZD9P2m5usLGu20mv/QCRQPSfi4LL40xmfnCed65ggomoxUnfnHe eftFmdVhT8k3w+uRIi77eQ7uqGX7sYLNeWXZ5mg2Cd31nUosxRmJhlrMRcWJADYIs6dgAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rStbuP6J44rAJSZ7BI2HzlO94UQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 15:21:56 -0000 Hi, >>>> Q2: >>>>=A0 >>>> Would it be possible, for subprotocol values, use the same IANA regist= ry/values as for the WebRTC Data Channel Protocol? >>> >>> This is really more a question for the data channel design itself. =A0A= decision has been made to use the PPID for framing rather than protocol id= entification. =A0There is some discussion of this in another thread. >> I am not talking about the PPID - I am talking about the Protocol field = in the DATA_CHANNEL_OPEN message, which (afaik) specifies the same thing as= the subprotocol parameter in your draft. > > This issue did come up in another thread, and the answer is yes. =A0It sh= ould probably be documented in the core data channel specs and just referen= ced here. Good. Sorry if I missed the previous discussion on the topic. =A0 >>>> Q3: >>>>=A0 >>>> It would be good to clarify, if only one data channel is requested (or= , even required), that the stream value must be the same in the Offer and A= nswer. >>> >>> I thought this also came up in an earlier thread and that it is documen= ted (or should be documented) in the core data channel docs. =A0My understa= nding is that the stream id is always the same in both directions for a par= ticular data channel. =A0=A0 >> Correct. But, there should be an Offer/Answer procedure section in your = draft, which shall say that the stream number must be the same. You can the= n reference to the data channel doc for justification. >> > Since there is no disagreement over how it should work, we can clarify as= necessary in a subsequent draft. =A0 Good. =A0 >>>> Q4: >>>> >>>> I have issues with the max_retr, max_time and unordered parameters. >>>>=A0 >>>> First, they seem to specify SENDING capabilities, rather than RECEIVIN= G capabilities. >>>>=A0 >>>> Second, they seem to describe characteristics associated with the subp= rotocol, in which case they could be specified in the associated subprotoco= l specification. >>> >>> This should be a topic for discussion in London. =A0As it is currently = written, these parameters are of the "take it or leave it" variety, i.e., t= he answerer either accepts the options listed >>> in the offer or rejects the data channel outright. =A0This is true for = the in-band control protocol (please correct me if I am wrong on this), so = we adopted the same approach for the >>> SDP-negotiated case. =A0Some have suggested that we should allow more f= lexibility in negotiation of these parameters when using SDP. =A0If there i= s general agreement that it should be >>> done this way, I see no problem with defining parameter negotiation rul= es for SDP in the next version of the draft. >> The difference is that your draft is based on Offer/Answer, which is abo= ut indicating receiving capabilities (yes, I know we have broken that rule = in the past). > > There are many examples of attributes that use different negotiation mode= ls than this. =A0The only requirement is that the semantics of the negotiat= ion be defined in the document defining the attribute. I still don't think the information belong to SDP - they define protocol ch= aracteristics. The protocol specification should define re-transmission tim= ers etc. Anyway, we can argue about it later. At this moment I think the focus shoul= d be on whether to move forward with the mechanism to begin with, and the m= ain feature of the mechanism - which is about negotiating usage of channels= :) Regards, Christer From nobody Mon Feb 24 07: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 4284D1A0104 for ; Mon, 24 Feb 2014 07:23:56 -0800 (PST) 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_80=2, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 gUDkYZUmGiPq for ; Mon, 24 Feb 2014 07:23:55 -0800 (PST) Received: from blu0-omc3-s10.blu0.hotmail.com (blu0-omc3-s10.blu0.hotmail.com [65.55.116.85]) by ietfa.amsl.com (Postfix) with ESMTP id E6C6E1A0102 for ; Mon, 24 Feb 2014 07:23:54 -0800 (PST) Received: from BLU0-SMTP100 ([65.55.116.74]) by blu0-omc3-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Feb 2014 07:23:54 -0800 X-TMN: [aeNLm/Mpy/hHfvG/UbIUX8Pynuot7FpA] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([74.12.62.240]) by BLU0-SMTP100.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Feb 2014 07:23:53 -0800 From: Paul Coverdale To: Date: Mon, 24 Feb 2014 10:23:51 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01CF314A.83A40860" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8xdGvn5+ttPje2T0GUNZrrdMIWGA== Content-Language: en-us X-OriginalArrivalTime: 24 Feb 2014 15:23:53.0969 (UTC) FILETIME=[6D79A610:01CF3174] Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6u9DJabEkUZsjocw54xKBwtghdM Subject: [rtcweb] Draft-proust-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: Mon, 24 Feb 2014 15:23:56 -0000 ------=_NextPart_000_0041_01CF314A.83A40860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This draft seems like a good start to address the issue of interoperability of audio codecs in WebRTC. As has been pointed out in previous postings, AMR, AMR-WB and G.722 are particularly attractive codecs which should be included, but I note that the authors have left the opportunity for including others. ...Paul ------=_NextPart_000_0041_01CF314A.83A40860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This draft = seems like a good start to address the issue of interoperability of = audio codecs in WebRTC. As has been pointed out in previous postings, = AMR, AMR-WB and G.722 are particularly attractive codecs which should be = included, but I note that the authors have left the opportunity for = including others.

 

...Paul

------=_NextPart_000_0041_01CF314A.83A40860-- From nobody Mon Feb 24 08:32: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 B1E181A0111 for ; Mon, 24 Feb 2014 08:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, 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 ho_a7FXppSA5 for ; Mon, 24 Feb 2014 08:32:16 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 66F521A00FD for ; Mon, 24 Feb 2014 08:32:16 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-45-530b740fa030 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 07.24.10875.F047B035; Mon, 24 Feb 2014 17:32:15 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.2.347.0; Mon, 24 Feb 2014 17:32:14 +0100 Message-ID: <530B740E.4090707@ericsson.com> Date: Mon, 24 Feb 2014 17:32:14 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" , X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJMWRmVeSWpSXmKPExsUyM+JvjS5/CXewwcp2cYvVh/eyWaz9187u wOSxZMlPJo8vlz+zBTBFcdmkpOZklqUW6dslcGV86ZrJWnBbpWLz3ItsDYw7ZbsYOTkkBEwk jnw6zgZhi0lcuLceyObiEBI4xChx6+w+JghnOaPEp99HmEGqeAW0JfbM62YFsVkEVCXmHVrF CGKzCVhI3PzRCDZJVCBYYueB34wQ9YISJ2c+YQGxRQSiJXa+7GAHsYUF7CQ+r58DZHMAbRaX 6GkMAgkzC+hJTLnawghhy0s0b50NtlYIaG1DUwfrBEb+WUimzkLSMgtJywJG5lWM7LmJmTnp 5YabGIEhdnDLb90djKfOiRxilOZgURLn/fDWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD 4+zK3Wk2r3YdMuz00zuy+t2zL8/b9UX2lJxR/Bwk2yvxUNd2/eG8lUfObzp5hHuCdvXa9pob C3bN315r7aKaEe/8RcOJhe/7Hefbv9fYd3adXjrV9lfx/e3cLR6VRoWz3qzeGBLqsiwo2vam cchOj50dPi1z+LJKd8b+E+hIeqxV++7kTd2MaUosxRmJhlrMRcWJAHWlY8z/AQAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hLFiWQY5Hj8N-PSzik9fyDQO8HA Subject: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 16:32:18 -0000 Hi, (as individual) I have reviewed the WebRTC Data Channel Establishment protocol (draft-ietf-rtcweb-data-protocol-03) and have some comments: 1. Section 4: Shouldn't this section discuss the priority field? 2. Section 4: The method used to determine which side uses odd or even is based on the underlying DTLS connection role when used in WebRTC, with the side acting as the DTLS client using even stream identifiers. Isn't this unnecessary using the vague word of WebRTC instead of simply pointing to the DTLS roles of the established data channel? 3. Section 5.1: DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel provides a partial reliable in-order bi-directional Communication channel. User messages might not be transmitted or retransmitted after a specified life-time given in milli- seconds in the Reliability Parameter. This life-time starts when providing the user message to the Javascript engine. I think the use of "Javascript engine" in the last sentence is unclear. Can we provide a implementation neutral definition, like "This life-time starts when requesting transmission of the user message."? 4. Section 5.1: Label: Variable Length (sequence of characters) The name of the channel. This may be an empty string. Protocol: Variable Length (sequence of characters) The protocol for the channel. If this is an empty string the protocol us unspecified. If it is an non-empty string, it specifies an IANA-registered protocol (see Section 8.4). Both of these fields are strings, shouldn't a particular encoding be specified here? Like UTF-8. Secondly, what values are allowed, the full set of Unicode? 5. Section 6: All Data Channel Establishment Protocol messages MUST be sent requesting ordered delivery and using reliable transmission. I wonder of the use of requesting ordered delivery and using reliable transmission, from an SCTP stream perspective, wouldn't using in both places be appropriate? Or is how object which has been requested to be transmitted unordered interact in SCTP with the ordered ones? 6. Section 7: I think this section can be beefed up a bit. First make clear that the Data Channel's required usage of DTLS ensures that the message integrity and possible source authentication as well as confidentiality. Then going over any security risks with a malicous peer using this protocol. Can a malicous side screw up the peer using this protocol? What are the implications? 7. Section 8.2: This registry reserves 0xff without any motivation, please add one. 8. Section 8.3: If I define a channel behavior that allows mixed ordered and unordered, how would I register this? 9. Section 8.4: I have a suggestion for this registries name, instead of "Protocol Registry" I propose "DCEP Protocol Identification Registry" 10. Section 8.4: There is missing any specification of what type of strings I may register. Also, no length limitation, although the protocol allows at maximum of 255 octets of encoded characters. 11. This comments concerns the relation to the Data Channel specification. So my interpretation is that the WebRTC Data channel draft has become both the base for this specification as well as the one that specifies that the DCEP shall be implemented and supported. For WebRTC I don't think this matters much, but if someone likes to re-use the basic Data Channel specification, this structure makes it more difficult and have no need for the bi-directional negotiated parameter settings that the DCEP provides. In that case one have to sub-set the data channel specification. I wonder if it would be better to move some normative statements around, so that the chain of implementation requirement goes draft-ietf-rtcweb-transports -> draft-ietf-rtcweb-data-protocol -> draft-ietf-rtcweb-data-channel thus providing a cleaner and more modular build up of the protocols. This a suggestion based on that it looks like others, like CLUE is going to use the Data Channel specification, but I am uncertain if they want DCEP or not. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Feb 24 08: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 8B69E1A019C for ; Mon, 24 Feb 2014 08:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.66 X-Spam-Level: X-Spam-Status: No, score=0.66 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 C4KzNrZAZ_lP for ; Mon, 24 Feb 2014 08:54:45 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 621CF1A0164 for ; Mon, 24 Feb 2014 08:54:43 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-76-530b7952f9d1 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 00.B3.04853.2597B035; Mon, 24 Feb 2014 17:54:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 17:54:42 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: JSEP-06: max-bundle policy questions Thread-Index: Ac8xgReyx0/WK3m4RUOln8j3WJLYRQ== Date: Mon, 24 Feb 2014 16:54:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1B552E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1B552EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+JvjW5QJXewwawf1hZbpwpZrP3Xzu7A 5LFgU6nHkiU/mQKYorhsUlJzMstSi/TtErgyns/fxVSwWqOifeVexgbGPcpdjJwcEgImEhtO 7GeGsMUkLtxbz9bFyMUhJHCCUWLSxFfsEM4SRok/1++xdjFycLAJWEh0/9MGaRARUJe4/PAC O4jNLGArsf7pVEYQW1hAV+LKm/fMEDVGEj2rZrNB2HoSu9ogalgEVCWWbHwM1ssr4Cuxa/oT VhCbEeiI76fWMEHMFJf4cPA61HECEkv2nIeyRSVePv7HCmErSaw9vJ0Foj5f4kbLCUaImYIS J2c+YZnAKDwLyahZSMpmISmDiOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxgli1OLi3PT jQz0ctNzS/RSizKTi4vz8/SKUzcxAmPo4JbfRjsYT+6xP8QozcGiJM57nbUmSEggPbEkNTs1 tSC1KL6oNCe1+BAjEwenVAPjsvpC/S0lP5uzSxaumfhWPzNtrUPtqmkLvqtxhPr2uzdP+3yB a87ZRYy7e9WbcluquDUljjW2hOh05G3+l9b9qWXpFK9fc/r1DNPOLFxn1Nm+tuwKN1+JA1u7 DufqQ88iNE2nlt/5dCv2S9u7pze4bd5tZ/04fd/RDem7v7adezPtW4OBoUu6EktxRqKhFnNR cSIANC6KR28CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8Qnno2TA72rC3Y26D-AxaLbRfII Subject: [rtcweb] JSEP-06: max-bundle policy 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, 24 Feb 2014 16:54:46 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1B552EESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 4.1.1 says: "o "max-bundle": The application will BUNDLE all of its media streams on a single transport. All streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy endpoints." Q1: I think it would be good to clarify that the application will BUNDLE all of= its media streams *THAT THE APPLICATION IS ABLE TO DE-MULTIPLEX*. Q2: The text says that all streams other than the first will be marked as bundl= e-only. But, will the application have any clue which media type that first= stream will be? Should we e.g. specify that it MUST be audio (if audio is = enabled)? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D1B552EESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Section 4.1.1 says:<= /span>

 

“o  "max-bundle= ": The application will BUNDLE all of its media streams<= /b>

    &nbs= p; on a single transport.  All streams= other than the first will be

      = marked as bundle-only.  This policy aims to minimize candidate

      = gathering and maximize multiplexing, at the cost of less<= /p>

      = compatibility with legacy endpoints.”

 

Q1:

 

I think it would be good to cla= rify that the application will BUNDLE all of its media streams *THAT THE= APPLICATION IS ABLE TO DE-MULTIPLEX*.

 

Q2:

 

The text says that all streams = other than the first will be marked as bundle-only. But, will the applicati= on have any clue which media type that first stream will be? Should we e.g.= specify that it MUST be audio (if audio is enabled)?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D1B552EESESSMB209erics_-- From nobody Mon Feb 24 09:02: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 E0FCE1A00AF for ; Mon, 24 Feb 2014 09:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.46 X-Spam-Level: * X-Spam-Status: No, score=1.46 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 vTnO0SnYp--E for ; Mon, 24 Feb 2014 09:02:48 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8976F1A00DD for ; Mon, 24 Feb 2014 09:02:47 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-fa-530b7b369501 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 13.A4.04853.63B7B035; Mon, 24 Feb 2014 18:02:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 18:02:45 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - PeerConnection BUNDLE policy Thread-Index: Ac8pjtnjzyDELOBDTjiX88M43xAyxwDrMPeAARFru7A= Date: Mon, 24 Feb 2014 17:02:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1B5588@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1730E7@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvja5ZNXewQe8MJYutU4Us1v5rZ3dg 8liwqdRjyZKfTAFMUVw2Kak5mWWpRfp2CVwZJ47cZCrYI1Kxe9om1gbGH8JdjJwcEgImEk8O H2WBsMUkLtxbzwZiCwmcYJR48LSsi5ELyF7CKLHtxCWgIg4ONgELie5/2iA1IgJqEg9n7WIF sZkF1CXuLD7HDmILCyRIrHy1kQWiJlHi9e8ONgjbSuLlt/vMIGNYBFQlvi8pBQnzCvhKTF/x gRVi1RRGiae9XWCrOAUCJc6d8wCpYQQ67fupNUwQq8QlPhy8zgxxsoDEkj3noWxRiZeP/7FC 2EoSaw9vBxvDLKApsX6XPkSrosSU7ofsEGsFJU7OfMIygVFsFpKpsxA6ZiHpmIWkYwEjyypG yeLU4uLcdCMDvdz03BK91KLM5OLi/Dy94tRNjMDYObjlt9EOxpN77A8xSnOwKInzXmetCRIS SE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOHWH+x3NbvFm40v83M96JLgtN5jUGW06UhZScPHH Vo3Oy3GNMe0726wFOi+caTz5L2fFxCAfPp5Vpc2M8Ysa2PfNm3i7OfPuWaN9iukBuzu5gyt1 Y5N7tr4y2vruwsdItbX1L+ojPbrabS28TbP6b/e6hNnlG8zn8/hV9nljwW1xmy1njykqsRRn JBpqMRcVJwIA5L7GfmsCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LnY8wFL4S4C3qusQvPBV5DVbXVM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - PeerConnection BUNDLE policy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 17:02:49 -0000 SGksDQoNCj4+IFNlY3Rpb24gNC4xLjEuIGRlZmluZXMsIGZvciB0aGUgUGVlckNvbm5lY3Rpb24g Y29uc3RydWN0b3IsIHRoZSBwb3NzaWJpbGl0eSB0byBzcGVjaWZ5IEJVTkRMRSBwb2xpY3kuDQo+ Pg0KPj4gSG93ZXZlciwgSSBhbSBtaXNzaW5nIHRoZSBwb3NzaWJpbGl0eSB0byBpbmRpY2F0ZSB3 aGV0aGVyLCB3aXRoaW4gYSBCVU5ETEUgZ3JvdXAsIHRoZSBzYW1lIHBvcnQgbnVtYmVyIHNoYWxs IGJlIHVzZWQgb3Igbm90Lg0KPj4NCj4+IFNlY3Rpb24gNS4yLjEgZG9lcyBzYXk6DQo+Pg0KPj7C oCDCoCDCoCDCoCAibyDCoFRoZSBwb3J0IHZhbHVlIGlzIHNldCB0byB0aGUgcG9ydCBvZiB0aGUg ZGVmYXVsdCBJQ0UgY2FuZGlkYXRlIGZvcg0KPj7CoCDCoCDCoCDCoCB0aGlzIG09IHNlY3Rpb247 IGlmIHRoaXMgbT0gc2VjdGlvbiBpcyBub3QgYmVpbmcgYnVuZGxlZCBpbnRvDQo+PsKgIMKgIMKg IMKgIGFub3RoZXIgbT0gc2VjdGlvbiwgdGhlIHBvcnQgdmFsdWUgTVVTVCBiZSB1bmlxdWUuIg0K Pj4NCj4+IC4uLmJ1dCwgaXQgZG9lc24ndCB0YWxrIGFib3V0IHRoZSBjYXNlIHdoZW4gdGhlIHBv cnQgSVMgYmVpbmcgYnVuZGxlZCBpbnRvIGFub3RoZXIgbT0gc2VjdGlvbi4gTm9ybWFsbHksIGlu IHRoZSBpbml0aWFsIE9mZmVyLCB0aGUgcG9ydCB2YWx1ZSB3aWxsIGJlIA0KPj4gdW5pcXVlIGFs c28gaW4gdGhhdCBjYXNlLCBidXQgaWYgdGhlIFBlZXJDb25uZWN0aW9uIGlzIGNyZWF0ZWQgZHVl IHRvIGZvcmtpbmcsIGFuZCBpdCBpcyBrbm93biB0aGF0IHRoZSByZW1vdGUgcGVlciBzdXBwb3J0 cyBCVU5ETEUsIHRoZW4gDQo+PiBpZGVudGljYWwgcG9ydCB2YWx1ZXMgY2FuIGJlIHVzZWQgYWxy ZWFkeSBpbiB0aGUgaW5pdGlhbCBvZmZlci4NCj4NCj4gSWYgYSBtPSBzZWN0aW9uIGlzIGJlaW5n IGJ1bmRsZWQgaW50byBhbm90aGVyIG09IHNlY3Rpb24sIHRoZW4gdGhlIHBvcnQgbnVtYmVyIG11 c3QgYmUgdGhlIHNhbWUsIGFzIGluZGljYXRlZCBpbiB0aGUgQlVORExFIFdHIGRyYWZ0LsKgDQoN CkJlZm9yZSBpdCBpcyBrbm93biB3aGV0aGVyIHRoZSByZW1vdGUgcGVlciBzdXBwb3J0cyBCVU5E TEUsIGVhY2ggbT0gbGluZSBtdXN0IGhhdmUgYSB1bmlxdWUgcG9ydCBudW1iZXIuDQoNCj4gSSBk aWQgbm90IGluY2x1ZGUgYSBwb2xpY3kgb3B0aW9uIHRvIGZvcmNlIHVzZSBvZiB0aGUgc2FtZSBw b3J0OyB0aGUgY2xvc2VzdCB0aGluZyB3b3VsZCBiZSB0byB1c2UgYSBwb2xpY3kgb2YgImFsbCIs IHdoaWNoIHdpbGwgbWFyayBhbGwgbGluZXMgZXhjZXB0IHRoZSANCj4gZmlyc3QgYXMgYnVuZGxl LW9ubHkgYW5kIGFjaGlldmUgYmFzaWNhbGx5IHRoZSBzYW1lIHJlc3VsdCwgYWx0aG91Z2ggaXQg d291bGQgcmVxdWlyZSBhIHNlY29uZCBvZmZlciB0byB1cGRhdGUgdGhlIGJ1bmRsZS1vbmx5IHBv cnRzLiBJZiB0aGlzIGlzIGEgDQo+IHByb2JsZW0gd2UgY291bGQgY29uc2lkZXIgYWRkaW5nIGFu b3RoZXIgcG9saWN5IHZhbHVlLg0KDQpOb3Qgc3VyZSBJIGZvbGxvdy4gSSB0aGluayB0aGUgdXNh Z2Ugb2YgYnVuZGxlLW9ubHkgaXMgYSBzZXBhcmF0ZSBpc3N1ZS4NCg0KVGhlIHVzZS1jYXNlIEkg aGF2ZSBpbiBtaW5kIGlzIHdoZXJlIEkgd2FudCB0byBndWFyYW50ZWUgaW50ZXJvcGVyYWJpbGl0 eSwgc28gSSdkIGNob29zZSB0aGUgIm1heC1jb21wYXQiIHBvbGljeS4NCg0KSG93ZXZlciwgSSBk byBuZWVkIHRvIGJlIGFibGUgdG8gaW5kaWNhdGUgd2hldGhlciB0aGUgbT0gbGluZXMgc2hvdWxk IGhhdmUgdGhlIHNhbWUgcG9ydCBudW1iZXIgb3Igbm90IChhZ2FpbiwgZGVwZW5kaW5nIG9uIHdo ZXRoZXIgdGhlIHJlbW90ZSBwZWVyIGhhcyBpbmRpY2F0ZWQgc3VwcG9ydCBvZiBCVU5ETEUgb3Ig bm90KS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Mon Feb 24 09:07: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 58EE91A01EA for ; Mon, 24 Feb 2014 09:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.461 X-Spam-Level: * X-Spam-Status: No, score=1.461 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 w3Yiggp0dugP for ; Mon, 24 Feb 2014 09:07:45 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 76D8C1A01FD for ; Mon, 24 Feb 2014 09:07:44 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-9c-530b7c5ff4c8 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id C7.05.04853.F5C7B035; Mon, 24 Feb 2014 18:07:43 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 18:07:42 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: JSEP-06: How to create the second offer where only the port numbers are changed? Thread-Index: Ac8xgmHR3mZq1KQqQbqrDgGDhayzRA== Date: Mon, 24 Feb 2014 17:07:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1B55BF@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1B55BFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+JvjW58DXewwbEVshZbpwpZrP3Xzu7A 5LFgU6nHkiU/mQKYorhsUlJzMstSi/TtErgyjm43K7gkX7HqWRdLA+NF6S5GTg4JAROJhye2 MUPYYhIX7q1n62Lk4hASOMEosfxNEztIQkhgCaPE1r21XYwcHGwCFhLd/7RBwiIC6hKXH14A K2EWsJVY/3QqI4gtLBAt8fXFIlaImgSJdZ+ms0DYehJL/y5jA7FZBFQlzjTuANvLK+Arsamz HayGEeiG76fWMEHMFJf4cPA61G0CEkv2nIeyRSVePv7HCmErSaw9vJ0Foj5fYvrUfUwQMwUl Ts58wjKBUXgWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzFKFqcWF+em Gxno5abnluilFmUmFxfn5+kVp25iBMbPwS2/jXYwntxjf4hRmoNFSZz3OmtNkJBAemJJanZq akFqUXxRaU5q8SFGJg5OqQZGCTHJH25qvgm22xLVdl9l7b6VWuc9fc2sNckvQhTjHu0UCNa5 L3fxPFtMFr/4qc4rTzdK64coTciRvBtWfvxNb+O/5mtT1qtOMLg27Xd/NuelTwIsN1NYPKLn 9q74dNX05N8l39tzohImGm2yWu/38MnajUeKA5e9iDHMT472jk1i0WmqrwxQYinOSDTUYi4q TgQA29egeG0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0FfaFeTS3wuUYTnJ8jqK7tfwrKc Subject: [rtcweb] JSEP-06: How to create the second offer where only the port numbers are changed? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 17:07:46 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1B55BFESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As specified in BUNDLE, before the remote peer has indicated support of BUN= DLE, all m- lines (including those within to a bundle group) must have uniq= ue port numbers. Then, when the remote peer has indicated support of BUNDLE, a second offer = (called the BAS offer) needs to be sent, in which the same port number is a= ssigned to all m- lines within a bundle group. My question is: how do I create the BAS offer? I don't want to change anyth= ing - I just want to get an SDP with the BUNDLE port assigned to all m- lin= es. Is there a flag in createOffer() for that? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D1B55BFESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As specified in BUNDLE, before = the remote peer has indicated support of BUNDLE, all m- lines (including th= ose within to a bundle group) must have unique port numbers.

 

Then, when the remote peer has = indicated support of BUNDLE, a second offer (called the BAS offer) needs to= be sent, in which the same port number is assigned to all m- lines within = a bundle group.

 

My question is: how do I create= the BAS offer? I don’t want to change anything – I just want t= o get an SDP with the BUNDLE port assigned to all m- lines. Is there a flag= in createOffer() for that?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D1B55BFESESSMB209erics_-- From nobody Mon Feb 24 10:58: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 8FCFE1A02B4 for ; Mon, 24 Feb 2014 10:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 dmEaWEcKG5qL for ; Mon, 24 Feb 2014 10:58:51 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5B01A0154 for ; Mon, 24 Feb 2014 10:58:50 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id z12so4953545wgg.17 for ; Mon, 24 Feb 2014 10:58:50 -0800 (PST) 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=zBJtKas5tis1Ukd3UBmVwOT8VvZtNVUvAdWFWUbkGAM=; b=j4kVJNOe6En2vZKJE/HFIZOJ3u2/3hSd+vSsxXDq0Yefir32deb36HLuBd/ivJrwuR N50akj79ldkbPv/UKjafeY4uuo4LFowbfIaeLfLqg9cgkEtXlXGU+Gkjeo8UBUYSiSWb OYBi4WUy4/RNFLNzqcUwmzQOXjKfi/Hn02A3GtECR8KA2I2+lTBNS5DCKQcUHerG/2ZY 5/y1XKiuad16lknOnp4TgFOBwulHIHwxm898jEFJhPuU3Y2JL37IP/fFp2QZPsr6kI6C aR9YVjSVV07sUDVPKeHQZGIVjVvsHUZZL9/wXo3hX+RNqxfnTinjKe8F2cQvxQI4jwyA 8Z6A== MIME-Version: 1.0 X-Received: by 10.180.84.73 with SMTP id w9mr15643029wiy.58.1393268329984; Mon, 24 Feb 2014 10:58:49 -0800 (PST) Received: by 10.227.10.196 with HTTP; Mon, 24 Feb 2014 10:58:49 -0800 (PST) In-Reply-To: <530B194F.4040909@ericsson.com> References: <530627C7.30906@ericsson.com> <53070996.9040707@ericsson.com> <530B194F.4040909@ericsson.com> Date: Mon, 24 Feb 2014 10:58:49 -0800 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IeIGf8kgC06Qb2Q9R6qrq8eGnm4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 18:58:52 -0000 On 24 February 2014 02:05, Magnus Westerlund wrote: > My position is that the above mitigation is unlikely to have significant > impact on this attack. That was my sense too. > There are two reasons I wanted this attack to be considered. First, it > provides a clear requirement on having congestion control as first level > mitigation. Congestion control. Check. > Secondly, I think this could become a significant issue as data channel > PeerConnections can be opened without user consent. A malicious JS that > is sufficient well spread with a well working find and connect could > establish a large mesh of peer connections that could come close to > saturate each endpoints local access link, resulting in very heavy loads > on the network, even with congestion control. With congestion control > you can likely prevent congestion collapse, but you should be fully > capable of driving a network into a state of "mostly useless", > especially a network suffering from buffer bloat inside of the ingress > nodes. So the concern is that even with congestion control, a single bad actor can use more than their "fair" share of network resources. Sadly, this is already true on the web. No harm in writing down the potential. Are you looking for anything more than that? From nobody Mon Feb 24 11:03: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 580091A0186 for ; Mon, 24 Feb 2014 11:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 FuS-YXoPVYLc for ; Mon, 24 Feb 2014 11:03:11 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E68171A0151 for ; Mon, 24 Feb 2014 11:03:10 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id bs8so3487832wib.12 for ; Mon, 24 Feb 2014 11:03:09 -0800 (PST) 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=aKZSQX9l/4TXXU1rEMScqCG0akvh1AOEKlemacCiFks=; b=sI7jTToyZSF+RlWj5iDvtkRF1GhLSGkB7bwJLqT/XVwhQhPlaH1hJ9PEdvEoEH8agD LPm6rpmmvjbDnkfO+r/D+oEWGsjVmjRKo3wZTQ6DwXI+BMEPkM5Io1HVXpo5G4X6XqEh Af6cxe4zYbyQzOHcLGHsx0qZaK+GQv+bkFlTkBx97qfEcAlRY7zFNBx1eWIGlkSBcmc7 NaZdIPP/iyT2EPQzGSezv6RA807jWFWQiJohbI66NJEsA0P0oywjk30n++XZlySpMal/ DHSgGZQTyNtH/oxHptPPxpRyn9nz2Lm9mnuCr80Ki/1UdXHjSnqEmuowFaHxO+84jNj0 pqGA== MIME-Version: 1.0 X-Received: by 10.180.84.73 with SMTP id w9mr15659795wiy.58.1393268589909; Mon, 24 Feb 2014 11:03:09 -0800 (PST) Received: by 10.227.10.196 with HTTP; Mon, 24 Feb 2014 11:03:09 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B552E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B552E@ESESSMB209.ericsson.se> Date: Mon, 24 Feb 2014 11:03:09 -0800 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Bwk0mys5DKkHk5AKnIMUY-hdtBc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-06: max-bundle policy 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, 24 Feb 2014 19:03:12 -0000 On 24 February 2014 08:54, Christer Holmberg wrote: > The text says that all streams other than the first will be marked as > bundle-only. But, will the application have any clue which media type that > first stream will be? Should we e.g. specify that it MUST be audio (if audio > is enabled)? I'd prefer not. I'm OK with having a recommendation (or RECOMMENDED), but not MUST. If anything, the idea here is to select the media section that is *most important*. That's going to be application-specific. Common usages might have audio being the most important, but that's not a universal principal. MUST would also require a higher degree of specification. Do you prefer video over application? Does it matter which application? What if video is more important? From nobody Mon Feb 24 11:09: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 CD4451A0186 for ; Mon, 24 Feb 2014 11:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.145 X-Spam-Level: ** X-Spam-Status: No, score=2.145 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, 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 A7C5KQj-vtoH for ; Mon, 24 Feb 2014 11:09:16 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 67D2E1A0154 for ; Mon, 24 Feb 2014 11:09:15 -0800 (PST) Received: from [10.0.6.246] (p578b6f8e.dip0.t-ipconnect.de [87.139.111.142]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id F387A1C1042E7; Mon, 24 Feb 2014 20:09:13 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <530965D5.9090105@alum.mit.edu> Date: Mon, 24 Feb 2014 11:12:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1B3F1D52-0F89-4F87-AB70-C1FAA73EC8EC@lurchi.franken.de> References: <530965D5.9090105@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Sk89joHH-CK2f9o9Yq1s9Sfl470 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-protocol-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 19:09:20 -0000 On Feb 23, 2014, at 4:07 AM, Paul Kyzivat wrote: > A few comments on this draft: >=20 > * Section 5.1: >=20 > DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel provides > a partial reliable in-order bi-directional Communication > channel. User messages might not be transmitted or > retransmitted after a specified life-time given in milli- > seconds in the Reliability Parameter. This life-time starts > when providing the user message to the Javascript engine. >=20 > The last sentence above is troubling. This protocol won't always be = used via Javascript. Can we please have a definition that OK. What about replacing the last sentence with This life-time starts when providing the user message to the protocol stack. > doesn't depend on that? Is the timing being done by SCTP, or are you = assuming that a data channel layer on top of SCTP is doing this? Is it = specific to SCEP, or is it still applicable when the channel has been = established via external negotiation? It is actually the time when the message is provided to the SCTP stack, = but I think there might be some code running between the SCTP code and the user code = (let it be JS or anything else). I'm assuming that there is no substantial = buffering happening there. >=20 > Does use of this option imply that retransmission continues until this = time limit is reached? Or might it stop after some implementation = defined number of retransmissions? The only way the retransmissions don't happen until the time limit is = reached, is that SCTP decides that the association is broken because of excessive = retransmissions. =20 >=20 > The description of the reliability parameter says: >=20 > This field is ignored if a reliable channel is used. >=20 > IMO folk wisdom says that some specific value (e.g., 0) should be = prescribed to be used in such cases. That makes things more = deterministic and provides more flexibility in extending the protocol in = the future. What about: For reliable channels this field MUST be set to 0 on the sending side and MUST be ignored no the receiving side. >=20 > The name "Protocol" (and "Protocol Length") here is troublesome, = because it is ambiguous with other sorts of uses. (See my comment about = this point earlier today wrt draft-ietf-rtcweb-data-channel-07.) Others = (including draft-ejzak-mmusic-data-channel-sdpneg-00 and websockets) = call this "subprotocol". Using that would make it a little less = confusing. In the W3C specification it is also called protocol, but the text talks = about sub-protocol. Maybe we should do the same here. >=20 > Also, ISTM that all of these things are applicable to externally = negotiated channels, and so ought to be defined by = draft-ietf-rtcweb-data-channel. (But of course their use in the = DATA_CHANNEL_OPEN message belongs here.) Reliability is discussed there, but I agree, we need to discuss label = and protocol there, too. >=20 > * Section 8.4: >=20 > ISTM there ought to be a template of the minimum information that the = specification for a registered (sub)protocol MUST (SHOULD?) include. = E.g., >=20 > - what Channel Type(s) are valid for this (sub)protocol I assumed all... > - A contact for more information about this protocol You need to provide a reference for the protocol. Isn't that enough? Best regards Michael >=20 > Thanks, > Paul >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Feb 24 11:16: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 1D57E1A01CA for ; Mon, 24 Feb 2014 11:16:22 -0800 (PST) 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_50=0.8, RCVD_IN_DNSWL_HI=-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 xNHobBq8pdWR for ; Mon, 24 Feb 2014 11:16:19 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 617571A0235 for ; Mon, 24 Feb 2014 11:16:17 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1OJGDkl009767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Feb 2014 13:16:14 -0600 (CST) 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 s1OJG2I0009371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 14:16:13 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 24 Feb 2014 14:16:04 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Richard Ejzak Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YA= Date: Mon, 24 Feb 2014 19:16:03 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B5305@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lTOdjinEzQ-AbLdDgEUe1Tgp2Mg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 19:16:22 -0000 > >>>> Q4: > >>>> > >>>> I have issues with the max_retr, max_time and unordered parameters. > >>>> > >>>> First, they seem to specify SENDING capabilities, rather than RECEIV= ING > capabilities. > >>>> > >>>> Second, they seem to describe characteristics associated with the > subprotocol, in which case they could be specified in the associated > subprotocol specification. > >>> > >>> This should be a topic for discussion in London. =A0As it is currentl= y > written, these parameters are of the "take it or leave it" variety, i.e., > the answerer either accepts the options listed > >>> in the offer or rejects the data channel outright. =A0This is true fo= r the > in-band control protocol (please correct me if I am wrong on this), so we > adopted the same approach for the > >>> SDP-negotiated case. =A0Some have suggested that we should allow more > flexibility in negotiation of these parameters when using SDP. =A0If ther= e is > general agreement that it should be > >>> done this way, I see no problem with defining parameter negotiation > rules for SDP in the next version of the draft. > >> The difference is that your draft is based on Offer/Answer, which is > about indicating receiving capabilities (yes, I know we have broken that > rule in the past). > > > > There are many examples of attributes that use different negotiation > models than this. =A0The only requirement is that the semantics of the > negotiation be defined in the document defining the attribute. >=20 > I still don't think the information belong to SDP - they define protocol > characteristics. The protocol specification should define re-transmission > timers etc. >=20 > Anyway, we can argue about it later. At this moment I think the focus sho= uld > be on whether to move forward with the mechanism to begin with, and the m= ain > feature of the mechanism - which is about negotiating usage of channels := ) [Raju] Sorry to continue this discussion here instead of London, which I wo= n't be attending. I also believe that we do need these max_retr, max_time and unordered in th= e SDP. These map to the data channel init parameters specified in http://dev.w3.or= g/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel . In case of DCP th= ese are used by "5.1. DATA_CHANNEL_OPEN Message" of http://tools.ietf.org/= html/draft-ietf-rtcweb-data-protocol-03=20 Combination of these parameters will determine the type of=20 DATA_CHANNEL_OPEN open that will be sent. For non-DCP external negotiation use case, these values have to be communic= ated to the peer. Since we want to closely follow DCP, which allows only on= e set of these values to be negotiated for both the directions, SDP offer/a= nswer will do that same. Receiving end should accept these values, give it = to data channel stack and echo them back to the offerer. This way in external negotiation case as well, similar to DCP, both the pee= rs will have same set of data channel attributes (reliable or partial relia= ble, ordered or unordered, timed or # of retransmission). We will make the following changes, if agreed by others, in the next draft: 1. Add a new "reliable/partial reliable" SDP attribute, which is missing no= w. This is needed to map to the exact data channel type using external nego= tiation. 2. Map these SDP attributes to relevant DCP and PeerConnection sections. Need to make updates to SDP whenever DCP and/or PeerConnection is change= d. 3. Specify either max_retr (retransmit data channel) or max_time (timed dat= a channel) =20 present, but NOT both. Best Regards Raju From nobody Mon Feb 24 11:24: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 442851A022D for ; Mon, 24 Feb 2014 11:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, 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 KNyqFh1GViFF for ; Mon, 24 Feb 2014 11:24:44 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2A01A01B9 for ; Mon, 24 Feb 2014 11:24:44 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-ae-530b9c7a89b2 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4D.21.10875.A7C9B035; Mon, 24 Feb 2014 20:24:43 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 20:24:42 +0100 From: Christer Holmberg To: Martin Thomson Thread-Topic: [rtcweb] JSEP-06: max-bundle policy questions Thread-Index: Ac8xgReyx0/WK3m4RUOln8j3WJLYRQACZUGAAALZDko= Date: Mon, 24 Feb 2014 19:24:41 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1B552E@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+JvjW71HO5ggwN3+C2unfnHaLH2Xzu7 A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVxs/Mhc8Ffzoo7Z/6wNzD+Ze9i5OSQEDCR 6Pr/mQnCFpO4cG89WxcjF4eQwCFGiSvvr7JDOEsYJZ5/usrYxcjBwSZgIdH9TxukQURAV2LR 2Qdgg5gF1CXuLD4HZgsLWElMnb2ODaLGWmLv0y8sELaVxIOzJ8BqWARUJRYt7GUFsXkF3CT6 Ztxkgdg1iVHi+82zYM2cAoESuyb/AbuOEei676fWMEEsE5e49WQ+1NUCEkv2nGeGsEUlXj7+ xwpRoyOxYPcnNghbW2LZwtfMEMsEJU7OfMIygVF0FpJRs5C0zELSMgtJywJGllWM7LmJmTnp 5YabGIHRcHDLb90djKfOiRxilOZgURLn/fDWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD I5fWo2ObL954PLVaSvCrDvtk298igUcYTnzo5OU52TBl2kvbjf9+7Z8yaaqzwYrERxXvUpSv TF7TnSAufvQbXw7bci+PcCbhJ6+WLF75+2zAbIX7c75tnqjeVFnMu/JW1EGllc/LJpTKbk8S zrWq3upsuUD/n+pMs+zwnyGe/M+Cbn8SVdv44ZUSS3FGoqEWc1FxIgDwwgZ/VAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/icPeB50xehtdBZmAzbmJpl6xJeI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-06: max-bundle policy 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, 24 Feb 2014 19:24:46 -0000 Hi Martin, I buy the argument that different applications may have different prioritie= s regarding media type, so a "MUST audio" is not a good idea. But, should the application then be able to indicate which media type (or, = even which media source) shall be considered "first"? The browser probably = has no clue? Regards, Christer Sent from my Sony Ericsson Xperia arc S Martin Thomson wrote: On 24 February 2014 08:54, Christer Holmberg wrote: > The text says that all streams other than the first will be marked as > bundle-only. But, will the application have any clue which media type tha= t > first stream will be? Should we e.g. specify that it MUST be audio (if au= dio > is enabled)? I'd prefer not. I'm OK with having a recommendation (or RECOMMENDED), but not MUST. If anything, the idea here is to select the media section that is *most important*. That's going to be application-specific. Common usages might have audio being the most important, but that's not a universal principal. MUST would also require a higher degree of specification. Do you prefer video over application? Does it matter which application? What if video is more important? From nobody Mon Feb 24 11:30: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 76FE01A020E for ; Mon, 24 Feb 2014 11:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 JDRvXKqJhsTj for ; Mon, 24 Feb 2014 11:30:09 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6031A01E1 for ; Mon, 24 Feb 2014 11:30:09 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id u57so4993413wes.41 for ; Mon, 24 Feb 2014 11:30:08 -0800 (PST) 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=h/hODeFUzW9NcaBChRd+o5kS8yWgZv1c8cAI0+Obr20=; b=nUlExPcK+BUVgh+oO3yaGPtHsWAUmPfiIyFY8//L9YyZYU7Yv1pIXgMoMuufW1d9t3 D2dwnfByEq2eExxUzYLxbeyPNKGAwKeU9nV5S+vxA8HkkyvnJ4WuQA4DN/hjpaBtqy3U e+DQnd9LBoxYH1FSNGlZNNbz/yhX3rSrKmZ+w6ucAWvWRUyKekv5eB9bHVoRoZDR9bDn BimJTDlXIrSYiL7uxTh5fXtf21yVy3OoJo1aN0hU9mPxzk20vAvz1fjPQQdhjSzY+bpF eH7X3KM4IZOnvAXVVJ1xDVMC7L/WsC557mzo0bBamYk4odBXOLRq5Z1sfhXdsmf2OAny +o4g== MIME-Version: 1.0 X-Received: by 10.194.110.41 with SMTP id hx9mr20984575wjb.28.1393270208606; Mon, 24 Feb 2014 11:30:08 -0800 (PST) Received: by 10.227.10.196 with HTTP; Mon, 24 Feb 2014 11:30:08 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D1B552E@ESESSMB209.ericsson.se> Date: Mon, 24 Feb 2014 11:30:08 -0800 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ja3_1e62igpFhNhipOZhn-Ixsi0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-06: max-bundle policy 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, 24 Feb 2014 19:30:11 -0000 On 24 February 2014 11:24, Christer Holmberg wrote: > But, should the application then be able to indicate which media type (or, even which media source) shall be considered "first"? The browser probably has no clue? I think that Justin has proposed a way to identify tracks that should not be bundled. I recall no objections to this [1]. I'd assume that with only one track being marked that way, that track could be the one that gets ports and the others not. [1]... though I can't find anything in the API spec, and we did have the discussion at an IETF meeting and nowhere else. Maybe the W3C don't know about it yet. From nobody Mon Feb 24 12:02: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 82D791A01DA for ; Mon, 24 Feb 2014 12:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, 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 ytkOJ7JqU0DY for ; Mon, 24 Feb 2014 12:02:15 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 17F661A020D for ; Mon, 24 Feb 2014 12:01:48 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-85-530ba52bcf81 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8F.23.10875.B25AB035; Mon, 24 Feb 2014 21:01:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 21:01:47 +0100 From: Christer Holmberg To: Martin Thomson Thread-Topic: [rtcweb] JSEP-06: max-bundle policy questions Thread-Index: Ac8xgReyx0/WK3m4RUOln8j3WJLYRQACZUGAAALZDkr///DBAP//5uqA Date: Mon, 24 Feb 2014 20:01:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1B597C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B552E@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvja72Uu5ggzNvrC2unfnHaLH2Xzu7 A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWx6vk85oJz7BXfzt5mbmDcwt7FyMkhIWAi sevXOlYIW0ziwr31bF2MXBxCAocYJabPamCEcJYwSkx8/hMow8HBJmAh0f1PG6RBREBXYtHZ B2CDmAXUJe4sPgdmCwtYSXy4+pEdosZaYu/TLywQtpvEz8WbwJaxCKhKXFiyACzOK+Ar8e/O NajFM5gkTv64BNbMKRAosbP3LFgRI9B130+tYYJYJi7x4eB1ZoirBSSW7DkPZYtKvHz8D+ob JYm1h7ezgNzMLKApsX6XPkSrosSU7ofsEHsFJU7OfMIygVFsFpKpsxA6ZiHpmIWkYwEjyypG 9tzEzJz0csNNjMAIObjlt+4OxlPnRA4xSnOwKInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyI kYmDU6qBcQKnqZnfhg1f67sz/cOPKUYEPrO9ybGSU7Jp5rrvmZcqvMMuu93V6fC0fnbCPZnN WfEwz28m7aiulUZ/F5Yc+/lRN0tc4+nD1U19j3Ju51hbX3VX01BI3OtZI3GxmH33K+7QZj6W +NsMj2pSm2uOb3m82usE621WhpXzDB9Y8vz89nL92goFJZbijERDLeai4kQA1hw9Yl4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fR2cs8bHBILqLaP3BwPi9zx5vTA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-06: max-bundle policy 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, 24 Feb 2014 20:02:16 -0000 SGksDQoNCj4+IEJ1dCwgc2hvdWxkIHRoZSBhcHBsaWNhdGlvbiB0aGVuIGJlIGFibGUgdG8gaW5k aWNhdGUgd2hpY2ggbWVkaWEgdHlwZSAob3IsIGV2ZW4gd2hpY2ggbWVkaWEgc291cmNlKSBzaGFs bCBiZSBjb25zaWRlcmVkICJmaXJzdCI/IFRoZSBicm93c2VyIHByb2JhYmx5IGhhcyBubyBjbHVl Pw0KPg0KPiBJIHRoaW5rIHRoYXQgSnVzdGluIGhhcyBwcm9wb3NlZCBhIHdheSB0byBpZGVudGlm eSB0cmFja3MgdGhhdCBzaG91bGQgbm90IGJlIGJ1bmRsZWQuICBJIHJlY2FsbCBubyBvYmplY3Rp b25zIHRvIHRoaXMgWzFdLiAgSSdkIGFzc3VtZSB0aGF0IHdpdGggb25seSBvbmUgdHJhY2sgYmVp bmcgbWFya2VkIHRoYXQgd2F5LCB0aGF0IHRyYWNrIGNvdWxkIGJlIHRoZSBvbmUgdGhhdCBnZXRz IHBvcnRzIGFuZCB0aGUgb3RoZXJzIG5vdC4NCj4NCj4NCj4gWzFdLi4uIHRob3VnaCBJIGNhbid0 IGZpbmQgYW55dGhpbmcgaW4gdGhlIEFQSSBzcGVjLCBhbmQgd2UgZGlkIGhhdmUgdGhlIGRpc2N1 c3Npb24gYXQgYW4gSUVURiBtZWV0aW5nIGFuZCBub3doZXJlIGVsc2UuICBNYXliZSB0aGUgVzND IGRvbid0IGtub3cgYWJvdXQgaXQgeWV0Lg0KDQpKU0VQLTA2IGRlZmluZXMgZGlmZmVyZW50IEJV TkRMRSBwb2xpY2llcywgYnV0IHRoZXkgYXJlIG5vdCBvbiBwZXIgdHJhY2svbS1saW5lIGxldmVs Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K From nobody Mon Feb 24 12:07: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 7A2E81A02B6 for ; Mon, 24 Feb 2014 12:07:45 -0800 (PST) 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_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 FCLBNJG08jGz for ; Mon, 24 Feb 2014 12:07:43 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 31FC11A02AD for ; Mon, 24 Feb 2014 12:07:43 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-23-530ba68d84d6 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 23.B9.04249.D86AB035; Mon, 24 Feb 2014 21:07:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 21:07:40 +0100 From: Christer Holmberg To: Michael Tuexen , Paul Kyzivat Thread-Topic: [rtcweb] Comments on draft-ietf-rtcweb-data-protocol-03 - Protocol IANA registration information Thread-Index: Ac8xnA0wyaOYJez3T5i7IuW8nBbppw== Date: Mon, 24 Feb 2014 20:07:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1B59BB@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI 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+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvjW7vMu5ggym7zS0uNi1htFix4QCr xdp/7ewOzB5/339g8liy5CeTx4aWHUwBzFFcNimpOZllqUX6dglcGcuv9DEW/GOteHFuPmsD 4yOWLkZODgkBE4mvz3+wQ9hiEhfurWfrYuTiEBI4wijRtv8PI4SzhFHiZ2sbaxcjBwebgIVE 9z9tkAYRgViJy583sIHYzALqEncWnwMbJCyQL/Gw7Tg7RE2BxIyjp9ggbD2JM7ebmEHGsAio SnxYpg4S5hXwlVi+dzZYCSPQDd9PrWGCGCku8eHgdWaI2wQkluw5D2WLSrx8/I8VwlaSWHt4 OwtEvY7Egt2foM7Rlli28DUzxHxBiZMzn7BMYBSZhWTsLCQts5C0zELSsoCRZRUjR3FqcVJu upHBJkZgHBzc8ttiB+PlvzaHGKU5WJTEeT++dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wOi6uHXttTXTZgYvlTVKk7/ZuzG8+J/AxKUB/0rY8883ZTjFPf19kFnAr2FBpivvqUVvYi8m BnUWN51iLBL8nVDKYx75REd7dryCdMIG9aMF+s2O91n07rzhYY7RXVu746PxnsqpSbGOLySq z+VsDamcUvG71ntxqaSVhUF6sOXcytMVn6wTlViKMxINtZiLihMBrMiLglECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-gjHxa33Sfi4hkVKr2UIDoUfR9Y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-protocol-03 - Protocol IANA registration information X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 20:07:45 -0000 Hi, >> * Section 8.4: >>=20 >> ISTM there ought to be a template of the minimum information that the=20 >> specification for a registered (sub)protocol MUST (SHOULD?) include.=20 >> E.g., >>=20 >> - what Channel Type(s) are valid for this (sub)protocol >> I assumed all... >> - A contact for more information about this protocol > You need to provide a reference for the protocol. Isn't that enough? The question is what information that reference needs to contain. For example, if a protocol requires reliability, the reference needs to spe= cify that a reliable data channel must be opened.=20 The protocol may also define procedures regarding who is responsible for op= ening the data channel.=20 Etc etc etc. Regards, Christer From nobody Mon Feb 24 12:15: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 4B8C31A0131 for ; Mon, 24 Feb 2014 12:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 oDCMimSsEVhf for ; Mon, 24 Feb 2014 12:15:39 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 89F671A024D for ; Mon, 24 Feb 2014 12:15:38 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-bb-530ba8690ddb Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id E6.C0.04853.968AB035; Mon, 24 Feb 2014 21:15:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 21:15:36 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Richard Ejzak" Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EA== Date: Mon, 24 Feb 2014 20:15:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+JvjW7mCu5gg3MTpCwaNl5htXjW28Bq sfZfO7sDs0frs72sHjtn3WX3WLLkJ1MAcxSXTUpqTmZZapG+XQJXxt/Vj9gKTqhUzL7bwNjA eE22i5GTQ0LARGJX93MWCFtM4sK99WxdjFwcQgInGCUOPdzICOEsYZQ4+/AlcxcjBwebgIVE 9z9tkAYRgSKJb5//gTUzC6hL3Fl8jh3EFhaIldh9dD0jRE2cxKMH29gh7DCJ3lXz2EBsFgFV iUNH/oPV8Ar4Srw7+oEJYtc2Zol1z+8zgSQ4gQbNe9ELVsQIdN33U2uYIJaJS3w4eJ0Z4moB iSV7zkPZohIvH/9jhbCVJNYe3g51nJ7EjalT2CBsbYllC18zQywWlDg58wnLBEaxWUjGzkLS MgtJyywkLQsYWVYxShanFhfnphsZ6OWm55bopRZlJhcX5+fpFaduYgRG18Etv412MJ7cY3+I UZqDRUmc9zprTZCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxq3Jp5ccelLmNe3dx1sZ513/ SGd1rVfq33/nufTFnJqlhsLzf9VeSdV56HKDP53hK+eRqYZrFzw4mHvrCaNBH+P89ZoREjVB 7C99KiO3Gz8vmft3pbrLOR/rmu8/hC+1hD+KnxS/IPrXi+AzDq6lZ2RrLoR1q22+t/D802qB xIKJc19pVOtx31ViKc5INNRiLipOBACDZA4BfAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dZKbSAq0oo9xhbpi58aLaw-34U4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 20:15:40 -0000 Hi, I don't see why an SDP based mechanism by default must provide the same cap= abilities as the DCP. If you need to communicate everything that DCP provid= es, then you use DCP. Otherwise you may use SDP (or whatever other external= mechanism). OR, you can define a mechanism to communicate low-level information (re-tra= nsmission timer values etc) within the protocol that you are going to trans= port on top of the data channel. Anyway, can you give me an example of a case where you want to use SDP, and= where you need to negotiate the re-transmission values etc? Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Makaraju, Maridi Raju (Raju) [mailto:Raju.Makaraju@alcatel= -lucent.com]=20 L=E4hetetty: 24. helmikuuta 2014 21:16 Vastaanottaja: Christer Holmberg; Richard Ejzak Kopio: rtcweb@ietf.org Aihe: RE: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-chan= nel-sdpneg-00 > >>>> Q4: > >>>> > >>>> I have issues with the max_retr, max_time and unordered parameters. > >>>> > >>>> First, they seem to specify SENDING capabilities, rather than=20 > >>>> RECEIVING > capabilities. > >>>> > >>>> Second, they seem to describe characteristics associated with the > subprotocol, in which case they could be specified in the associated=20 > subprotocol specification. > >>> > >>> This should be a topic for discussion in London. =A0As it is=20 > >>> currently > written, these parameters are of the "take it or leave it" variety,=20 > i.e., the answerer either accepts the options listed > >>> in the offer or rejects the data channel outright. =A0This is true=20 > >>> for the > in-band control protocol (please correct me if I am wrong on this), so=20 > we adopted the same approach for the > >>> SDP-negotiated case. =A0Some have suggested that we should allow=20 > >>> more > flexibility in negotiation of these parameters when using SDP. =A0If=20 > there is general agreement that it should be > >>> done this way, I see no problem with defining parameter=20 > >>> negotiation > rules for SDP in the next version of the draft. > >> The difference is that your draft is based on Offer/Answer, which=20 > >> is > about indicating receiving capabilities (yes, I know we have broken=20 > that rule in the past). > > > > There are many examples of attributes that use different negotiation > models than this. =A0The only requirement is that the semantics of the=20 > negotiation be defined in the document defining the attribute. >=20 > I still don't think the information belong to SDP - they define=20 > protocol characteristics. The protocol specification should define=20 > re-transmission timers etc. >=20 > Anyway, we can argue about it later. At this moment I think the focus=20 > should be on whether to move forward with the mechanism to begin with,=20 > and the main feature of the mechanism - which is about negotiating=20 > usage of channels :) [Raju] Sorry to continue this discussion here instead of London, which I wo= n't be attending. I also believe that we do need these max_retr, max_time and unordered in th= e SDP. These map to the data channel init parameters specified in http://dev.w3.or= g/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel . In case of DCP th= ese are used by "5.1. DATA_CHANNEL_OPEN Message" of http://tools.ietf.org/= html/draft-ietf-rtcweb-data-protocol-03 Combination of these parameters will determine the type of DATA_CHANNEL_OPE= N open that will be sent. For non-DCP external negotiation use case, these values have to be communic= ated to the peer. Since we want to closely follow DCP, which allows only on= e set of these values to be negotiated for both the directions, SDP offer/a= nswer will do that same. Receiving end should accept these values, give it = to data channel stack and echo them back to the offerer. This way in external negotiation case as well, similar to DCP, both the pee= rs will have same set of data channel attributes (reliable or partial relia= ble, ordered or unordered, timed or # of retransmission). We will make the following changes, if agreed by others, in the next draft: 1. Add a new "reliable/partial reliable" SDP attribute, which is missing no= w. This is needed to map to the exact data channel type using external nego= tiation. 2. Map these SDP attributes to relevant DCP and PeerConnection sections. Need to make updates to SDP whenever DCP and/or PeerConnection is change= d. 3. Specify either max_retr (retransmit data channel) or max_time (timed dat= a channel) =20 present, but NOT both. Best Regards Raju From nobody Mon Feb 24 12:38: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 B24BA1A02F4 for ; Mon, 24 Feb 2014 12:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-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 ucRikw0UShU7 for ; Mon, 24 Feb 2014 12:38:26 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5991A0256 for ; Mon, 24 Feb 2014 12:38:25 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1OKcLQJ026213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Feb 2014 14:38:21 -0600 (CST) 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 s1OKcK8P010520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 15:38:20 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 24 Feb 2014 15:38:20 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Richard Ejzak Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EP/+ONLQ Date: Mon, 24 Feb 2014 20:38:19 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B59FA@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dMNHlauaXYBgAStjob6O67gSQ2Y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 20:38:28 -0000 Hi, > Hi, >=20 > I don't see why an SDP based mechanism by default must provide the same [Raju] Because, whether browser based or not each side will use a data chan= nel stack. Independent of DCP used or not, the data channel stack has to ha= ve these attributes to do various order/unordered, reliab/unreliable, retra= nsmit/timed modes. With external negotiation, the same SDP will be used to negotiate these val= ues (similar to what DCP data channel open does). This way the only difference between external based negotiation vs. DCP is = "DCP" itself, neither more nor less; rest of the attributes of data channel= are exactly identical on both ends. This is what we want to achieve with e= xternal negotiation. > capabilities as the DCP. If you need to communicate everything that DCP > provides, then you use DCP. Otherwise you may use SDP (or whatever other > external mechanism). [Raju] Using DCP means the intermediate elements have no ("easy") visibilit= y into what channels are being negotiated; such visibility is needed for va= rious reasons like to have interworking functionality with other protocols,= such as MSRP; or regulatory needs; or value added services with billing im= plications etc. >=20 > OR, you can define a mechanism to communicate low-level information (re- > transmission timer values etc) within the protocol that you are going to > transport on top of the data channel. [Raju] On top of data channel standard IANA registered protocols, such as M= SRP, will typically be used; so modifying such protocols for this use case = is not an option. >=20 > Anyway, can you give me an example of a case where you want to use SDP, a= nd > where you need to negotiate the re-transmission values etc? [Raju] A simple example would be 2 browsers talking thru an intermedia prox= y, which wants to know what protocols are being negitiated and used as part= of the session. 1. Calling client creates data channel (using http://dev.w3.org/2011/webrtc= /editor/webrtc.html#idl-def-RTCDataChannel) with desired attributes and set= s negotiated=3Dtrue. So, calling browser saves the attributes for the data = channel but won't use DCP. 2. These attributes are sent via SDP to peer client (via proxy). 3. Peer client sets these same attributes while creating data channel and s= ets negotiated=3Dtrue but won't do DCP. 4. Peer client echo the same attributes back in SDP answer. Now, data channel stacks on both ends will use same attributes, similar to = DCP use case, with the only difference being DCP is not used here. Best Regards Raju From nobody Mon Feb 24 14:10: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 D56001A02ED; Mon, 24 Feb 2014 14:10:13 -0800 (PST) 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_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 79hHDeNkKP9a; Mon, 24 Feb 2014 14:10:08 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id A3E481A028B; Mon, 24 Feb 2014 14:09:26 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402242309203001; Mon, 24 Feb 2014 23:09:20 +0100 From: "Karl Stahl" To: , "'Magnus Westerlund'" , References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> In-Reply-To: <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> Date: Mon, 24 Feb 2014 23:09:17 +0100 Message-ID: <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04DE_01CF31B5.71AA9500" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7EFbkmQFwvQDChQl+1C3afCRd/RgE7zuMwGiI2FdA= Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jtGYCAvGRgiGqDrPrw-Ama0T5Cc Cc: 'Colin Perkins' Subject: [rtcweb] [tram] Payload Types assignments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 22:10:14 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04DE_01CF31B5.71AA9500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I suggest to the RTCWEB WG that the below from the September and October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is introduced into draft-ietf-rtcweb-rtp-usage for usage of RFC 5285, to = allow: =20 (1) WebRTC applications to directly convey QoS related real-time traffic info to the network at points where RTP flow is directed to by TRAM = Milstone 3, to be used by *any network element implementing any suitable QoS = methods for the particular network* for=20 (2) *all* WebRTC browsers *and* clients, under *all* OSs, and *all* = current and future IP network, to achieve best QoE=20 (3) *without* having to force WebRTC into application specific networks (such as IMS) instead of using the Internet (including OTT). =20 The only further activity required, is to call for ISPs=92 to review = whether the traffic information transferred by RFC 5285 is sufficient for = current and future needs in their network as suggested in below repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =85two parameters (e.g. two bytes each) are encoded into the RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each for quality type e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Then this could be assigned numbers to have an RFC in place. =20 With TRAM milestone 3 also place,=20 market forces will drive ISPs and browser makers to implement just this, without even having it MUST-established. =20 =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. =20 Please see further emails soon following this one, for details and = history. =20 /Karl =20 =20 Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Karl Stahl Skickat: den 22 oktober 2013 16:37 Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus Westerlund' Kopia: 'Colin Perkins' =C4mne: [rtcweb] [avtext] Payload Types assignments was Re: SV: [mmusic] = WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 Harald, I mostly agree with the quality requirements of different = real-time traffic that the WebRTC browser/application may use. But rather than = asking the application, let's convey the bandwidth and priority requirements to = the network. Just like with the Payload type (that is hard to squeeze that information into) it must be visible to the network (and not changed by = the network, like diffserv bits are). Such marking must also be available = for incoming traffic, which is especially important in RSVP type of = networks, that has to reserve bandwidth for it. =20 =20 There is actually a good way to show these needs to the network (without using the PT, or diffserv bits, which aren=92t sufficient anyway).=20 =20 Let's use the RTP header extension field that also is visible outside = the encrypted payload. A week ago came http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that outlines the usage of the extension field for classification of traffic! This document does not yet outline what to put in there and how to = encode it though. =20 Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 = discusses other webrtc usages of the RTP header extension in 5.2 (there can be = many header extensions according to RFC 5285) and in 9 there is "WebRTC Use = of RTP: Future Extensions". =20 So, it looks obvious to use the RTP header extension to show the characteristics and bandwidth requirements to the network. It should not introduce any backward incompatibilities either. =20 Such marking is done in every RTP packet so it can be set individually = for each stream and could even be changed during a session (e.g. when = limiting the bandwidth based on RTCP feedback). RFC 5286 also specifies how RTP extension header usage can be negotiated in SDP. I think this could be easily done by the WebRTC browser for "all current and future needs" if properly specified now. =20 I suggest that two parameters (e.g. two bytes each) are encoded into the = RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each quality e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Please note the totally different requirements a diffserv and an RSVP network have to know, so let=92s put all into these bytes. (E.g. a = diffserv network don't need the bandwidth usage, but RSVP reservation networks = (e.g. cable and 3G/4G OTT) do. There one should initially reserve the maximum bandwidth indicated, but can later re-reserve.) =20 /Karl =20 PS Microsoft seems to have done work in this field, defining a = proprietary attribute =93MS Service Quality=94;=20 However that seems to apply to the TURN server allocation request and = would therefore: --- Apply to the whole UDP flow, and could not be set for each stream individually (with different requirements), and --- Does not handle the bandwidth requirement for incoming real-time = traffic (required to reserve in RSVP type of networks) However the quality attributes conveyed and their encoding may be considered. =20 This is 2.2.2.19 MS-Service Quality Attribute from=20 http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx=20 =20 MS-Service Quality Attribute The MS-Service Quality attribute is used to convey information about the data stream that the protocol client is intending to transfer over an allocated port. The protocol client SHOULD<21> include this attribute as part of an Allocate request message. A TURN server SHOULD use the information in this attribute to make decisions about resource = allocation, bandwidth prioritization, and data delivery methods. If the attribute is = not present in the Allocate request message, the TURN server SHOULD assume = that the data stream is audio with best effort delivery. The format of this attribute is as follows...=20 ... The following stream types are supported in this extension. All other = stream types are reserved for future use. =A7 "0x0001": Audio =A7 "0x0002": Video =A7 "0x0003": Supplemental Video =A7 "0x0004": Data Service Quality (2 bytes): The service quality level required by the protocol client for the stream. The following service quality levels are supported in this extension. = All other service quality levels are reserved for future use. =A7 "0x0000": Best effort delivery. =A7 "0x0001": Reliable delivery. =20 =20 -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Harald Alvestrand Skickat: den 8 oktober 2013 13:01 Till: rtcweb@ietf.org =C4mne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC = of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 On 10/08/2013 09:17 AM, Karl Stahl wrote: > Hej Magnus, >=20 >> Also, are you really interested in knowing that it is VP9 vs H.264,=20 >> isn't > the questions this is video of this priority that is important? >> I think you need to more carefully consider what are the goals you=20 >> try to > achieve them. >=20 > Actually, my concern is to get an idea of the maximum bandwidth that=20 > could be required for a WebRTC (ICE) setup media flow. Both voice and=20 > video should be prioritized over data (their individual priority is of = > less importance as long as there is sufficient bandwidth for both). =20 You don't know that without knowing what the application is for. In, for instance, a shooter game with voice backchannels, the movement = and event information (data) is MORE time sensitive than the voice data. =20 >=20 > With diffserv you don=92t need to know the bandwidth requirement, but=20 > with RSVP reservation (like in cable and mobile networks) you need to=20 > know how much to reserve. Voice is like 100's kbit/s, video VP8 or=20 > H.264 is like 3,5 mbps. =20 Again, without knowing the application, you don't know that. The application could decide to use QCIF or HD, and the bandwidth = variation of screencast (semi-static with sudden, large changes) is completely different from that of a talking head, which is again completely = different from a high-movement scene. =20 >=20 > To add to the complication of codec variants, the video codecs in=20 > question for WebRTC have variable bandwidth, and when there is a poor=20 > connection we see Chrome reducing the video window size to reduce the bandwidth used... >=20 > I think the payload type field at best can reflect a maximum bandwidth = > to initially reserve bandwidth for, and thereafter make new=20 > reservations if the bandwidth changes during the call. So could we=20 > change RTP to show maximum bandwidth instead of payload type in that=20 > field outside the encrypted payload :) ... Or maybe that is not a = joke? =20 I think these ruminations only lead to one conclusion: =20 You can't tell what the needed bandwidth is up front without asking the application. You can't tell what the right priority ranking is without asking the application. =20 If you need to know the bandwidth or the priority up front, the = application has to tell you. Anything else is pure heuristics. =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ------=_NextPart_000_04DE_01CF31B5.71AA9500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I = suggest to the RTCWEB WG that the below from the September and October = discussions on the relevant [rtcweb] [avtext] = [mmusic] = lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = is introduced into draft-ietf-rtcweb-rtp-usage = fo= r usage of RFC 5285, to allow:

 

(1= ) WebRTC applications to directly convey QoS related real-time traffic = info to the network at points where RTP flow is directed to by TRAM = Milstone 3, to be used by *any network element implementing any = suitable QoS methods for the particular network* for =

(2= ) *all* WebRTC browsers *and* clients, under *all* = OSs, and *all* current and future IP network, to achieve best QoE =

(3= ) *without* ha= ving to force WebRTC into application specific networks (such as IMS) = instead of using the Internet (including OTT).

 

Th= e only further activity required, is to call for ISPs’ to review = whether the traffic information transferred by RFC 5285 is sufficient = for current and future needs in their network as suggested in below = repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip><= o:p>

…two = parameters (e.g. two bytes each) are encoded into the RTP header = extension:

 

A) The = maximum bandwidth requirement: Two bytes could contain everything from = some bps for real-time text to Gbps for future 3D supersize = telepresence… on a logarithmic scale.

 

B) The = quality characteristics for the stream, with the highest bit set to 1, = we could allocate a bit each for quality type = e.g:

Best Effort, = Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. = video streaming), Minimum Delay, Reliable Delivery, Prioritize X, = Variation Y, that could be combined as required to describe the = stream.

 

And with = highest bit set to 0, there could instead be a number for special usage = that does not fit the general description of the individual = bits.

</snip>=

 

Th= en this could be assigned numbers to have an RFC in = place.

 

Wi= th TRAM milestone 3 also place,

ma= rket forces will drive ISPs and browser makers to implement just this, = without even having it MUST-established.

 

&#= 8220;Who does not want a “WebRTC-Ready” Internet = access?” and

&#= 8220;Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?” and vice = versa.

 

Pl= ease see further emails soon following this one, for details and = history.

 

/K= arl

 

 

Fr=E5n: = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Karl Stahl
Skickat: den 22 oktober 2013 = 16:37
Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus = Westerlund'
Kopia: 'Colin Perkins'
=C4mne: [rtcweb] = [avtext] Payload Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

Harald, I mostly agree with the quality requirements of = different real-time traffic that the WebRTC browser/application may use. = But rather than asking the application, let's convey the bandwidth and = priority requirements to the network. Just like with the Payload type = (that is hard to squeeze that information into) it must be visible to = the network (and not changed by the network, like diffserv bits are). = Such marking must also be available for incoming traffic, which is = especially important in RSVP type of networks, that has to reserve = bandwidth for it.  

 

There is actually a good way to = show these needs to the network (without using the PT, or diffserv bits, = which aren’t sufficient anyway).

 

Let's use the RTP header = extension field that also is visible outside the encrypted payload. A = week ago came h= ttp://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 =  that outlines the usage of the extension field for classification = of traffic! This document does not yet outline what to put in there and = how to encode it though.

 

Today's http:/= /tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 discusses other = webrtc usages of the RTP header extension in 5.2 (there can be many = header extensions according to RFC 5285) and in 9 there is "WebRTC = Use of RTP: Future Extensions".

 

So, it looks obvious to use the = RTP header extension to show the characteristics and bandwidth = requirements to the network. It should not introduce any backward = incompatibilities either.

 

Such marking is done in every = RTP packet so it can be set individually for each stream and could even = be changed during a session (e.g. when limiting the bandwidth based on = RTCP feedback). RFC 5286 also specifies how RTP extension header usage = can be negotiated in SDP. I think this could be easily done by the = WebRTC browser for "all current and future needs" if properly = specified now.

 

I suggest that two parameters (e.g. two bytes each) are = encoded into the RTP header extension:

 

A) The maximum bandwidth = requirement: Two bytes could contain everything from some bps for = real-time text to Gbps for future 3D supersize telepresence… on a = logarithmic scale.

 

B) The quality characteristics for the stream, with the = highest bit set to 1, we could allocate a bit each quality = e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, = Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable = Delivery, Prioritize X, Variation Y, that could be combined as required = to describe the stream.

 

And with highest bit set to 0, = there could instead be a number for special usage that does not fit the = general description of the individual bits.

 

Please note the totally = different requirements a diffserv and an RSVP network have to know, so = let’s put all into these bytes. (E.g. a diffserv network don't = need the bandwidth usage, but RSVP reservation networks (e.g. cable and = 3G/4G OTT) do. There one should initially reserve the maximum bandwidth = indicated, but can later re-reserve.)

 

/Karl

 

PS Microsoft seems = to have done work in this field, defining a proprietary attribute = “MS Service Quality”;

However that = seems to apply to the TURN server allocation request and would = therefore:

--- Apply to = the whole UDP flow, and could not be set for each stream individually = (with different requirements), and

--- Does not = handle the bandwidth requirement for incoming real-time traffic = (required to reserve in RSVP type of networks)

However the = quality attributes conveyed and their encoding may  be = considered.

 

This is 2.2.2.19 MS-Service Quality Attribute from =

http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).asp= x 

 

MS-Service = Quality Attribute

The MS-Service = Quality attribute is used to convey information about the data stream = that the protocol client is intending to transfer over an allocated = port. The protocol client SHOULD<21> include this attribute as = part of an Allocate request message. A TURN server SHOULD use the = information in this attribute to make = decisions about resource allocation, bandwidth prioritization, and data = delivery methods. If the attribute is not present in the Allocate = request message, the TURN server SHOULD assume that the data stream is = audio with best effort delivery. The format of this attribute is as = follows...

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

The following = stream types are supported in this extension. All other stream types are = reserved for future use.

=A7 = "0x0001&quo= t;: Audio

=A7 = "0x0002&quo= t;: Video

=A7 = "0x0003&quo= t;: Supplemental Video

=A7 = "0x0004&quo= t;: Data

Service Quality = (2 bytes): The service quality level required by the protocol client for = the stream.

The following = service quality levels are supported in this extension. All other = service quality levels are reserved for future use.

=A7 = "0x0000&quo= t;: Best effort delivery.

=A7 = "0x0001&quo= t;: Reliable delivery.

 

 

-----Ursprungligt meddelande-----

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r Harald Alvestrand

Skickat: den 8 oktober 2013 13:01

Till: rtcweb@ietf.org

=C4mne: Re: [rtcweb] Payload = Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

On 10/08/2013 09:17 AM, Karl = Stahl wrote:

> Hej Magnus,

> 

>> Also, are you really = interested in knowing that it is VP9 vs H.264,

>> = isn't

> the questions this is video of this priority that is = important?

>> I think you need to more carefully consider what = are the goals you

>> try to

> achieve = them.

> 

> Actually, my concern is to = get an idea of the maximum bandwidth that

> could be required for a = WebRTC (ICE) setup media flow. Both voice and

> video should be prioritized = over data (their individual priority is of

> less importance as long as = there is sufficient bandwidth for both).

 

You don't know that without = knowing what the application is for.

In, for instance, a shooter game = with voice backchannels, the movement and event information (data) is = MORE time sensitive than the voice data.

 

> 

> With diffserv you = don’t need to know the bandwidth requirement, but =

> = with RSVP reservation (like in cable and mobile networks) you need to =

> = know how much to reserve. Voice is like 100's kbit/s, video VP8 or =

> = H.264 is like 3,5 mbps.

 

Again, without knowing the = application, you don't know that.

The application could decide to = use QCIF or HD, and the bandwidth variation of screencast (semi-static = with sudden, large changes) is completely different from that of a = talking head, which is again completely different from a high-movement = scene.

 

> 

> To add to the complication = of codec variants, the video codecs in

> question for WebRTC have = variable bandwidth, and when there is a poor

> connection we see Chrome = reducing the video window size to reduce the bandwidth = used...

> 

> I think the payload type = field at best can reflect a maximum bandwidth

> to initially reserve = bandwidth for, and thereafter make new

> reservations if the = bandwidth changes during the call. So could we

> change RTP to show maximum = bandwidth instead of payload type in that

> field outside the encrypted = payload :) ... Or maybe that is not a joke?

 

I think these ruminations only = lead to one conclusion:

 

You can't tell what the needed = bandwidth is up front without asking the = application.

You can't tell what the right priority ranking is without = asking the application.

 

If you need to know the = bandwidth or the priority up front, the application has to tell you. = Anything else is pure heuristics.

 

_______________________________________________

rtcweb mailing = list

rtcweb@ietf.org

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

------=_NextPart_000_04DE_01CF31B5.71AA9500-- From nobody Mon Feb 24 14:22: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 932611A02FB; Mon, 24 Feb 2014 14:22:30 -0800 (PST) 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_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 2TdJ8oIFPPuN; Mon, 24 Feb 2014 14:22:26 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 80E061A02F3; Mon, 24 Feb 2014 14:22:25 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402242322233838; Mon, 24 Feb 2014 23:22:23 +0100 From: "Karl Stahl" To: "'Pal Martinsen \(palmarti\)'" , , References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> In-Reply-To: Date: Mon, 24 Feb 2014 23:22:20 +0100 Message-ID: <04ee01cf31ae$e296d500$a7c47f00$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04EF_01CF31B7.445B3D00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPLuh9NKjjBBbIvkuPAKYD51v6LZrD+kgA Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_CbWjZJbLmcR77WjmPZQI3i6Bx4 Cc: 'Oleg Moskalenko' , "'Yoakum, John H \(John\)'" Subject: Re: [rtcweb] [tram] I-D Action: draft-thomson-tram-turn-bandwidth-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, 24 Feb 2014 22:22:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04EF_01CF31B7.445B3D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi P=E5l, =20 You did not comment nor answer, in response to any of: http://www.ietf.org/mail-archive/web/tram/current/msg00275.html=20 http://www.ietf.org/mail-archive/web/tram/current/msg00273.html=20 whether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the application/browser to transfer relevant real-time traffic information (types and bandwidth) into every RTP package by using the already IETF standardized RTP extension header RCF 5285, which could be used by any current or future Internet (including OTT) network where WebRTC = real-time traffic may flow. It seems to have been standardized already 2008 to = allow such usage. =20 QoS related step C) draft-martinsen-tram-discuss can then be taken out = of TRAM, and step D) (that was never intended to be handled by TRAM anyway) will be handled elsewhere. =20 I have repeated my suggestion to RTCWEB WG from the October discussions = on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html to introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage suggesting usage of RFC 5285, where traffic information in RTP packets simply would be filled by any browser under any OS. =20 Without step B), TRAM =93Enforcing the real-time traffic through the offered/discovered TURN servers=94, the real-time traffic may happen = through the IP default gateways often congested by data traffic and QoS = insensitive streaming video and file sharing. Without specific QoS methods at those points, the network raw bandwidth capacity may have to be 10-folded to achieve sufficient QoE when WebRTC usage becomes popular. Methods like DISCUSS addresses such things occurring when STUN instead TURN is used = (by allowing flows into such congestion points), but only provides direct traffic info for outgoing (not incoming) real-time traffic and locally, therefore are not even applicable to reservation type of networks like = Cable Networks and Mobile OTT.=20 =20 That would leave certain network types to investing in raw bandwidth increase, instead of simply borrowing the bandwidth (from much larger = data traffic and QoS insensitive streaming video and file sharing at no = adverse effect) and making that borrowed no-cost bandwidth very valuable for the carriers when delivering to their customers. I know a few of you Cisco guys are among the ones that have been = fighting against the general =93it is all about bandwidth=94 and =93it will go = away with time=94-attitude within IETF work, e.g. see http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html, but = the pointers given in the current QoS discussion within TRAM:=20 =20 (i) will *not allow* ISP=92s to use already available and currently = deployable quality IP pipes for real-time traffic to also be used for WebRTC = generated real-time traffic. =20 (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. All networks will *also be inhibited* from the = very common and used method of simply providing an extra IP pipe (often = provided over the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) Newer, fiber only type of networks, can still borrow bandwidth at no = extra cost, *by proprietary usage* of RFC 5285 by browsers.=20 =20 (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may has to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes = intermittently are filled, whatever bandwidth is available). =20 Further explainations about QoS methods and their implementation were = given a few days ago in:=20 http://www.ietf.org/mail-archive/web/tram/current/msg00274.html=20 =20 (i), (ii) and (iii) will *seriously delay* usage of telepresence capable = and quality demanding WebRTC (bandwidth being around 30 times higher over = best effort Internet, than telephony over quality managed networks) and will *vastly increase cost* for ISPs to offer WebRTC with good QoE. =20 Below you are giving pointers saying =93They are currently working on a problem-statement draft and a use-case draft, any input to those would = be very helpful.=94 Those are unnecessary, risking leading to (i), (ii) and = (iii) above. =20 So are pointers such as: =93RMCAT where congestion avoidance for RTP is = being developed=94. TRAMs Milestone 3 is for the purpose of directing = real-time traffic where congestion control isn=92t already in place. Using RFC = 5285 available since 2008, to fill traffic information in RTP packets (step = D)) is probably a necessity for most future =93congestion control=94 = discussed. =20 This chicken-and-egg circular also applies to RTCWEB direction of QoS = issues to:=20 http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos=20 focusing on DSCP-mapping without even mentioning RFC 5285 available = since 2008, to fill traffic information in RTP packets where it is a = necessity and will allow:=20 (1) applications to directly convey QoS related real-time traffic info = to the network at points where RTP flow is directed to by TRAM Milstone 3, = to be used by *any network element implementing any suitable QoS methods = for the particular network* for=20 (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), = under *all* OSs, and *all* current and future IP networks=20 (3) *without* having to be forced into application specific networks = (PSTN, IMS) instead of using the Internet (including OTT). =20 The only activity required, is to call for ISPs=92 review whether the = traffic information transferred by RFC 5285 is sufficient for current and future needs in their network as suggested in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =85two parameters (e.g. two bytes each) are encoded into the RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each for quality type e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Then this could be assigned numbers to have the RFC in place. With TRAM milestone 3 also place,=20 market forces will drive ISPs and browser makers to implement just that, without even having it MUST-established. =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. =20 Please see further emails soon following this one, for details and = history. =20 /Karl =20 Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Pal Martinsen = (palmarti) Skickat: den 21 februari 2014 10:37 Till: tram@ietf.org Kopia: Karl Stahl; Oleg Moskalenko; Alan Johnston; Yoakum, John H (John) =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 Hi, =20 I agree the full QoS discussion should _not_ happen in TRAM. If you are interested in helping out in that area I suggest you looking into the = AEON mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are currently working on a problem-statement draft and a use-case draft, any input to those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). =20 That said, STUN have a few nice characteristics that makes it a perfect candidate for transporting some of the QoS information. IMHO that would = be extending the STUN spec and should be within the TRAM charter. The main goal of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and to start the discussion if TRAM is the appropriate place to have those on = the wire format discussions. =20 .-. P=E5l-Erik =20 =20 =20 =20 =20 =20 On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) = wrote: +1 I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts. There are other groups doing QOS = work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterprise VPNs, and various combinations and seldom suffer egregious quality issues. I am more concerned about carriers doing = things to regulate or degrade WebRTC flows than a failure of existing Internet mechanisms to enable them. =20 Significant focus on QOS before we better enable TURN to be easily used = in a browser environment taking advantage or normal web characteristics (as opposed to historic telephony constructs) would seem to be highly distracting at this point. =20 =20 Cheers, John =20 AVAYA 1.919.425.8446 =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 12:43 PM To: Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 =20 =20 On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston < alan.b.johnston@gmail.com> wrote: =20 =20 =20 Personally, I am not sure how much QoS is actually in scope for TRAM. = Have you been following RMCAT where congestion avoidance for RTP is being developed? I see some overlap in your goals and the goals of that work. - =20 =20 I'd concentrate on the TURN application-level functionality, for now, = and I'd leave QoS for the future discussions. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 ------=_NextPart_000_04EF_01CF31B7.445B3D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi= P=E5l,

 

Yo= u did not comment nor answer, in response to any = of:

= http://www.ietf.org/mail-archive/web/tram/current/msg00275.html =

= http://www.ietf.org/mail-archive/web/tram/current/msg00273.html =

wh= ether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the = application/browser to transfer relevant real-time traffic information = (types and bandwidth) into every RTP package by using the already IETF = standardized RTP extension header RCF 5285, which could be used by any = current or future Internet (including OTT) network where WebRTC = real-time traffic may flow. It seems to have been standardized already = 2008 to allow such usage.

 

Qo= S related step C) draft-martinsen-tram-discuss = ca= n then be taken out of TRAM, and step D) (that was never intended to be = handled by TRAM anyway) will be handled = elsewhere.

 

I = have repeated my suggestion to RTCWEB WG from the October discussions on = the relevant [rtcweb] [avtext] = [mmusic] = lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = to introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage sug= gesting usage of RFC 5285, where traffic information in RTP packets = simply would be filled by any browser under any OS.

 

Wi= thout step B), = TRAM = “En= forcing the real-time traffic through the offered/discovered TURN = servers”, the real-time traffic may happen through the IP default = gateways often congested by data traffic and QoS insensitive streaming = video and file sharing. Without specific QoS methods at those points, = the network raw bandwidth capacity may have to be 10-folded to achieve = sufficient QoE when WebRTC usage becomes popular. Methods like DISCUSS = addresses such things occurring when STUN instead TURN is used (by = allowing flows into such congestion points), but only provides direct = traffic info for outgoing (not incoming) real-time traffic and locally, = therefore are not even applicable to reservation type of networks like = Cable Networks and Mobile OTT.

 

Th= at would leave certain network types to investing in raw bandwidth = increase, instead of simply borrowing the bandwidth (from much larger = data traffic and QoS insensitive streaming video and file sharing at no = adverse effect) and making that borrowed no-cost bandwidth very valuable = for the carriers when delivering to their = customers.

=

I = know a few of you Cisco guys are among the ones that have been fighting = against the general “it is all about bandwidth” and = “it will go away with time”-attitude within IETF work, e.g. = see http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html, = but the pointers given in the current QoS discussion within TRAM: =

 

(i= ) will *not allow* ISP’s to use already available and = currently deployable quality IP pipes for real-time traffic to also be = used for WebRTC generated real-time traffic.

 

(i= i) will *not allow* some network types (e.g. Cable Networks and = Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive = streaming video and file sharing. All networks will *also be = inhibited* from the very common and used method of simply providing = an extra IP pipe (often provided over the same wire but level-2 = separated) dedicated for real-time usage

(<= b>*by resisting TRAM implementation of step = B*)

Ne= wer, fiber only type of networks, can still borrow bandwidth at no extra = cost, *by proprietary usage* of RFC 5285 by browsers. =

 

(i= ii) will leave most ISPs to *only use* raw bandwidth capacity = increase that may has to be 10-folded to reach sufficient QoE when = WebRTC usage becomes popular (if at all possible, since unmanaged IP = pipes intermittently are filled, whatever bandwidth is = available).

 

Fu= rther explainations about QoS methods and their implementation were = given a few days ago in:

= http://www.ietf.org/mail-archive/web/tram/current/msg00274.html =

 

(i= ), (ii) and (iii) will *seriously delay* usage of telepresence = capable and quality demanding WebRTC (bandwidth being around 30 times = higher over best effort Internet, than telephony over quality managed = networks) and will *vastly increase cost* for ISPs to offer = WebRTC with good QoE.

 

Be= low you are giving pointers saying “They = are currently working on a problem-statement draft and a use-case draft, = any input to those would be very helpful.&#= 8221; Those are unnecessary, risking leading to (i), (ii) and (iii) = above.

 

So= are pointers such as: “RMCAT where = congestion avoidance for RTP is being developed&#= 8221;. TRAMs Milestone 3 is for the purpose of directing real-time = traffic where congestion control isn’t already in place. Using = RF= C 5285 available since 2008, to fill traffic information in RTP packets = (step D)) is probably a necessity for most future “congestion = control” discussed.

 

Th= is chicken-and-egg circular also applies to RTCWEB direction of QoS = issues to:

= http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos =

fo= cusing on DSCP-mapping without even mentioning RFC 5285 available since = 2008, to fill traffic information in RTP packets where it =A0is a = necessity and will allow:

(1= ) applications to directly convey QoS related real-time traffic info to = the network at points where RTP flow is directed to by TRAM Milstone 3, = to be used by *any network element implementing any suitable QoS = methods for the particular network* for

(2= ) *all* WebRTC browsers *and* dedicated clients (not using = WebRTC), under *all* OSs, and *all* current and future IP = networks

(3= ) *without* ha= ving to be forced into application specific networks (PSTN, IMS) instead = of using the Internet (including OTT).

 

Th= e only activity required, is to call for ISPs’ review whether the = traffic information transferred by RFC 5285 is sufficient for current = and future needs in their network as suggested in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip><= o:p>

…two = parameters (e.g. two bytes each) are encoded into the RTP header = extension:

 

A) The = maximum bandwidth requirement: Two bytes could contain everything from = some bps for real-time text to Gbps for future 3D supersize = telepresence… on a logarithmic scale.

 

B) The = quality characteristics for the stream, with the highest bit set to 1, = we could allocate a bit each for quality type = e.g:

Best Effort, = Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. = video streaming), Minimum Delay, Reliable Delivery, Prioritize X, = Variation Y, that could be combined as required to describe the = stream.

 

And with = highest bit set to 0, there could instead be a number for special usage = that does not fit the general description of the individual = bits.

</snip>=

 

Th= en this could be assigned numbers to have the RFC in = place.

Wi= th TRAM milestone 3 also place,

ma= rket forces will drive ISPs and browser makers to implement just that, = without even having it MUST-established.

&#= 8220;Who does not want a “WebRTC-Ready” Internet = access?” and

&#= 8220;Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?” and vice = versa.

 

Pl= ease see further emails soon following this one, for details and = history.

 

/K= arl

 

Fr=E5n: tram = [mailto:tram-bounces@ietf.org] F=F6r Pal Martinsen = (palmarti)
Skickat: den 21 februari 2014 10:37
Till: = tram@ietf.org
Kopia: Karl Stahl; Oleg Moskalenko; Alan = Johnston; Yoakum, John H (John)
=C4mne: Re: [tram] I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

Hi,

 

I = agree the full QoS discussion should _not_ happen in TRAM. If you are = interested in helping out in that area I suggest you looking into the = AEON mailing list at: https://www.ietf.org/= mailman/listinfo/aeon . They are currently working on a = problem-statement draft and a use-case draft, any input to those would = be very helpful. (http://= tools.ietf.org/html/draft-eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00).

 

That said, STUN have a few nice characteristics that = makes it a perfect candidate for transporting some of the QoS = information.  IMHO that would be extending the STUN spec and should = be within the TRAM charter.  The main goal = of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and = to start the discussion if TRAM is the appropriate place to have those = on the wire format discussions.

 

.-.

P=E5l-Erik

 

 

 

 

 

 

On = 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) <yoakum@avaya.com> = wrote:



+1

I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts.  There are other groups = doing QOS work and frankly I engage in WebRTC multimedia interactions = daily over the Internet, enterprise VPNs, and various combinations and = seldom suffer egregious quality issues.  I am more concerned about = carriers doing things to regulate or degrade WebRTC flows than a failure = of existing Internet mechanisms to enable them.

 

Significant focus on QOS before we better enable TURN to be easily = used in a browser environment taking advantage or normal web = characteristics (as opposed to historic telephony constructs) would seem = to be highly distracting at this point.

 

 

Ch= eers,

Jo= hn

&nb= sp;

AVAY= A
1.9= 19.425.8446

 

From:=  tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg = Moskalenko
Sent: Thursday, February 20, 2014 = 12:43 PM
To: Alan = Johnston
Cc: Karl Stahl; tram@ietf.org
Subject: Re: [tram] Fwd: I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

 

 

On Thu, Feb 20, 2014 at 6:26 AM, = Alan Johnston <alan.b.johnston@gmail.com> = wrote:

 

 

 

Personally, I am not sure how much = QoS is actually in scope for TRAM. Have you been following RMCAT where = congestion avoidance for RTP is being developed?  I see some = overlap in your goals and the goals of that = work.

-

 

 

I'd = concentrate on the TURN application-level functionality, for now, and = I'd leave QoS for the future = discussions.


__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/= mailman/listinfo/tram

 

------=_NextPart_000_04EF_01CF31B7.445B3D00-- From nobody Mon Feb 24 14:52: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 157791A0223; Mon, 24 Feb 2014 14:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 a_js_i8kzZ_5; Mon, 24 Feb 2014 14:52:15 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 732C51A01B7; Mon, 24 Feb 2014 14:52:14 -0800 (PST) Received: from [81.187.2.149] (port=34990 helo=[192.168.0.15]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WI4Na-0006F3-Us; Mon, 24 Feb 2014 22:52:10 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_88B6A6AA-91D0-4A95-AD5B-F4C66DD48D6D" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Colin Perkins In-Reply-To: <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> Date: Mon, 24 Feb 2014 22:52:04 +0000 Message-Id: <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> To: Karl Stahl X-Mailer: Apple Mail (2.1827) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/H__oVRdFdp5B8uAaADdOcLHlTww Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [rtcweb] [tram] Payload Types assignments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 22:52:20 -0000 --Apple-Mail=_88B6A6AA-91D0-4A95-AD5B-F4C66DD48D6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Karl, I strongly disagree with this suggestion. An RTP header extension, = located at an unknown and variable offset into a packet that does not = have a well-defined magic number in the header, indicated using a = dynamically assigned identifier that is conveyed in an out-of-band and = encrypted signalling channel, is not an appropriate place to put QoS = information that has to be processed on a per-packet basis. If you want = DiffServ, you know where to find it. Colin On 24 Feb 2014, at 22:09, Karl Stahl wrote: > I suggest to the RTCWEB WG that the below from the September and = October discussions on the relevant [rtcweb] [avtext] [mmusic] lists = http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is = introduced into draft-ietf-rtcweb-rtp-usage for usage of RFC 5285, to = allow: > =20 > (1) WebRTC applications to directly convey QoS related real-time = traffic info to the network at points where RTP flow is directed to by = TRAM Milstone 3, to be used by *any network element implementing any = suitable QoS methods for the particular network* for > (2) *all* WebRTC browsers *and* clients, under *all* OSs, and *all* = current and future IP network, to achieve best QoE > (3) *without* having to force WebRTC into application specific = networks (such as IMS) instead of using the Internet (including OTT). > =20 > The only further activity required, is to call for ISPs=92 to review = whether the traffic information transferred by RFC 5285 is sufficient = for current and future needs in their network as suggested in below = repeated = http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html > > =85two parameters (e.g. two bytes each) are encoded into the RTP = header extension: > =20 > A) The maximum bandwidth requirement: Two bytes could contain = everything from some bps for real-time text to Gbps for future 3D = supersize telepresence=85 on a logarithmic scale. > =20 > B) The quality characteristics for the stream, with the highest bit = set to 1, we could allocate a bit each for quality type e.g: > Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay = Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, = Prioritize X, Variation Y, that could be combined as required to = describe the stream. > =20 > And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the = individual bits. > > =20 > Then this could be assigned numbers to have an RFC in place. > =20 > With TRAM milestone 3 also place, > market forces will drive ISPs and browser makers to implement just = this, without even having it MUST-established. > =20 > =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and > =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. > =20 > Please see further emails soon following this one, for details and = history. > =20 > /Karl > =20 > =20 > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Karl Stahl > Skickat: den 22 oktober 2013 16:37 > Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus Westerlund' > Kopia: 'Colin Perkins' > =C4mne: [rtcweb] [avtext] Payload Types assignments was Re: SV: = [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 > =20 > Harald, I mostly agree with the quality requirements of different = real-time traffic that the WebRTC browser/application may use. But = rather than asking the application, let's convey the bandwidth and = priority requirements to the network. Just like with the Payload type = (that is hard to squeeze that information into) it must be visible to = the network (and not changed by the network, like diffserv bits are). = Such marking must also be available for incoming traffic, which is = especially important in RSVP type of networks, that has to reserve = bandwidth for it. =20 > =20 > There is actually a good way to show these needs to the network = (without using the PT, or diffserv bits, which aren=92t sufficient = anyway). > =20 > Let's use the RTP header extension field that also is visible outside = the encrypted payload. A week ago came = http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that = outlines the usage of the extension field for classification of traffic! = This document does not yet outline what to put in there and how to = encode it though. > =20 > Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 = discusses other webrtc usages of the RTP header extension in 5.2 (there = can be many header extensions according to RFC 5285) and in 9 there is = "WebRTC Use of RTP: Future Extensions". > =20 > So, it looks obvious to use the RTP header extension to show the = characteristics and bandwidth requirements to the network. It should not = introduce any backward incompatibilities either. > =20 > Such marking is done in every RTP packet so it can be set individually = for each stream and could even be changed during a session (e.g. when = limiting the bandwidth based on RTCP feedback). RFC 5286 also specifies = how RTP extension header usage can be negotiated in SDP. I think this = could be easily done by the WebRTC browser for "all current and future = needs" if properly specified now. > =20 > I suggest that two parameters (e.g. two bytes each) are encoded into = the RTP header extension: > =20 > A) The maximum bandwidth requirement: Two bytes could contain = everything from some bps for real-time text to Gbps for future 3D = supersize telepresence=85 on a logarithmic scale. > =20 > B) The quality characteristics for the stream, with the highest bit = set to 1, we could allocate a bit each quality e.g: > Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay = Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, = Prioritize X, Variation Y, that could be combined as required to = describe the stream. > =20 > And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the = individual bits. > =20 > Please note the totally different requirements a diffserv and an RSVP = network have to know, so let=92s put all into these bytes. (E.g. a = diffserv network don't need the bandwidth usage, but RSVP reservation = networks (e.g. cable and 3G/4G OTT) do. There one should initially = reserve the maximum bandwidth indicated, but can later re-reserve.) > =20 > /Karl > =20 > PS Microsoft seems to have done work in this field, defining a = proprietary attribute =93MS Service Quality=94; > However that seems to apply to the TURN server allocation request and = would therefore: > --- Apply to the whole UDP flow, and could not be set for each stream = individually (with different requirements), and > --- Does not handle the bandwidth requirement for incoming real-time = traffic (required to reserve in RSVP type of networks) > However the quality attributes conveyed and their encoding may be = considered. > =20 > This is 2.2.2.19 MS-Service Quality Attribute from > http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx=20= > =20 > MS-Service Quality Attribute > The MS-Service Quality attribute is used to convey information about = the data stream that the protocol client is intending to transfer over = an allocated port. The protocol client SHOULD<21> include this attribute = as part of an Allocate request message. A TURN server SHOULD use the = information in this attribute to make decisions about resource = allocation, bandwidth prioritization, and data delivery methods. If the = attribute is not present in the Allocate request message, the TURN = server SHOULD assume that the data stream is audio with best effort = delivery. The format of this attribute is as follows... > ... > The following stream types are supported in this extension. All other = stream types are reserved for future use. > =A7 "0x0001": Audio > =A7 "0x0002": Video > =A7 "0x0003": Supplemental Video > =A7 "0x0004": Data > Service Quality (2 bytes): The service quality level required by the = protocol client for the stream. > The following service quality levels are supported in this extension. = All other service quality levels are reserved for future use. > =A7 "0x0000": Best effort delivery. > =A7 "0x0001": Reliable delivery. > =20 > =20 > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Harald Alvestrand > Skickat: den 8 oktober 2013 13:01 > Till: rtcweb@ietf.org > =C4mne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] = WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 > =20 > On 10/08/2013 09:17 AM, Karl Stahl wrote: > > Hej Magnus, > >=20 > >> Also, are you really interested in knowing that it is VP9 vs H.264, > >> isn't > > the questions this is video of this priority that is important? > >> I think you need to more carefully consider what are the goals you > >> try to > > achieve them. > >=20 > > Actually, my concern is to get an idea of the maximum bandwidth that > > could be required for a WebRTC (ICE) setup media flow. Both voice = and > > video should be prioritized over data (their individual priority is = of > > less importance as long as there is sufficient bandwidth for both). > =20 > You don't know that without knowing what the application is for. > In, for instance, a shooter game with voice backchannels, the movement = and event information (data) is MORE time sensitive than the voice data. > =20 > >=20 > > With diffserv you don=92t need to know the bandwidth requirement, = but > > with RSVP reservation (like in cable and mobile networks) you need = to > > know how much to reserve. Voice is like 100's kbit/s, video VP8 or > > H.264 is like 3,5 mbps. > =20 > Again, without knowing the application, you don't know that. > The application could decide to use QCIF or HD, and the bandwidth = variation of screencast (semi-static with sudden, large changes) is = completely different from that of a talking head, which is again = completely different from a high-movement scene. > =20 > >=20 > > To add to the complication of codec variants, the video codecs in > > question for WebRTC have variable bandwidth, and when there is a = poor > > connection we see Chrome reducing the video window size to reduce = the bandwidth used... > >=20 > > I think the payload type field at best can reflect a maximum = bandwidth > > to initially reserve bandwidth for, and thereafter make new > > reservations if the bandwidth changes during the call. So could we > > change RTP to show maximum bandwidth instead of payload type in that > > field outside the encrypted payload :) ... Or maybe that is not a = joke? > =20 > I think these ruminations only lead to one conclusion: > =20 > You can't tell what the needed bandwidth is up front without asking = the application. > You can't tell what the right priority ranking is without asking the = application. > =20 > If you need to know the bandwidth or the priority up front, the = application has to tell you. Anything else is pure heuristics. > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_88B6A6AA-91D0-4A95-AD5B-F4C66DD48D6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Karl,

I strongly disagree with = this suggestion. An RTP header extension, located at an unknown and = variable offset into a packet that does not have a well-defined magic = number in the header, indicated using a dynamically assigned identifier = that is conveyed in an out-of-band and encrypted signalling channel, is = not an appropriate place to put QoS information that has to be processed = on a per-packet basis. If you want DiffServ, you know where to find = it.

Colin


= On 24 Feb 2014, at 22:09, Karl Stahl <karl.stahl@intertex.se> = wrote:

I suggest to the RTCWEB WG that the below from the = September and October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = is introduced into draft-ietf-rtcweb-rtp-usage= for usage of RFC 5285, to = allow:

 

(1) WebRTC applications to directly convey QoS related = real-time traffic info to the network at points where RTP flow is = directed to by TRAM Milstone 3, to be used by *any network element = implementing any suitable QoS methods for the particular network* = for

(2) *all* WebRTC browsers *and* clients, = under *all* OSs, and *all* current and future IP network, = to achieve best QoE

(3) *without* having to force WebRTC into application specific = networks (such as IMS) instead of using the Internet (including = OTT).

 

The only further activity required, is to call for = ISPs=92 to review whether the traffic information transferred by RFC = 5285 is sufficient for current and future needs in their network as = suggested in below repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip>

=85two parameters (e.g. two bytes each) are encoded into the RTP = header extension:

 

A) The maximum bandwidth requirement: Two bytes could contain = everything from some bps for real-time text to Gbps for future 3D = supersize telepresence=85 on a logarithmic = scale.

 

B) The quality characteristics for the stream, with the highest = bit set to 1, we could allocate a bit each for quality type = e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay = Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, = Prioritize X, Variation Y, that could be combined as required to = describe the stream.

 

And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the = individual bits.

</snip>

 

Then this could be assigned numbers to have an RFC in = place.

 

With TRAM milestone 3 also place, =

market forces will drive ISPs and browser makers to = implement just this, without even having it = MUST-established.

 

=93Who does not want a =93WebRTC-Ready=94 Internet = access?=94 and

=93Who wants to use Chrome, if Firefox, Internet = Explorer or Safari comes with much better QoE?=94 and vice = versa.

 

Please see further emails soon following this one, for = details and history.

 

/Karl

 

 

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org= ] F=F6r Karl Stahl
Skickat: den 22 oktober 2013 = 16:37
Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus = Westerlund'
Kopia: 'Colin Perkins'
=C4mne: [rtcweb] = [avtext] Payload Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

Harald, I mostly agree with = the quality requirements of different real-time traffic that the WebRTC = browser/application may use. But rather than asking the application, = let's convey the bandwidth and priority requirements to the network. = Just like with the Payload type (that is hard to squeeze that = information into) it must be visible to the network (and not changed by = the network, like diffserv bits are). Such marking must also be = available for incoming traffic, which is especially important in RSVP = type of networks, that has to reserve bandwidth for it. =  

 

There is actually a good way to show these needs to the = network (without using the PT, or diffserv bits, which aren=92t = sufficient anyway).

 

Let's use the RTP header extension field that also is = visible outside the encrypted payload. A week ago came ht= tp://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 =  that outlines the usage of the extension field for classification = of traffic! This document does not yet outline what to put in there and = how to encode it though.

 

Today's http://= tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 discusses other = webrtc usages of the RTP header extension in 5.2 (there can be many = header extensions according to RFC 5285) and in 9 there is "WebRTC Use = of RTP: Future Extensions".

 

So, it looks obvious to use = the RTP header extension to show the characteristics and bandwidth = requirements to the network. It should not introduce any backward = incompatibilities either.

 

Such marking is done in = every RTP packet so it can be set individually for each stream and could = even be changed during a session (e.g. when limiting the bandwidth based = on RTCP feedback). RFC 5286 also specifies how RTP extension header = usage can be negotiated in SDP. I think this could be easily done by the = WebRTC browser for "all current and future needs" if properly specified = now.

 

I suggest that two parameters (e.g. two bytes each) are = encoded into the RTP header extension:

 

A) The maximum bandwidth = requirement: Two bytes could contain everything from some bps for = real-time text to Gbps for future 3D supersize telepresence=85 on a = logarithmic scale.

 

B) The quality characteristics for the stream, with the = highest bit set to 1, we could allocate a bit each quality = e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, = Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable = Delivery, Prioritize X, Variation Y, that could be combined as required = to describe the stream.

 

And with highest bit set to = 0, there could instead be a number for special usage that does not fit = the general description of the individual bits.

 

Please note the totally = different requirements a diffserv and an RSVP network have to know, so = let=92s put all into these bytes. (E.g. a diffserv network don't need = the bandwidth usage, but RSVP reservation networks (e.g. cable and 3G/4G = OTT) do. There one should initially reserve the maximum bandwidth = indicated, but can later re-reserve.)

 

/Karl

 

PS Microsoft seems to have = done work in this field, defining a proprietary attribute =93MS Service = Quality=94;

However that = seems to apply to the TURN server allocation request and would = therefore:

--- Apply to = the whole UDP flow, and could not be set for each stream individually = (with different requirements), and

--- Does not handle the bandwidth requirement for = incoming real-time traffic (required to reserve in RSVP type of = networks)

However the = quality attributes conveyed and their encoding may  be = considered.

 

This is 2.2.2.19 MS-Service Quality Attribute from =

http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx<= /a> 

 

MS-Service = Quality Attribute

The = MS-Service Quality attribute is used to convey information about the = data stream that the protocol client is intending to transfer over an = allocated port. The protocol client SHOULD<21> include this = attribute as part of an Allocate request message. A TURN server SHOULD = use the information in this attribute to make = decisions about resource allocation, bandwidth prioritization, and data = delivery methods. If the attribute is not present in the Allocate = request message, the TURN server SHOULD assume that the data stream is = audio with best effort delivery. The format of this attribute is as = follows...

...

The following = stream types are supported in this extension. All other stream types are = reserved for future use.

=A7 "0x0001": = Audio

=A7 = "0x0002": Video

=A7 "0x0003": Supplemental = Video

=A7 = "0x0004": Data

Service = Quality (2 bytes): The service quality level required by the protocol = client for the stream.

The following = service quality levels are supported in this extension. All other = service quality levels are reserved for future use.

=A7 = "0x0000": Best effort delivery.

=A7 = "0x0001": Reliable delivery.

 

 

-----Ursprungligt = meddelande-----

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org= ] F=F6r Harald Alvestrand

Skickat:= den 8 oktober 2013 13:01

Till: = rtcweb@ietf.org

=C4mne: Re: [rtcweb] Payload = Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

On 10/08/2013 09:17 AM, Karl = Stahl wrote:

> Hej Magnus,

> 

>> Also, are you = really interested in knowing that it is VP9 vs H.264, =

>> isn't

> the questions this is = video of this priority that is important?

>> I think you need to = more carefully consider what are the goals you

>> try = to

> achieve them.

> 

> Actually, my concern is = to get an idea of the maximum bandwidth that

> could be required for a = WebRTC (ICE) setup media flow. Both voice and

> video should be = prioritized over data (their individual priority is of =

> = less importance as long as there is sufficient bandwidth for = both).

 

You don't know that without knowing what the application = is for.

In, for instance, a shooter game with voice backchannels, = the movement and event information (data) is MORE time sensitive than = the voice data.

 

> 

> With diffserv you don=92t= need to know the bandwidth requirement, but

> with RSVP reservation = (like in cable and mobile networks) you need to

> know how much to = reserve. Voice is like 100's kbit/s, video VP8 or =

> = H.264 is like 3,5 mbps.

 

Again, without knowing the = application, you don't know that.

The application could decide = to use QCIF or HD, and the bandwidth variation of screencast = (semi-static with sudden, large changes) is completely different from = that of a talking head, which is again completely different from a = high-movement scene.

 

> 

> To add to the = complication of codec variants, the video codecs in =

> = question for WebRTC have variable bandwidth, and when there is a poor =

> = connection we see Chrome reducing the video window size to reduce the = bandwidth used...

> 

> I think the payload = type field at best can reflect a maximum bandwidth =

> = to initially reserve bandwidth for, and thereafter make new =

> = reservations if the bandwidth changes during the call. So could we =

> = change RTP to show maximum bandwidth instead of payload type in that =

> = field outside the encrypted payload :) ... Or maybe that is not a = joke?

 

I think these ruminations only lead to one = conclusion:

 

You can't tell what the needed bandwidth is up front = without asking the application.

You can't tell what the = right priority ranking is without asking the = application.

 

If you need to know the bandwidth or the priority up = front, the application has to tell you. Anything else is pure = heuristics.

 

_______________________________________________<= /span>

rtcweb mailing = list

rtcweb@ietf.org

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




-- 
Colin Perkins



= --Apple-Mail=_88B6A6AA-91D0-4A95-AD5B-F4C66DD48D6D-- From nobody Mon Feb 24 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 A6FFA1A030A; Mon, 24 Feb 2014 15:03:12 -0800 (PST) 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_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 rp0hYZAXodU5; Mon, 24 Feb 2014 15:03:04 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 602201A01CB; Mon, 24 Feb 2014 15:03:03 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402250002595903; Tue, 25 Feb 2014 00:02:59 +0100 From: "Karl Stahl" To: "'Cullen Jennings \(fluffy\)'" , "'Magnus Westerlund'" , "'Simon Perreault'" , "'Ted Hardie'" , "'Gonzalo Camarillo'" , , References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> In-Reply-To: Date: Tue, 25 Feb 2014 00:02:57 +0100 Message-ID: <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0500_01CF31BC.F07B9F80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPLuh9NKjjBBbIvkuPAKYD51v6LZq/zpPA Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4OE4PaC-4DjtzOZdWN1w7eDoNL4 Cc: 'Spencer Dawkins' Subject: [rtcweb] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Feb 2014 23:03:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0500_01CF31BC.F07B9F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To the TRAM WG and RTCWEB WG and ADs: =20 It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed = and encouraged to route quality demanding WebRTC media into their IP pipes = that are capable of transporting real-time traffic without quality issues, = using TURN servers.=20 =20 The subject from the TRAM mailing initiation spells out: *Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs* The TRAM WG must assure that TURN servers offered by ISPs/NSPs can be = used for the above purpose. (The objective of the TRAM WG milestone 3 is *not only* to resolve restrictive enterprise NAT/firewall traversal problem using TURN = servers.) I request that this is explicitly clarified in the TRAM charter. =20 The QoS discussions that has appeared in this TRAM WG, resulting from=20 draft-martinsen-tram-discuss-00.txt and=20 draft-thomson-tram-turn-bandwidth-00.txt=20 has been confusing (to say the least), risking that the general QoS = attitude within IETF work =93it is all about bandwidth=94 and =93it will go away = with time=94:=20 (i) will *not allow* ISP=92s to use already available and currently = deployable quality IP pipes for real-time traffic to also be used for WebRTC = generated real-time traffic. (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. That all networks *will be inhibited* from the = very common and used method of simply providing an extra IP pipe (often = provided over the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) *while* newer, fiber only type of networks, still can borrow bandwidth = at no extra cost, *by proprietary usage* of RFC 5285 by browsers.=20 (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may have to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes = intermittently are filled, whatever bandwidth is available). =20 Further explanations about QoS methods and their implementation were = given a few days ago in:=20 http://www.ietf.org/mail-archive/web/tram/current/msg00274.html=20 =20 (i), (ii) and (iii) risk *seriously delaying* usage of telepresence = capable and quality demanding WebRTC (bandwidth being around 30 times higher = over best effort Internet, than telephony over quality managed networks) and = will *vastly increase cost* for ISPs to offer WebRTC with good QoE. =20 I am therefore advising that draft-martinsen-tram-discuss-00.txt and draft-thomson-tram-turn-bandwidth-00.txt=20 are withdrawn from TRAM. draft-martinsen-tram-discuss-00.txt can be reintroduced after clarification in the draft, that it is not about QoS = as clarified by http://www.ietf.org/mail-archive/web/tram/current/msg00276.html. =20 There are further details about this in the email http://www.ietf.org/mail-archive/web/tram/current/msg00303.html also = copied below. =20 It is therein explained that my repeated suggestion to RTCWEB WG http://www.ietf.org/mail-archive/web/rtcweb/current/msg11542.html from = the October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html to introduce the QoS related usage of RFC 5285 into = draft-ietf-rtcweb-rtp-usage in combinations with the Milestone 3 objectives of TRAM, immediately = would allow: (1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP = variants) to quickly allow us to finally enjoy the high quality and connectivity (NAT/firewall traversal) of real-time communication services now = possible, for =20 (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), = under *all* OSs, and *all* current and future IP networks=20 (3) *without* having to be forced into application specific networks = (PSTN, IMS) instead of the Internet (including OTT). =20 The only activity required, is to call for ISPs=92 review whether the = traffic information transferred by RFC 5285 is sufficient for the needs of their networks. =20 WebRTC *can be* used for existing application specific IP networks (such = as IMS) for services existing on these networks, but with the introduction = of the TRAM objectives above and the proposed traffic information in every = RTP packet http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = as made possible by RFC 5285 available since 2008:=20 (a) the same as well as other real-time services using IETF RTP traffic, *can also (often much better) be* implemented over the Internet = (including OTT) (b) also considering needs of QoS, media routing, control, quality measurements, SLA implementation, usage, accounting, billing and = SP-peering, that so far has been attributed application specific networks, but in practice and in reality have shown difficulties to implement (e.g. = SP=92s peering of beyond POTS services, resulting in that the 50 year old, = pre-AM radio quality telephony service, still is the only truly global communication service (and today often is used to initiate other better proprietary communication services). =20 Application specific networks such as the IMS network have their own = methods of handling QoS, that not in anyway will be made less efficient by the methods proposed here. Application specific networks *can use and will = also benefit* from the flow control and traffic requirement marking of RTP streams proposed here. =20 WebRTC *will be* used over the Internet (including OTT) and *will = probably also be* used over the application specific IMS network for the services existing there through a gateway function from the Internet.=20 =20 With RFC 5285 QoS usage and with TRAM milestone 3 in place (which I = suggest the WGs to expedite),=20 market forces will drive ISPs and browser makers to implement just that, without even having it MUST-established. =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. =20 The TRAM WG and RTCWEB WG chairs and ADs are advised to review whether = IETF standard work in these WGs by contributors having an interest in more = than one of current or emerging: ISPs, carrier equipment vendors or web = browser makers, may discriminate any with an interest only in one of these. The = same should apply to non-activity by WG contributors to remedy such discrimination opened by allowed proprietary usage of RFCs such as RFC = 5285. =20 One input for such review are responses directed to me in the September = =96 October discussion on the RTCWEB list and on the TRAM list from my entry there February 8 http://www.ietf.org/mail-archive/web/tram/current/msg00132.html. =20 Please see just sent emails: http://www.ietf.org/mail-archive/web/rtcweb/current/msg11542.html=20 http://www.ietf.org/mail-archive/web/tram/current/msg00303.html=20 and further emails soon following this one, for details and history. =20 /Karl =20 =20 Charter charter-ietf-tram-01 https://datatracker.ietf.org/doc/charter-ietf-tram/=20 =20 =20 Fr=E5n: Karl Stahl [mailto:karl.stahl@intertex.se]=20 Skickat: den 24 februari 2014 23:22 Till: 'Pal Martinsen (palmarti)'; 'tram@ietf.org'; 'rtcweb@ietf.org' Kopia: 'Oleg Moskalenko'; 'Alan Johnston'; 'Yoakum, John H (John)' =C4mne: SV: [tram] [rtcweb] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 Hi P=E5l, =20 You did not comment nor answer, in response to any of: http://www.ietf.org/mail-archive/web/tram/current/msg00275.html=20 http://www.ietf.org/mail-archive/web/tram/current/msg00273.html=20 whether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the application/browser to transfer relevant real-time traffic information (types and bandwidth) into every RTP package by using the already IETF standardized RTP extension header RCF 5285, which could be used by any current or future Internet (including OTT) network where WebRTC = real-time traffic may flow. It seems to have been standardized already 2008 to = allow such usage. =20 QoS related step C) draft-martinsen-tram-discuss can then be taken out = of TRAM, and step D) (that was never intended to be handled by TRAM anyway) will be handled elsewhere. =20 I have repeated my suggestion to RTCWEB WG from the October discussions = on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html to introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage suggesting usage of RFC 5285, where traffic information in RTP packets simply would be filled by any browser under any OS. =20 Without step B), TRAM =93Enforcing the real-time traffic through the offered/discovered TURN servers=94, the real-time traffic may happen = through the IP default gateways often congested by data traffic and QoS = insensitive streaming video and file sharing. Without specific QoS methods at those points, the network raw bandwidth capacity may have to be 10-folded to achieve sufficient QoE when WebRTC usage becomes popular. Methods like DISCUSS addresses such things occurring when STUN instead TURN is used = (by allowing flows into such congestion points), but only provides direct traffic info for outgoing (not incoming) real-time traffic and locally, therefore are not even applicable to reservation type of networks like = Cable Networks and Mobile OTT.=20 =20 That would leave certain network types to investing in raw bandwidth increase, instead of simply borrowing the bandwidth (from much larger = data traffic and QoS insensitive streaming video and file sharing at no = adverse effect) and making that borrowed no-cost bandwidth very valuable for the carriers when delivering to their customers. =20 I know a few of you Cisco guys are among the ones that have been = fighting against the general =93it is all about bandwidth=94 and =93it will go = away with time=94-attitude within IETF work, e.g. see http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html, but = the pointers given in the current QoS discussion within TRAM:=20 =20 (i) will *not allow* ISP=92s to use already available and currently = deployable quality IP pipes for real-time traffic to also be used for WebRTC = generated real-time traffic. =20 (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. All networks will *also be inhibited* from the = very common and used method of simply providing an extra IP pipe (often = provided over the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) Newer, fiber only type of networks, can still borrow bandwidth at no = extra cost, *by proprietary usage* of RFC 5285 by browsers.=20 =20 (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may has to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes = intermittently are filled, whatever bandwidth is available). =20 Further explanations about QoS methods and their implementation were = given a few days ago in:=20 http://www.ietf.org/mail-archive/web/tram/current/msg00274.html=20 =20 (i), (ii) and (iii) will *seriously delay* usage of telepresence capable = and quality demanding WebRTC (bandwidth being around 30 times higher over = best effort Internet, than telephony over quality managed networks) and will *vastly increase cost* for ISPs to offer WebRTC with good QoE. =20 Below you are giving pointers saying =93They are currently working on a problem-statement draft and a use-case draft, any input to those would = be very helpful.=94 Those are unnecessary, risking leading to (i), (ii) and = (iii) above. =20 So are pointers such as: =93RMCAT where congestion avoidance for RTP is = being developed=94. TRAMs Milestone 3 is for the purpose of directing = real-time traffic where congestion control isn=92t already in place. Using RFC = 5285 available since 2008, to fill traffic information in RTP packets (step = D)) is probably a necessity for most future =93congestion control=94 = discussed. =20 This chicken-and-egg circular also applies to RTCWEB direction of QoS = issues to:=20 http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos=20 focusing on DSCP-mapping without even mentioning RFC 5285 available = since 2008, to fill traffic information in RTP packets where it is a = necessity and will allow:=20 (1) applications to directly convey QoS related real-time traffic info = to the network at points where RTP flow is directed to by TRAM Milstone 3, = to be used by *any network element implementing any suitable QoS methods = for the particular network* for=20 (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), = under *all* OSs, and *all* current and future IP networks=20 (3) *without* having to be forced into application specific networks = (PSTN, IMS) instead of using the Internet (including OTT). =20 The only activity required, is to call for ISPs=92 review whether the = traffic information transferred by RFC 5285 is sufficient for current and future needs in their network as suggested in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =85two parameters (e.g. two bytes each) are encoded into the RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each for quality type e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Then this could be assigned numbers to have the RFC in place. With TRAM milestone 3 also place,=20 market forces will drive ISPs and browser makers to implement just that, without even having it MUST-established. =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. =20 Please see further emails soon following this one, for details and = history. =20 /Karl =20 Fr=E5n: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]=20 Skickat: den 21 februari 2014 10:37 Till: tram@ietf.org Kopia: Oleg Moskalenko; Alan Johnston; Karl Stahl; Yoakum, John H (John) =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 Hi, =20 I agree the full QoS discussion should _not_ happen in TRAM. If you are interested in helping out in that area I suggest you looking into the = AEON mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are currently working on a problem-statement draft and a use-case draft, any input to those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). =20 That said, STUN have a few nice characteristics that makes it a perfect candidate for transporting some of the QoS information. IMHO that would = be extending the STUN spec and should be within the TRAM charter. The main goal of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and to start the discussion if TRAM is the appropriate place to have those on = the wire format discussions. =20 .-. P=E5l-Erik =20 =20 On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) < yoakum@avaya.com> wrote: +1 I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts. There are other groups doing QOS = work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterprise VPNs, and various combinations and seldom suffer egregious quality issues. I am more concerned about carriers doing = things to regulate or degrade WebRTC flows than a failure of existing Internet mechanisms to enable them. =20 Significant focus on QOS before we better enable TURN to be easily used = in a browser environment taking advantage or normal web characteristics (as opposed to historic telephony constructs) would seem to be highly distracting at this point. =20 =20 Cheers, John =20 AVAYA 1.919.425.8446 =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 12:43 PM To: Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 =20 =20 On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston < alan.b.johnston@gmail.com> wrote: =20 =20 =20 Personally, I am not sure how much QoS is actually in scope for TRAM. = Have you been following RMCAT where congestion avoidance for RTP is being developed? I see some overlap in your goals and the goals of that work. - =20 =20 I'd concentrate on the TURN application-level functionality, for now, = and I'd leave QoS for the future discussions. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 ------=_NextPart_000_0500_01CF31BC.F07B9F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

To= the TRAM WG and RTCWEB WG and ADs:

 

It= must be a clear objective of the TRAM WG that ISPs/NSPs are allowed and = encouraged to route quality demanding WebRTC media into their IP pipes = that are capable of transporting real-time traffic without quality = issues, using TURN servers.

 

Th= e subject from the TRAM mailing initiation spells = out:

*<= b>Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs*

Th= e TRAM WG must assure that TURN servers offered by ISPs/NSPs can be used = for the above purpose.

(T= he objective of the TRAM WG milestone 3 is *not only* to resolve = restrictive enterprise NAT/firewall traversal problem using TURN = servers.)

=

I = request that this is explicitly clarified in the TRAM = charter.

 

Th= e QoS discussions that has appeared in this TRAM WG, resulting from =

draft-martinsen-tram-discuss-00.txt

an= d

draft-thomson-tram-turn-bandwidth-00.txt =

ha= s been confusing (to say the least), risking that the = general QoS attitude within IETF work “it is all about = bandwidth” and “it will go away with time”: =

(i= ) will *not allow* ISP’s to use already available and = currently deployable quality IP pipes for real-time traffic to also be = used for WebRTC generated real-time traffic.

(i= i) will *not allow* some network types (e.g. Cable Networks and = Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive = streaming video and file sharing. That all networks *will be = inhibited* from the very common and used method of simply providing = an extra IP pipe (often provided over the same wire but level-2 = separated) dedicated for real-time usage

(<= b>*by resisting TRAM implementation of step = B*)

*<= b>while* newer, fiber only type of networks, still can borrow = bandwidth at no extra cost, *by proprietary usage* of RFC 5285 by = browsers.

(i= ii) will leave most ISPs to *only use* raw bandwidth capacity = increase that may have to be 10-folded to reach sufficient QoE when = WebRTC usage becomes popular (if at all possible, since unmanaged IP = pipes intermittently are filled, whatever bandwidth is = available).

 

Fu= rther explanations about QoS methods and their implementation were given = a few days ago in:

= http://www.ietf.org/mail-archive/web/tram/current/msg00274.html =

 

(i= ), (ii) and (iii) risk *seriously delaying* usage of telepresence = capable and quality demanding WebRTC (bandwidth being around 30 times = higher over best effort Internet, than telephony over quality managed = networks) and will *vastly increase cost* for ISPs to offer = WebRTC with good QoE.

 

I = am therefore advising that draft-martinsen-tram-discuss-00.txt an= d draft-thomson-tram-turn-bandwidth-00.txt =

ar= e withdrawn from TRAM. draft-martinsen-tram-discuss-00.txt ca= n be reintroduced after clarification in the draft, that it is not about = QoS as clarified by = http://www.ietf.org/mail-archive/web/tram/current/msg00276.html.=

 

Th= ere are further details about this in the email = http://www.ietf.org/mail-archive/web/tram/current/msg00303.html also = copied below.

 

It= is therein explained that my repeated suggestion to RTCWEB WG http://www.ietf.org/mail-archive/web/rtcweb/current/msg11542.html = from the October discussions on the relevant [rtcweb] [avtext] [mmusic] = lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = to introduce the QoS related usage of RFC 5285 into draft-ietf-rtcweb-rtp-usage in= combinations with the Milestone 3 objectives of TRAM, immediately would = allow:

(1= ) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE = (in addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP = variants) to quickly allow us to finally enjoy the high quality and = connectivity (NAT/firewall traversal) of real-time communication = services now possible, for =A0

(2= ) *all* WebRTC browsers *and* dedicated clients (not using = WebRTC), under *all* OSs, and *all* current and future IP = networks

(3= ) *without* ha= ving to be forced into application specific networks (PSTN, IMS) instead = of the Internet (including OTT).

 

Th= e only activity required, is to call for ISPs’ review whether the = traffic information transferred by RFC 5285 is sufficient for the needs = of their networks.

 

We= bRTC *can be* used for existing application specific IP networks = (such as IMS) for services existing on these networks, but with the = introduction of the TRAM objectives above and the proposed traffic = information in every RTP packet http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = as made possible by RFC 5285 available since 2008: =

(a= ) the same as well as other real-time services using IETF RTP traffic, = *can also (often much better) be* implemented over the Internet = (including OTT)

(b= ) also considering needs of QoS, media routing, control, quality = measurements, SLA implementation, usage, accounting, billing and = SP-peering, =A0=A0

th= at so far has been attributed application specific networks, but in = practice and in reality have shown difficulties to implement (e.g. = SP’s peering of beyond POTS services, resulting in that the 50 = year old, pre-AM radio quality telephony service, still is the only = truly global communication service (and today often is used to initiate = other better proprietary communication = services).

 

Ap= plication specific networks such as the IMS network have their own = methods of handling QoS, that not in anyway will be made less efficient = by the methods proposed here. Application specific networks *can use = and will also benefit* from the flow control and traffic requirement = marking of RTP streams proposed here.

 

We= bRTC *will be* used over the Internet (including OTT) and = *will probably also be* used over the application specific IMS = network for the services existing there through a gateway function from = the Internet.

 

Wi= th RFC 5285 QoS usage and with TRAM milestone 3 in place (which I = suggest the WGs to expedite),

ma= rket forces will drive ISPs and browser makers to implement just that, = without even having it MUST-established.

&#= 8220;Who does not want a “WebRTC-Ready” Internet = access?” and

&#= 8220;Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?” and vice = versa.

 

Th= e TRAM WG and RTCWEB WG chairs and ADs are advised to review whether = IETF standard work in these WGs by contributors having an interest in = more than one of current or emerging: ISPs, carrier equipment vendors or = web browser makers, may discriminate any with an interest only in one of = these. The same should apply to non-activity by WG contributors to = remedy such discrimination opened by allowed proprietary usage of RFCs = such as RFC 5285.

 

On= e input for such review are responses directed to me in the September = – October discussion on the RTCWEB list and on the TRAM list from = my entry there February 8 = http://www.ietf.org/mail-archive/web/tram/current/msg00132.html.=

 

Pl= ease see just sent emails:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg11542.html =

= http://www.ietf.org/mail-archive/web/tram/current/msg00303.html =

an= d further emails soon following this one, for details and = history.

 

/K= arl =A0

 

Charter = charter-ietf-tram-01 https://datatracker.ietf.org/doc/charter-ietf-tram/

 

 

Fr=E5n: Karl Stahl = [mailto:karl.stahl@intertex.se]
Skickat: den 24 februari 2014 = 23:22
Till: 'Pal Martinsen (palmarti)'; 'tram@ietf.org'; = 'rtcweb@ietf.org'
Kopia: 'Oleg Moskalenko'; 'Alan Johnston'; = 'Yoakum, John H (John)'
=C4mne: SV: [tram] [rtcweb] I-D = Action: draft-thomson-tram-turn-bandwidth-00.txt

 

Hi= P=E5l,

 

Yo= u did not comment nor answer, in response to any = of:

= http://www.ietf.org/mail-archive/web/tram/current/msg00275.html =

= http://www.ietf.org/mail-archive/web/tram/current/msg00273.html =

wh= ether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the = application/browser to transfer relevant real-time traffic information = (types and bandwidth) into every RTP package by using the already IETF = standardized RTP extension header RCF 5285, which could be used by any = current or future Internet (including OTT) network where WebRTC = real-time traffic may flow. It seems to have been standardized already = 2008 to allow such usage.

 

Qo= S related step C) draft-martinsen-tram-discuss = ca= n then be taken out of TRAM, and step D) (that was never intended to be = handled by TRAM anyway) will be handled = elsewhere.

 

I = have repeated my suggestion to RTCWEB WG from the October discussions on = the relevant [rtcweb] [avtext] = [mmusic] = lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = to introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage sug= gesting usage of RFC 5285, where traffic information in RTP packets = simply would be filled by any browser under any OS.

 

Wi= thout step B), TRAM “Enforcing the real-time traffic through the = offered/discovered TURN servers”, the real-time traffic may happen = through the IP default gateways often congested by data traffic and QoS = insensitive streaming video and file sharing. Without specific QoS = methods at those points, the network raw bandwidth capacity may have to = be 10-folded to achieve sufficient QoE when WebRTC usage becomes = popular. Methods like DISCUSS addresses such things occurring when STUN = instead TURN is used (by allowing flows into such congestion points), = but only provides direct traffic info for outgoing (not incoming) = real-time traffic and locally, therefore are not even applicable to = reservation type of networks like Cable Networks and Mobile OTT. =

 

Th= at would leave certain network types to investing in raw bandwidth = increase, instead of simply borrowing the bandwidth (from much larger = data traffic and QoS insensitive streaming video and file sharing at no = adverse effect) and making that borrowed no-cost bandwidth very valuable = for the carriers when delivering to their = customers.

 

I = know a few of you Cisco guys are among the ones that have been fighting = against the general “it is all about bandwidth” and = “it will go away with time”-attitude within IETF work, e.g. = see http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html, = but the pointers given in the current QoS discussion within TRAM: =

 

(i= ) will *not allow* ISP’s to use already available and = currently deployable quality IP pipes for real-time traffic to also be = used for WebRTC generated real-time traffic.

 

(i= i) will *not allow* some network types (e.g. Cable Networks and = Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive = streaming video and file sharing. All networks will *also be = inhibited* from the very common and used method of simply providing = an extra IP pipe (often provided over the same wire but level-2 = separated) dedicated for real-time usage

(<= b>*by resisting TRAM implementation of step = B*)

Ne= wer, fiber only type of networks, can still borrow bandwidth at no extra = cost, *by proprietary usage* of RFC 5285 by browsers. =

 

(i= ii) will leave most ISPs to *only use* raw bandwidth capacity = increase that may has to be 10-folded to reach sufficient QoE when = WebRTC usage becomes popular (if at all possible, since unmanaged IP = pipes intermittently are filled, whatever bandwidth is = available).

 

Fu= rther explanations about QoS methods and their implementation were given = a few days ago in:

= http://www.ietf.org/mail-archive/web/tram/current/msg00274.html =

 

(i= ), (ii) and (iii) will *seriously delay* usage of telepresence = capable and quality demanding WebRTC (bandwidth being around 30 times = higher over best effort Internet, than telephony over quality managed = networks) and will *vastly increase cost* for ISPs to offer = WebRTC with good QoE.

 

Be= low you are giving pointers saying “They = are currently working on a problem-statement draft and a use-case draft, = any input to those would be very helpful.&#= 8221; Those are unnecessary, risking leading to (i), (ii) and (iii) = above.

 

So= are pointers such as: “RMCAT where = congestion avoidance for RTP is being developed&#= 8221;. TRAMs Milestone 3 is for the purpose of directing real-time = traffic where congestion control isn’t already in place. Using RFC = 5285 available since 2008, to fill traffic information in RTP packets = (step D)) is probably a necessity for most future “congestion = control” discussed.

 

Th= is chicken-and-egg circular also applies to RTCWEB direction of QoS = issues to:

= http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos =

fo= cusing on DSCP-mapping without even mentioning RFC 5285 available since = 2008, to fill traffic information in RTP packets where it  is a = necessity and will allow:

(1= ) applications to directly convey QoS related real-time traffic info to = the network at points where RTP flow is directed to by TRAM Milstone 3, = to be used by *any network element implementing any suitable QoS = methods for the particular network* for

(2= ) *all* WebRTC browsers *and* dedicated clients (not using = WebRTC), under *all* OSs, and *all* current and future IP = networks

(3= ) *without* ha= ving to be forced into application specific networks (PSTN, IMS) instead = of using the Internet (including OTT).

 

Th= e only activity required, is to call for ISPs’ review whether the = traffic information transferred by RFC 5285 is sufficient for current = and future needs in their network as suggested in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip><= o:p>

…two = parameters (e.g. two bytes each) are encoded into the RTP header = extension:

 

A) The = maximum bandwidth requirement: Two bytes could contain everything from = some bps for real-time text to Gbps for future 3D supersize = telepresence… on a logarithmic scale.

 

B) The = quality characteristics for the stream, with the highest bit set to 1, = we could allocate a bit each for quality type = e.g:

Best Effort, = Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. = video streaming), Minimum Delay, Reliable Delivery, Prioritize X, = Variation Y, that could be combined as required to describe the = stream.

 

And with = highest bit set to 0, there could instead be a number for special usage = that does not fit the general description of the individual = bits.

</snip>=

 

Th= en this could be assigned numbers to have the RFC in = place.

Wi= th TRAM milestone 3 also place,

ma= rket forces will drive ISPs and browser makers to implement just that, = without even having it MUST-established.

&#= 8220;Who does not want a “WebRTC-Ready” Internet = access?” and

&#= 8220;Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?” and vice = versa.

 

Pl= ease see further emails soon following this one, for details and = history.

 

/K= arl

 

Fr=E5n: Pal = Martinsen (palmarti) [mailto:palmarti@cisco.com]
Skickat: den = 21 februari 2014 10:37
Till: tram@ietf.org
Kopia: = Oleg Moskalenko; Alan Johnston; Karl Stahl; Yoakum, John H = (John)
=C4mne: Re: [tram] I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

Hi,

 

I = agree the full QoS discussion should _not_ happen in TRAM. If you are = interested in helping out in that area I suggest you looking into the = AEON mailing list at: https://www.ietf.org/= mailman/listinfo/aeon . They are currently working on a = problem-statement draft and a use-case draft, any input to those would = be very helpful. (http://= tools.ietf.org/html/draft-eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00).

 

That said, STUN have a few nice characteristics that = makes it a perfect candidate for transporting some of the QoS = information.  IMHO that would be extending the STUN spec and should = be within the TRAM charter.  The main goal = of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and = to start the discussion if TRAM is the appropriate place to have those = on the wire format discussions.

 

.-.

P=E5l-Erik

 

 

On 20 Feb 2014, at 19:55 pm, = Yoakum, John H (John) <yoakum@avaya.com> = wrote:



+1

I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts.  There are other groups = doing QOS work and frankly I engage in WebRTC multimedia interactions = daily over the Internet, enterprise VPNs, and various combinations and = seldom suffer egregious quality issues.  I am more concerned about = carriers doing things to regulate or degrade WebRTC flows than a failure = of existing Internet mechanisms to enable them.

 

Significant focus on QOS before we better enable TURN to be easily = used in a browser environment taking advantage or normal web = characteristics (as opposed to historic telephony constructs) would seem = to be highly distracting at this point.

 

 

Ch= eers,

Jo= hn

&nb= sp;

AVAY= A
1.9= 19.425.8446

 

From:=  tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg = Moskalenko
Sent: Thursday, February 20, 2014 = 12:43 PM
To: Alan = Johnston
Cc: Karl Stahl; tram@ietf.org
Subject: Re: [tram] Fwd: I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

 

 

On Thu, Feb 20, 2014 at 6:26 AM, = Alan Johnston <alan.b.johnston@gmail.com> = wrote:

 

 

 

Personally, I am not sure how much = QoS is actually in scope for TRAM. Have you been following RMCAT where = congestion avoidance for RTP is being developed?  I see some = overlap in your goals and the goals of that = work.

-

 

 

I'd = concentrate on the TURN application-level functionality, for now, and = I'd leave QoS for the future = discussions.


__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/= mailman/listinfo/tram

 

------=_NextPart_000_0500_01CF31BC.F07B9F80-- From nobody Mon Feb 24 17:46: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 099B01A0238; Mon, 24 Feb 2014 17:46:12 -0800 (PST) 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_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 C6YVjW9KhBcJ; Mon, 24 Feb 2014 17:46:05 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 43E461A02F2; Mon, 24 Feb 2014 17:46:03 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402250245576737; Tue, 25 Feb 2014 02:45:57 +0100 From: "Karl Stahl" To: "'Colin Perkins'" References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> In-Reply-To: <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> Date: Tue, 25 Feb 2014 02:45:52 +0100 Message-ID: <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_052F_01CF31D3.B4D608A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8xsw6MT6VAbRocR6mnZ5R57HbLIwAEbGug Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dZYoPPuAL_u38SVMwVebnouCJb4 Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [rtcweb] [tram] Payload Types assignments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 01:46:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_052F_01CF31D3.B4D608A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Colin, =20 If the below were the case, it would be =93DPI guesswork=94 that I also = advice against. RTP doesn=92t even have unique protocol header within UDP =96 = it can even be confused with other UDP payload.=20 =20 However, if the RTP is captured in a TURN-flow, as in TRAM Milestone 3, = the network point that this flow is directed to and can apply QoS methods relevant to the network (which is not diffserve in Mobile OTT and Cable Networks) has not a too difficult tasks. Linking each RTP-flow by its ID = and sequence number, and picking exactly the right traffic type and = bandwidth parameters is doable (see inline below, we at Ingate do it already)! =20 Also DiffServ DSCP-bits are seldom maintained crossing network = boundaries, thus carrying no relevant information at the receiving end, while the = RTP extension header remains unchanged end-to-end. In DSCP-bits, there is no bandwidth requirement information when entering networks requiring reservation. That is always (and dynamically set) available in the RTP extension header for each packet. =20 And, I am sure you are aware of the difficulties of getting DSCP-bits through OS sockets, which is even worse with multiple streams over the = same UDP-port =20 Further, defining the QoS RTP extension header as in RFC5285, does not = in anyway conflict with other RTP extension headers or DSCP transfer or settings. =20 /Karl =20 Fr=E5n: Colin Perkins [mailto:csp@csperkins.org]=20 Skickat: den 24 februari 2014 23:52 Till: Karl Stahl Kopia: rtcweb@ietf.org; Magnus Westerlund; tram@ietf.org; Harald = Alvestrand =C4mne: Re: [rtcweb] [tram] Payload Types assignments =20 Karl, =20 I strongly disagree with this suggestion. An RTP header extension, = located at an unknown and variable offset into a packet that does not have a well-defined magic number in the header,=20 This is how to find the traffic info: The payload of the classifier header extension element can be encoded using either the one-byte or two-byte header defined in [rfc5285 ] and shown below in Figure 1 and 2 below. =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len=3D1 | Namespace | Value | 0 (pad) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Figure 1: Classifier Using the One-Byte Header =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len=3D2 | Namespace | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 Figure 2: Classifier Using the Two-Byte Header =20 indicated using a dynamically assigned identifier that is conveyed in an out-of-band=20 --- It is the TURN flow!!! Requested by the ICE protocol for the = specific media to come! and encrypted signalling channel,=20 --- Only the payload is encrypted in SRTP =96 leaving id, seq no and = header ext to be used as intended! --- Thus being the appropriate place=85 is not an appropriate place to put QoS information that has to be = processed on a per-packet basis.=20 If you want DiffServ, you know where to find it. --- True, but if it cannot be used=85 Colin =20 =20 On 24 Feb 2014, at 22:09, Karl Stahl wrote: I suggest to the RTCWEB WG that the below from the September and October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is introduced into draft-ietf-rtcweb-rtp-usage for usage of RFC 5285, to = allow: =20 (1) WebRTC applications to directly convey QoS related real-time traffic info to the network at points where RTP flow is directed to by TRAM = Milstone 3, to be used by *any network element implementing any suitable QoS = methods for the particular network* for=20 (2) *all* WebRTC browsers *and* clients, under *all* OSs, and *all* = current and future IP network, to achieve best QoE=20 (3) *without* having to force WebRTC into application specific networks (such as IMS) instead of using the Internet (including OTT). =20 The only further activity required, is to call for ISPs=92 to review = whether the traffic information transferred by RFC 5285 is sufficient for = current and future needs in their network as suggested in below repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =85two parameters (e.g. two bytes each) are encoded into the RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each for quality type e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Then this could be assigned numbers to have an RFC in place. =20 With TRAM milestone 3 also place,=20 market forces will drive ISPs and browser makers to implement just this, without even having it MUST-established. =20 =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. =20 Please see further emails soon following this one, for details and = history. =20 /Karl =20 =20 Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Karl Stahl Skickat: den 22 oktober 2013 16:37 Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus Westerlund' Kopia: 'Colin Perkins' =C4mne: [rtcweb] [avtext] Payload Types assignments was Re: SV: [mmusic] = WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 Harald, I mostly agree with the quality requirements of different = real-time traffic that the WebRTC browser/application may use. But rather than = asking the application, let's convey the bandwidth and priority requirements to = the network. Just like with the Payload type (that is hard to squeeze that information into) it must be visible to the network (and not changed by = the network, like diffserv bits are). Such marking must also be available = for incoming traffic, which is especially important in RSVP type of = networks, that has to reserve bandwidth for it. =20 =20 There is actually a good way to show these needs to the network (without using the PT, or diffserv bits, which aren=92t sufficient anyway).=20 =20 Let's use the RTP header extension field that also is visible outside = the encrypted payload. A week ago came http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that outlines the usage of the extension field for classification of traffic! This document does not yet outline what to put in there and how to = encode it though. =20 Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 = discusses other webrtc usages of the RTP header extension in 5.2 (there can be = many header extensions according to RFC 5285) and in 9 there is "WebRTC Use = of RTP: Future Extensions". =20 So, it looks obvious to use the RTP header extension to show the characteristics and bandwidth requirements to the network. It should not introduce any backward incompatibilities either. =20 Such marking is done in every RTP packet so it can be set individually = for each stream and could even be changed during a session (e.g. when = limiting the bandwidth based on RTCP feedback). RFC 5286 also specifies how RTP extension header usage can be negotiated in SDP. I think this could be easily done by the WebRTC browser for "all current and future needs" if properly specified now. =20 I suggest that two parameters (e.g. two bytes each) are encoded into the = RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each quality e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Please note the totally different requirements a diffserv and an RSVP network have to know, so let=92s put all into these bytes. (E.g. a = diffserv network don't need the bandwidth usage, but RSVP reservation networks = (e.g. cable and 3G/4G OTT) do. There one should initially reserve the maximum bandwidth indicated, but can later re-reserve.) =20 /Karl =20 PS Microsoft seems to have done work in this field, defining a = proprietary attribute =93MS Service Quality=94;=20 However that seems to apply to the TURN server allocation request and = would therefore: --- Apply to the whole UDP flow, and could not be set for each stream individually (with different requirements), and --- Does not handle the bandwidth requirement for incoming real-time = traffic (required to reserve in RSVP type of networks) However the quality attributes conveyed and their encoding may be considered. =20 This is 2.2.2.19 MS-Service Quality Attribute from=20 http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx=20 =20 MS-Service Quality Attribute The MS-Service Quality attribute is used to convey information about the data stream that the protocol client is intending to transfer over an allocated port. The protocol client SHOULD<21> include this attribute as part of an Allocate request message. A TURN server SHOULD use the information in this attribute to make decisions about resource = allocation, bandwidth prioritization, and data delivery methods. If the attribute is = not present in the Allocate request message, the TURN server SHOULD assume = that the data stream is audio with best effort delivery. The format of this attribute is as follows...=20 ... The following stream types are supported in this extension. All other = stream types are reserved for future use. =A7 "0x0001": Audio =A7 "0x0002": Video =A7 "0x0003": Supplemental Video =A7 "0x0004": Data Service Quality (2 bytes): The service quality level required by the protocol client for the stream. The following service quality levels are supported in this extension. = All other service quality levels are reserved for future use. =A7 "0x0000": Best effort delivery. =A7 "0x0001": Reliable delivery. =20 =20 -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Harald Alvestrand Skickat: den 8 oktober 2013 13:01 Till: rtcweb@ietf.org =C4mne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC = of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 On 10/08/2013 09:17 AM, Karl Stahl wrote: > Hej Magnus, >=20 >> Also, are you really interested in knowing that it is VP9 vs H.264,=20 >> isn't > the questions this is video of this priority that is important? >> I think you need to more carefully consider what are the goals you=20 >> try to > achieve them. >=20 > Actually, my concern is to get an idea of the maximum bandwidth that=20 > could be required for a WebRTC (ICE) setup media flow. Both voice and=20 > video should be prioritized over data (their individual priority is of = > less importance as long as there is sufficient bandwidth for both). =20 You don't know that without knowing what the application is for. In, for instance, a shooter game with voice backchannels, the movement = and event information (data) is MORE time sensitive than the voice data. =20 >=20 > With diffserv you don=92t need to know the bandwidth requirement, but=20 > with RSVP reservation (like in cable and mobile networks) you need to=20 > know how much to reserve. Voice is like 100's kbit/s, video VP8 or=20 > H.264 is like 3,5 mbps. =20 Again, without knowing the application, you don't know that. The application could decide to use QCIF or HD, and the bandwidth = variation of screencast (semi-static with sudden, large changes) is completely different from that of a talking head, which is again completely = different from a high-movement scene. =20 >=20 > To add to the complication of codec variants, the video codecs in=20 > question for WebRTC have variable bandwidth, and when there is a poor=20 > connection we see Chrome reducing the video window size to reduce the bandwidth used... >=20 > I think the payload type field at best can reflect a maximum bandwidth = > to initially reserve bandwidth for, and thereafter make new=20 > reservations if the bandwidth changes during the call. So could we=20 > change RTP to show maximum bandwidth instead of payload type in that=20 > field outside the encrypted payload :) ... Or maybe that is not a = joke? =20 I think these ruminations only lead to one conclusion: =20 You can't tell what the needed bandwidth is up front without asking the application. You can't tell what the right priority ranking is without asking the application. =20 If you need to know the bandwidth or the priority up front, the = application has to tell you. Anything else is pure heuristics. =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 =20 --=20 Colin Perkins http://csperkins.org/ =20 =20 =20 ------=_NextPart_000_052F_01CF31D3.B4D608A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Co= lin,

 

If= the below were the case, it would be “DPI guesswork” that I = also advice against. RTP doesn’t even have unique protocol header = within UDP – it can even be confused with other UDP payload. =

 

Ho= wever, if the RTP is captured in a TURN-flow, as in TRAM Milestone 3, = the network point that this flow is directed to and can apply QoS = methods relevant to the network (which is not diffserve in Mobile OTT = and Cable Networks) has not a too difficult tasks. Linking each RTP-flow = by its ID and sequence number, and picking exactly the right traffic = type and bandwidth parameters is doable (see inline below, we at Ingate = do it already)!

 

Al= so DiffServ DSCP-bits are seldom maintained crossing network boundaries, = thus carrying no relevant information at the receiving end, while the = RTP extension header remains unchanged end-to-end. In DSCP-bits, there = is no bandwidth requirement information when entering networks requiring = reservation. That is always (and dynamically set) available in the RTP = extension header for each packet.

 

An= d, I am sure you are aware of the difficulties of getting DSCP-bits = through OS sockets, which is even worse with multiple streams over the = same UDP-port

 

Fu= rther, defining the QoS RTP extension header as in RFC5285, does not in = anyway conflict with other RTP extension headers or DSCP transfer or = settings.

 

/K= arl

 

Fr=E5n: Colin = Perkins [mailto:csp@csperkins.org]
Skickat: den 24 februari = 2014 23:52
Till: Karl Stahl
Kopia: rtcweb@ietf.org; = Magnus Westerlund; tram@ietf.org; Harald Alvestrand
=C4mne: = Re: [rtcweb] [tram] Payload Types = assignments

 

Karl,

 

I = strongly disagree with this suggestion. An RTP header extension, located = at an unknown and variable offset into a packet that does not have a = well-defined magic number in the header,

Th= is is how to find the traffic info:

=A0=A0 The payload = of the classifier header extension element can be = encoded

=A0=A0 using either = the one-byte or two-byte header defined in [rfc5285] = and

=A0=A0 shown below = in Figure 1 and 2 below.

 

=A0=A0=A0=A0=A0 = 0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 3

=A0=A0=A0=A0=A0 0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

=A0=A0=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0=A0=A0 |=A0 = ID=A0=A0 | len=3D1 |=A0=A0 Namespace=A0=A0 |=A0=A0=A0 = Value=A0=A0=A0=A0=A0 |=A0=A0=A0 0 (pad)=A0=A0=A0 = |

=A0=A0=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 1: Classifier Using = the One-Byte Header

 

=A0=A0=A0=A0=A0 = 0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A01=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 = 2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 3

=A0=A0=A0=A0=A0 0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

=A0=A0=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0 ID=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 len=3D2=A0=A0=A0=A0=A0 = |=A0=A0 Namespace=A0=A0 |=A0=A0=A0 Value=A0=A0=A0=A0=A0 = |

=A0=A0=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 2: Classifier Using = the Two-Byte Header

 

indicated using a dynamically assigned identifier that is = conveyed in an out-of-band

--= - It is the TURN flow!!! Requested by the ICE protocol for the specific = media to come!

and encrypted signalling channel,

--= - Only the payload is encrypted in SRTP – leaving id, seq no and = header ext to be used as intended!

--= - Thus being the appropriate place…

is not an appropriate place to put = QoS information that has to be processed on a per-packet basis.

If you want DiffServ, you know = where to find it.

--- True, but = if it cannot be used…

Colin

 

 

On = 24 Feb 2014, at 22:09, Karl Stahl <karl.stahl@intertex.se> = wrote:

I = suggest to the RTCWEB WG that the below from the September and October = discussions on the relevant [rtcweb] [avtext] = [mmusic] = lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = is introduced into draft-ietf-rtcweb-rtp-usage = fo= r usage of RFC 5285, to allow:

&n= bsp;

(1= ) WebRTC applications to directly convey QoS related real-time traffic = info to the network at points where RTP flow is directed to by TRAM = Milstone 3, to be used by *any network element implementing any = suitable QoS methods for the particular network* for =

(2= ) *all* WebRTC browsers *and* clients, under *all* = OSs, and *all* current and future IP network, to achieve best QoE =

(3= ) *without* ha= ving to force WebRTC into application specific networks (such as IMS) = instead of using the Internet (including OTT).

&n= bsp;

Th= e only further activity required, is to call for ISPs’ to review = whether the traffic information transferred by RFC 5285 is sufficient = for current and future needs in their network as suggested in below = repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip><= /span>

…two = parameters (e.g. two bytes each) are encoded into the RTP header = extension:

 =

A) The = maximum bandwidth requirement: Two bytes could contain everything from = some bps for real-time text to Gbps for future 3D supersize = telepresence… on a logarithmic scale.

 =

B) The = quality characteristics for the stream, with the highest bit set to 1, = we could allocate a bit each for quality type = e.g:

Best Effort, = Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. = video streaming), Minimum Delay, Reliable Delivery, Prioritize X, = Variation Y, that could be combined as required to describe the = stream.

 =

And with = highest bit set to 0, there could instead be a number for special usage = that does not fit the general description of the individual = bits.

</snip>=

&n= bsp;

Th= en this could be assigned numbers to have an RFC in = place.

&n= bsp;

Wi= th TRAM milestone 3 also place,

ma= rket forces will drive ISPs and browser makers to implement just this, = without even having it MUST-established.

&n= bsp;

&#= 8220;Who does not want a “WebRTC-Ready” Internet = access?” and

&#= 8220;Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?” and vice = versa.

&n= bsp;

Pl= ease see further emails soon following this one, for details and = history.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r Karl Stahl
Skickat: den 22 oktober 2013 = 16:37
Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus = Westerlund'
Kopia: 'Colin Perkins'
=C4mne: [rtcweb] = [avtext] Payload Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

Harald, I mostly agree with the quality requirements of = different real-time traffic that the WebRTC browser/application may use. = But rather than asking the application, let's convey the bandwidth and = priority requirements to the network. Just like with the Payload type = (that is hard to squeeze that information into) it must be visible to = the network (and not changed by the network, like diffserv bits are). = Such marking must also be available for incoming traffic, which is = especially important in RSVP type of networks, that has to reserve = bandwidth for it.  

 

There is actually a good way to = show these needs to the network (without using the PT, or diffserv bits, = which aren’t sufficient anyway).

 

Let's use the RTP header = extension field that also is visible outside the encrypted payload. A = week ago came h= ttp://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 =  that outlines the usage of the extension field for classification = of traffic! This document does not yet outline what to put in there and = how to encode it though.

 

Today's http:/= /tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 discusses other = webrtc usages of the RTP header extension in 5.2 (there can be many = header extensions according to RFC 5285) and in 9 there is "WebRTC = Use of RTP: Future Extensions".

 

So, it looks obvious to use the = RTP header extension to show the characteristics and bandwidth = requirements to the network. It should not introduce any backward = incompatibilities either.

 

Such marking is done in every = RTP packet so it can be set individually for each stream and could even = be changed during a session (e.g. when limiting the bandwidth based on = RTCP feedback). RFC 5286 also specifies how RTP extension header usage = can be negotiated in SDP. I think this could be easily done by the = WebRTC browser for "all current and future needs" if properly = specified now.

 

I suggest that two parameters (e.g. two bytes each) are = encoded into the RTP header extension:

 

A) The maximum bandwidth = requirement: Two bytes could contain everything from some bps for = real-time text to Gbps for future 3D supersize telepresence… on a = logarithmic scale.

 

B) The quality characteristics for the stream, with the = highest bit set to 1, we could allocate a bit each quality = e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, = Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable = Delivery, Prioritize X, Variation Y, that could be combined as required = to describe the stream.

 

And with highest bit set to 0, = there could instead be a number for special usage that does not fit the = general description of the individual bits.

 

Please note the totally = different requirements a diffserv and an RSVP network have to know, so = let’s put all into these bytes. (E.g. a diffserv network don't = need the bandwidth usage, but RSVP reservation networks (e.g. cable and = 3G/4G OTT) do. There one should initially reserve the maximum bandwidth = indicated, but can later re-reserve.)

 

/Karl

 

PS Microsoft seems to have = done work in this field, defining a proprietary attribute “MS = Service Quality”;

However that seems to apply = to the TURN server allocation request and would = therefore:

--- Apply to = the whole UDP flow, and could not be set for each stream individually = (with different requirements), and

--- Does not handle the = bandwidth requirement for incoming real-time traffic (required to = reserve in RSVP type of networks)

However the quality = attributes conveyed and their encoding may  be = considered.

 

=

This is 2.2.2.19 MS-Service = Quality Attribute from

http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).asp= x 

 

MS-Service Quality = Attribute

The MS-Service = Quality attribute is used to convey information about the data stream = that the protocol client is intending to transfer over an allocated = port. The protocol client SHOULD<21> include this attribute as = part of an Allocate request message. A TURN server SHOULD use the = information in this attribute to make = decisions about resource allocation, bandwidth prioritization, and data = delivery methods. If the attribute is not present in the Allocate = request message, the TURN server SHOULD assume that the data stream is = audio with best effort delivery. The format of this attribute is as = follows...

...

The following stream types = are supported in this extension. All other stream types are reserved for = future use.

=A7 "0x0001": = Audio

=A7 "0x0002": = Video

=A7 "0x0003": = Supplemental Video

=A7 = "0x0004": = Data

Service = Quality (2 bytes): The service quality level required by the protocol = client for the stream.

The following service = quality levels are supported in this extension. All other service = quality levels are reserved for future use.

=A7 = "0x0000": Best = effort delivery.

=A7 = "0x0001": = Reliable delivery.

 

 

-----Ursprungligt meddelande-----

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r Harald Alvestrand

Skickat: den 8 oktober 2013 13:01

Till: rtcweb@ietf.org

=C4mne: Re: [rtcweb] Payload = Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

On 10/08/2013 09:17 AM, Karl = Stahl wrote:

> Hej Magnus,

> 

>> Also, are you really = interested in knowing that it is VP9 vs H.264,

>> = isn't

> the questions this is video of this priority that is = important?

>> I think you need to more carefully consider what = are the goals you

>> try to

> achieve = them.

> 

> Actually, my concern is to = get an idea of the maximum bandwidth that

> could be required for a = WebRTC (ICE) setup media flow. Both voice and

> video should be prioritized = over data (their individual priority is of

> less importance as long as = there is sufficient bandwidth for both).

 

You don't know that without = knowing what the application is for.

In, for instance, a shooter game = with voice backchannels, the movement and event information (data) is = MORE time sensitive than the voice data.

 

> 

> With diffserv you = don’t need to know the bandwidth requirement, but =

> = with RSVP reservation (like in cable and mobile networks) you need to =

> = know how much to reserve. Voice is like 100's kbit/s, video VP8 or =

> = H.264 is like 3,5 mbps.

 

Again, without knowing the = application, you don't know that.

The application could decide to = use QCIF or HD, and the bandwidth variation of screencast (semi-static = with sudden, large changes) is completely different from that of a = talking head, which is again completely different from a high-movement = scene.

 

> 

> To add to the complication = of codec variants, the video codecs in

> question for WebRTC have = variable bandwidth, and when there is a poor

> connection we see Chrome = reducing the video window size to reduce the bandwidth = used...

> 

> I think the payload type = field at best can reflect a maximum bandwidth

> to initially reserve = bandwidth for, and thereafter make new

> reservations if the = bandwidth changes during the call. So could we

> change RTP to show maximum = bandwidth instead of payload type in that

> field outside the encrypted = payload :) ... Or maybe that is not a joke?

 

I think these ruminations only = lead to one conclusion:

 

You can't tell what the needed = bandwidth is up front without asking the = application.

You can't tell what the right priority ranking is without = asking the application.

 

If you need to know the = bandwidth or the priority up front, the application has to tell you. = Anything else is pure heuristics.

 

_______________________________________________<= /o:p>

rtcweb mailing = list

rtcweb@ietf.org

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

 

 

-- 

Colin Perkins

 

 

 

------=_NextPart_000_052F_01CF31D3.B4D608A0-- From nobody Mon Feb 24 23:09: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 DE4401A0339 for ; Mon, 24 Feb 2014 23:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, 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 zHPtloi1ri6z for ; Mon, 24 Feb 2014 23:09:40 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 815F31A01CC for ; Mon, 24 Feb 2014 23:09:40 -0800 (PST) Received: from [10.0.6.246] (p578b6f8e.dip0.t-ipconnect.de [87.139.111.142]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 30E881C0B4057; Tue, 25 Feb 2014 08:09:38 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D16D2A3@ESESSMB209.ericsson.se> Date: Tue, 25 Feb 2014 08:09:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D16D2A3@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/q_3TRWm0aLoXkL8aKsIJQJfUvbw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Some editorial comments on section 5 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 07:09:44 -0000 On Feb 11, 2014, at 7:12 PM, Christer Holmberg = wrote: > Hi, >=20 > Some editorial comments: >=20 > Q1: >=20 > Section 5 says: >=20 > "SCTP as specified in [RFC4960] MUST be used in > combination with the extension defined in [RFC3758] and provides = the > following interesting features for transporting non-media data > between browsers:" >=20 > I suggest to say: >=20 > "The SCTP extension defined in [RFC3758] MUST be supported, and > provides the following features: But this implies that the listed features are provided by the extension defined in RFC 3758, which is not true. The features are provided by the combination of RFC 4960 and RFC 3758. >=20 >=20 > Q2: >=20 > Section 5 says: >=20 > "Each SCTP user message contains a so called Payload Protocol > Identifier (PPID) that is passed..." >=20 > I suggest to remove "so called". Removed. >=20 >=20 > Q3: >=20 > Section 5 says: >=20 > "This value can be used to multiplex multiple protocols > over a single SCTP association. The sender provides for each > protocol a specific PPID and the receiver can demultiplex the > messages based on the received PPID." >=20 > I think we discussed this earlier. The PPID value CAN NOT (at least = not as used by WebRTC) be used to multiplex multiple protocols over a = single SCTP association. If you create multiple channels, for multiple = protocols, the same PPID values may be used for each protocol. >=20 > The PPID CAN, however, be used within a data channel, e.g. to = demultiplex the DCP from channel data. I guess the problem is that I consider 'protocol' as something running = on top of SCTP like DCEP, Binary of String data, you consider 'protocol' as something = running on top of Binary of String data and the 'protocol' being identified in = the JS protocol string. What about using: Each SCTP user message contains a Payload Protocol Identifier (PPID) that is passed to SCTP by its upper layer on the sending side and provided to its upper layer on the receiving side. The PPID can be used to multiplex/demultiplex multiple upper layers over a single SCTP association. In the WebRTP context, the PPID is used to distinguish between UTF-8 encoded user data, binary encoded userdata and the Data Channel Establishment Protocol defined in . Please note that the PPID is not accessable via the Javascript API. Does this address your issue? >=20 >=20 > Q4: >=20 > Section 5 says: >=20 > "When using DTLS as the lower layer, only single homed SCTP > associations MUST be used, since DTLS does not expose any = address > management to its upper layer." >=20 > I suggest to change "MUST be used" to "are supported". OK. >=20 >=20 > Q5: >=20 > Sometimes you say "SCTP" and sometimes "SCTP as defined in [RFC4960]". >=20 > I suggest to e.g. use the reference on the first occurrence, and then = only use "SCTP". I double checked: SCTP as defined in [RFC4960] is used in * In the Introduction (first occurrence) talking about SCTP / UDP * In the Introduction to make sure which specifications are used: RFC = 4960 and RFC 3758 * In section 5 when used with RFC 2119 language. * In section 6 to make clear what relates to RFC 4960 and what to the = NDATA extension. All of these are intentional. Which one do you think is not necessary? >=20 >=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Tue Feb 25 00:00: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 494B61A02D8; Mon, 24 Feb 2014 16:20:42 -0800 (PST) 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_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 2Yac5EBfSkH2; Mon, 24 Feb 2014 16:20:38 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 71AD11A0334; Mon, 24 Feb 2014 16:20:36 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402250120330129; Tue, 25 Feb 2014 01:20:33 +0100 From: "Karl Stahl" To: "'Alan Johnston'" , , , "'Bernard Aboba'" , "'David Singer'" , "'Harald Alvestrand'" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> In-Reply-To: Date: Tue, 25 Feb 2014 01:20:30 +0100 Message-ID: <050401cf31bf$64ae8ff0$2e0bafd0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0505_01CF31C7.C672F7F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8vLpOyXxkwjXJURauBPg8ftk+5EwBhXIDA Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Std_6_TuPFzv2J4yYcOb9ZU-mDg X-Mailman-Approved-At: Tue, 25 Feb 2014 00:00:28 -0800 Cc: "'Cullen Jennings \(fluffy\)'" , marc.robins@sipforum.org, eburger@standardstrack.com, mary.barnes@polycom.com, 'Henning Schulzrinne' Subject: Re: [rtcweb] [tram] I-D Action: draft-thomson-tram-turn-bandwidth-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, 25 Feb 2014 00:20:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0505_01CF31C7.C672F7F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alan, =20 I have in previous email http://www.ietf.org/mail-archive/web/tram/current/msg00304.html = suggested that both DISCUSS and draft-thomson-tram-turn-bandwidth-00.txt is taken = off the TRAM WG, but I think is shall be reintroduced after you clarify as = you do in=20 http://www.ietf.org/mail-archive/web/tram/current/msg00300.html : Hi Karl, Thanks for your comments and feedback on the draft. You are correct in saying that the BANDWIDTH extension is not about QoS. = It is about fairness between users of a TURN server, and a TURN server = being able to indicate rate limiting policy to users. in the draft. =20 The =93confusion=94 (to say least, see below) surrounding QoS within = IETF has lead me to protest and address the TRAM WG and RTCWEB WG and ADs with = the advise in = http://www.ietf.org/mail-archive/web/tram/current/msg00304.html : =93The TRAM WG and RTCWEB WG chairs and ADs are advised to review = whether IETF standard work in these WGs by contributors having an interest in more = than one of current or emerging: ISPs, carrier equipment vendors or web = browser makers, may discriminate any with an interest only in one of these. The = same should apply to non-activity by WG contributors to remedy such discrimination opened by allowed proprietary usage of RFCs such as RFC 5285.=94=20 =20 This is because the introduction of the QoS related usage of RFC 5285 = into draft-ietf-rtcweb-rtp-usage in combinations with the Milestone 3 = objectives of TRAM, immediately would allow for: (1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP = variants) to quickly allow us to finally enjoy the high quality and connectivity (NAT/firewall traversal) of real-time communication services now = possible, for =20 (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), = under *all* OSs, and *all* current and future IP networks=20 (3) *without* having to be forced into application specific networks = (PSTN, IMS) instead of the Internet (including OTT). =20 While the =93confusion=94 surrounding the QoS discussion in TRAM and = RTCWEB combined with the general QoS attitude within IETF =93it is all about bandwidth=94 and =93it will go away with time=94 otherwise: (i) will *not allow* ISP=92s to use already available and currently = deployable quality IP pipes for real-time traffic to also be used for WebRTC = generated real-time traffic. (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. That all networks *will be inhibited* from the = very common and used method of simply providing an extra IP pipe (often = provided over the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) *while* newer, fiber only type of networks, still can borrow bandwidth = at no extra cost, *by proprietary usage* of RFC 5285 by browsers.=20 (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may have to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes = intermittently are filled, whatever bandwidth is available). =20 As Good doers, we should not allow this to happen. =20 /Karl =20 =20 Fr=E5n: Alan Johnston [mailto:alan.b.johnston@gmail.com]=20 Skickat: den 21 februari 2014 18:59 Till: Pal Martinsen (palmarti) Kopia: tram@ietf.org; Oleg Moskalenko; Karl Stahl; Yoakum, John H (John) =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 I guess the way I would expect this to progress is for QoS discussions = to happen in another working group. Once that other working group came to consensus on an approach, and if that approach required STUN or TURN extensions, then we would discuss mechanisms and possible milestones in TRAM. =20 - Alan - =20 On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen (palmarti) wrote: Hi, =20 I agree the full QoS discussion should _not_ happen in TRAM. If you are interested in helping out in that area I suggest you looking into the = AEON mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are currently working on a problem-statement draft and a use-case draft, any input to those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). =20 That said, STUN have a few nice characteristics that makes it a perfect candidate for transporting some of the QoS information. IMHO that would = be extending the STUN spec and should be within the TRAM charter. The main goal of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and to start the discussion if TRAM is the appropriate place to have those on = the wire format discussions. =20 .-. P=E5l-Erik =20 =20 On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) < yoakum@avaya.com> wrote: +1 I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts. There are other groups doing QOS = work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterprise VPNs, and various combinations and seldom suffer egregious quality issues. I am more concerned about carriers doing = things to regulate or degrade WebRTC flows than a failure of existing Internet mechanisms to enable them. =20 Significant focus on QOS before we better enable TURN to be easily used = in a browser environment taking advantage or normal web characteristics (as opposed to historic telephony constructs) would seem to be highly distracting at this point. =20 =20 Cheers, John =20 AVAYA 1.919.425.8446 =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 12:43 PM To: Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 =20 =20 On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston < alan.b.johnston@gmail.com> wrote: =20 =20 =20 Personally, I am not sure how much QoS is actually in scope for TRAM. = Have you been following RMCAT where congestion avoidance for RTP is being developed? I see some overlap in your goals and the goals of that work. - =20 =20 I'd concentrate on the TURN application-level functionality, for now, = and I'd leave QoS for the future discussions. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 ------=_NextPart_000_0505_01CF31C7.C672F7F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi= Alan,

 

I = have in previous email = http://www.ietf.org/mail-archive/web/tram/current/msg00304.html = suggested that both DISCUSS and draft-thomson-tram-turn-bandwidth-00.txt = is taken off the TRAM WG, but I think is shall be reintroduced after you = clarify as you do in

= http://www.ietf.org/mail-archive/web/tram/current/msg00300.html = :

Hi Karl, = Thanks for your comments and feedback on the = draft.

You = are correct in saying that the BANDWIDTH extension is not about QoS. =  It is about fairness between users of a TURN server, and a TURN = server being able to indicate rate limiting policy to users. = in= the draft.

 

Th= e “confusion” (to say least, see below) surrounding QoS = within IETF has lead me to protest and address th= e TRAM WG and RTCWEB WG and ADs with the advise in = http://www.ietf.org/mail-archive/web/tram/current/msg00304.html = :

&#= 8220;Th= e TRAM WG and RTCWEB WG chairs and ADs are advised to review whether = IETF standard work in these WGs by contributors having an interest in = more than one of current or emerging: ISPs, carrier equipment vendors or = web browser makers, may discriminate any with an interest only in one of = these. The same should apply to non-activity by WG contributors to = remedy such discrimination opened by allowed proprietary usage of RFCs = such as RFC 5285.&#= 8221;

 

Th= is is because the in= troduction of the QoS related usage of RFC 5285 into draft-ietf-rtcweb-rtp-usage in= combinations with the Milestone 3 objectives of TRAM, immediately would = allow for:

(1= ) = *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in = addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP = variants) to quickly allow us to finally enjoy the high quality and = connectivity (NAT/firewall traversal) of real-time communication = services now possible, for  

(2= ) = *all* WebRTC browsers *and* dedicated clients (not using = WebRTC), under *all* OSs, and *all* current and future IP = networks

(3= ) *without* ha= ving to be forced into application specific networks (PSTN, IMS) instead = of the Internet (including OTT).

 

Wh= ile the “confusion” surrounding the QoS discussion in TRAM = and RTCWEB combined with the ge= neral QoS attitude within IETF “it is all about bandwidth” = and “it will go away with time” ot= herwise:

(i= ) = will *not allow* ISP’s to use already available and = currently deployable quality IP pipes for real-time traffic to also be = used for WebRTC generated real-time traffic.

(i= i) = will *not allow* some network types (e.g. Cable Networks and = Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive = streaming video and file sharing. That all networks *will be = inhibited* from the very common and used method of simply providing = an extra IP pipe (often provided over the same wire but level-2 = separated) dedicated for real-time usage

(<= b>*by resisting TRAM implementation of step = B*)

*<= b>while* newer, fiber only type of networks, still can borrow = bandwidth at no extra cost, *by proprietary usage* of RFC 5285 by = browsers.

(i= ii) = will leave most ISPs to *only use* raw bandwidth capacity = increase that may have to be 10-folded to reach sufficient QoE when = WebRTC usage becomes popular (if at all possible, since unmanaged IP = pipes intermittently are filled, whatever bandwidth is = available).

 

As= Good doers, we should not allow this to happen.

 

/K= arl

 

 

Fr=E5n: Alan = Johnston [mailto:alan.b.johnston@gmail.com]
Skickat: den 21 = februari 2014 18:59
Till: Pal Martinsen = (palmarti)
Kopia: tram@ietf.org; Oleg Moskalenko; Karl Stahl; = Yoakum, John H (John)
=C4mne: Re: [tram] I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

I guess = the way I would expect this to progress is for QoS discussions to happen = in another working group.  Once that other working group came to = consensus on an approach, and if that approach required STUN or TURN = extensions, then we would discuss mechanisms and possible milestones in = TRAM.

 

- = Alan -

 

On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen = (palmarti) <palmarti@cisco.com> = wrote:

Hi,

 

I = agree the full QoS discussion should _not_ happen in TRAM. If you are = interested in helping out in that area I suggest you looking into the = AEON mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They = are currently working on a problem-statement draft and a use-case draft, = any input to those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-use-cases-0= 1, http://tools.ietf.org/html/draft-eckel-aeon-problem-sta= tement-00).

 

That said, STUN have a few nice characteristics that = makes it a perfect candidate for transporting some of the QoS = information.  IMHO that would be extending the STUN spec and should = be within the TRAM charter.  The main goal = of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and = to start the discussion if TRAM is the appropriate place to have those = on the wire format discussions.

 

.-.

P=E5l-Erik

 

 

On 20 Feb 2014, at 19:55 pm, = Yoakum, John H (John) <yoakum@avaya.com> wrote:



+1

I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts.  There are other groups = doing QOS work and frankly I engage in WebRTC multimedia interactions = daily over the Internet, enterprise VPNs, and various combinations and = seldom suffer egregious quality issues.  I am more concerned about = carriers doing things to regulate or degrade WebRTC flows than a failure = of existing Internet mechanisms to enable them.

 

Significant focus on QOS before we better enable TURN to be easily = used in a browser environment taking advantage or normal web = characteristics (as opposed to historic telephony constructs) would seem = to be highly distracting at this point.

 

 

Ch= eers,

Jo= hn

&nb= sp;

 

From:=  tram = [mailto:tram-bounces@ietf.org] On Behalf = Of Oleg Moskalenko
Sent: Thursday, February 20, = 2014 12:43 PM
To: Alan Johnston
Cc: Karl = Stahl; tram@ietf.org
Subject: Re: [tram] = Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

 

 

 

On Thu, Feb 20, 2014 at 6:26 AM, = Alan Johnston <alan.b.johnston@gmail.com> = wrote:

 

 

 

Personally, I am not sure how much = QoS is actually in scope for TRAM. Have you been following RMCAT where = congestion avoidance for RTP is being developed?  I see some = overlap in your goals and the goals of that = work.

-

 

 

I'd = concentrate on the TURN application-level functionality, for now, and = I'd leave QoS for the future = discussions.

__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

 

------=_NextPart_000_0505_01CF31C7.C672F7F0-- From nobody Tue Feb 25 00: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 200EA1A0384; Tue, 25 Feb 2014 00:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, 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 10tJQJVH8LUO; Tue, 25 Feb 2014 00:39:44 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C61F81A0329; Tue, 25 Feb 2014 00:39:43 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-29-530c56ce195b Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 17.6E.10875.EC65C035; Tue, 25 Feb 2014 09:39:42 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.2.347.0; Tue, 25 Feb 2014 09:39:41 +0100 Message-ID: <530C56CD.3010003@ericsson.com> Date: Tue, 25 Feb 2014 09:39:41 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Karl Stahl References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> In-Reply-To: <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+Jvje65MJ5gg+P7ZSze9axls1j7r53d 4sPaC2wOzB5Llvxk8vi0dT5LAFMUl01Kak5mWWqRvl0CV8bDK1wFTwQrLvYfZ25g3MzXxcjJ ISFgIrHh9BIWCFtM4sK99WxdjFwcQgKHGCWenDnBDOEsB3L+b2IDqeIV0JY4f2ApO4jNIqAq 8eTUJEYQm03AQuLmj0awGlGBYImdB34zQtQLSpyc+QRsg4iAusS086fAapgF1CQmfbwPNkdY wEri0af1LBDLnrJKfJ8+lRkkwSngIPH0/wqgIg6g88QlehqDIHr1JKZcbWGEsOUlmrfOBisX ArqtoamDdQKj0Cwkq2chaZmFpGUBI/MqRvbcxMyc9HLDTYzAoD245bfuDsZT50QOMUpzsCiJ 83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdH4tZyf+qyPsgf1D3Mq1HUprJ5pFF69 5JPq5EnHuoXONc2dVn3kz/QLqv9ldL8c4WoN4SheVq5oX+/XunR1c1NUmX7p8+xXizfNmi1i VWVmILKHcbqbFvv7vYfNu1KZTrGVCD4ovmLyuECt6ODbhwJliuumCq91cIjXKZu/5dXqZTtf H/bS2K7EUpyRaKjFXFScCAAmPveOKAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/U1j_yasb9HOSCn1lA1p1O15GNks Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [rtcweb] [tram] Payload Types assignments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 08:39:46 -0000 Karl, (As individual) I also wish for more usable QoS mechanisms. However, I don't see that being achieved by your proposal. In addition I agree with Colin about the issues with putting the information in the RTP header extension. I would also note that this would be very RTP specific, and not at all help with the data channels multiple streams and their priorities. There might be data channel information that is more crucial than any of the RTP media stream packets. You are pushing for a small piece in the middle. A piece that will not help with the more general issue of QoS. How does the application and the multiple ISPs that carries the traffic reach an agreement on what properties that can be provided, that the application in this instance have the right to request those properties and that any cost is correctly associated with the user or the user's agent in regards to carrying the associated cost. When it comes to setting DSCP from user land in the OS, that is restricted due to the security implications. If those implications where resolved, then OS could open up those interfaces. There are many interlinked reasons why things look like they do today. I don't believe in tugging on a single random thread in ball of yarn and hope that it comes out without any knots and ties on it. Show me the framework for the QoS functions you have in mind that at least has less issues than the currently deployed and take care of at least some of the bigger issues. If that requires information in the RTP streams for some reasons, then let us talk about how to best encoded it. But, we need that framework first, the architecture that makes this a better solution than the current Diffserv architecture or any other QoS architecture. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Feb 25 01:08: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 7A4811A03C3 for ; Tue, 25 Feb 2014 01:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 NUIdf_qiQf6f for ; Tue, 25 Feb 2014 01:08:50 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 25A3A1A0649 for ; Tue, 25 Feb 2014 01:08:49 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-f7-530c5da06f91 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 50.EA.23809.0AD5C035; Tue, 25 Feb 2014 10:08:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 10:08:48 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Richard Ejzak" Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EP/+ONLQ//ubSNA= Date: Tue, 25 Feb 2014 09:08:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@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.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje6CWJ5ggxOr9C0aNl5htXjW28Bq sfZfO7sDs0frs72sHjtn3WX3WLLkJ1MAcxSXTUpqTmZZapG+XQJXxvf+A+wFU7krumY8ZWxg /MvRxcjJISFgIvGt9z8ThC0mceHeerYuRi4OIYFDjBLfLpxkhXCWMEr8OH8HqIqDg03AQqL7 nzZIg4hAkcS3z/9YQGxmAXWJO4vPsYPYwgKxEu2PdzBB1MRJPHqwjR3CTpI4vv0HI4jNIqAq ce3NN3aQkbwCvhKbz0lDrDrLInFq+h+wmZxAc158PQ02hxHouO+n1jBB7BKXuPVkPtTRAhJL 9pxnhrBFJV4+/scKYStKfHy1jxGiXkdiwe5PbBC2tsSyha/B6nkFBCVOznzCMoFRbBaSsbOQ tMxC0jILScsCRpZVjOy5iZk56eVGmxiBcXNwy2/VHYx3zokcYpTmYFES5/3w1jlISCA9sSQ1 OzW1ILUovqg0J7X4ECMTB6dUAyPvMoPWEw13LxyIVLZXUvjotNLtedfpJLtLyUyKsf+kXHWO f4ydcJKlK10m3S/XdM+/qPtzJhyc9D+8pSRBoYu1wffm9w+HxfsrI6dZ/tJaeSecb++PK3c2 CU1k7K6fzd/4VjSV/c/pF8481/ljfujLpGzeULyN5cP/2t8SxQoZsUpvXYWZtiuxFGckGmox FxUnAgDUSJqDaQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aB3nRvp9OEWBj8d3J_Domwh2k4E Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 09:08:52 -0000 Hi Raju, >> Anyway, can you give me an example of a case where you want to use=20 >> SDP, and where you need to negotiate the re-transmission values etc? > > [Raju] A simple example would be 2 browsers talking thru an intermedia pr= oxy, which wants to know what protocols are > being negitiated and used as part of the session. Sure. I don't question the use-case/need for using SDP to negotiate channel= usages. > 1. Calling client creates data channel (using http://dev.w3.org/2011/webr= tc/editor/webrtc.html#idl-def-RTCDataChannel) with desired > attributes and sets negotiated=3Dtrue. So, calling browser saves the attr= ibutes for the data channel but won't use DCP. > 2. These attributes are sent via SDP to peer client (via proxy). > 3. Peer client sets these same attributes while creating data channel and= sets negotiated=3Dtrue but won't do DCP. > 4. Peer client echo the same attributes back in SDP answer. > > Now, data channel stacks on both ends will use same attributes, similar t= o DCP use case, with the only difference being DCP is not used here. My question was regarding the re-transmission values etc.=20 Why do the peers need to negotiate those? Why would an intermediary need to= know about those? Why not simply define those in the protocol description,= and each endpoint supporting the protocol will then know what values to us= e? Regards, Christer From nobody Tue Feb 25 01:13: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 C80B91A0657 for ; Tue, 25 Feb 2014 01:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, 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 GmC_mC6KIPiQ for ; Tue, 25 Feb 2014 01:13:55 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2EB1A03A4 for ; Tue, 25 Feb 2014 01:13:54 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-c0-530c5ed14db0 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DA.E3.10875.1DE5C035; Tue, 25 Feb 2014 10:13:53 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.2.347.0; Tue, 25 Feb 2014 10:13:52 +0100 Message-ID: <530C5ED0.8040808@ericsson.com> Date: Tue, 25 Feb 2014 10:13:52 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Thomson References: <530627C7.30906@ericsson.com> <53070996.9040707@ericsson.com> <530B194F.4040909@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvje7FOJ5gg+UzBC2unfnHaLH2Xzu7 ReNcOwdmj52z7rJ7LFnykymAKYrLJiU1J7MstUjfLoEr40dDM3PBO6GKzv4vzA2Mi/i7GDk4 JARMJBq7ArsYOYFMMYkL99azgdhCAocYJd7dUuli5AKylzNKfJp9nh2knldAW+LmmzCQGhYB VYmjq/rZQWw2AQuJmz8awXpFBYIldh74zQhi8woISpyc+YQFxBYR0JVYdPYBWD2zgIfEtFtL WUFsYQF7iQd3nzNB7PrLJPGh+zpYM6dAoMSlF6dZIO4Ul+hpDILo1ZRo3f4bao68RPPW2cwQ N2tLNDR1sE5gFJqFZPUsJC2zkLQsYGRexciem5iZk15uuIkRGK4Ht/zW3cF46pzIIUZpDhYl cd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAG7NWO6Y+9r/VITtK6e1rO6opkq7lF WWw7xIz9PfV9LZ9cTrgceaGmyuH5UdbPet1+Ua0FZ+teTJm7YNpjy4bU29x/bH7kHU/Izb9k fGfJr3O5z8SZ+7/0NGf3tjj9n/TbL1p4k+hE+b0f9Oq+7mpIdT2V91Rhk/cShxu//li7rDzN FGz4k1eJpTgj0VCLuag4EQBjG4FZJQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YwgehUhvQ81b2INgcgF8iL1FvWE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 09:13:56 -0000 On 2014-02-24 19:58, Martin Thomson wrote: > On 24 February 2014 02:05, Magnus Westerlund > wrote: >> My position is that the above mitigation is unlikely to have significant >> impact on this attack. > > That was my sense too. > >> There are two reasons I wanted this attack to be considered. First, it >> provides a clear requirement on having congestion control as first level >> mitigation. > > Congestion control. Check. > >> Secondly, I think this could become a significant issue as data channel >> PeerConnections can be opened without user consent. A malicious JS that >> is sufficient well spread with a well working find and connect could >> establish a large mesh of peer connections that could come close to >> saturate each endpoints local access link, resulting in very heavy loads >> on the network, even with congestion control. With congestion control >> you can likely prevent congestion collapse, but you should be fully >> capable of driving a network into a state of "mostly useless", >> especially a network suffering from buffer bloat inside of the ingress >> nodes. > > So the concern is that even with congestion control, a single bad > actor can use more than their "fair" share of network resources. > > Sadly, this is already true on the web. > > No harm in writing down the potential. Are you looking for anything > more than that? No, I think the main thing is to have something to point at why congestion control is a MUST. Secondly, at least make people aware that this mechanism may give a malicious entity more potential for driving traffic load where they want to cause it than some of the previous mechanism, due to the ease of finding endpoint and keeping traffic more localized than in other DDoS attacks. But, sure it will more difficult to drive the targeted network into completely uselessness. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Feb 25 02:24: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 263CB1A0686 for ; Tue, 25 Feb 2014 02:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 hW5pwMzb6EAY for ; Tue, 25 Feb 2014 02:23:58 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE3C1A0682 for ; Tue, 25 Feb 2014 02:23:57 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-07-530c6f3cdd1c Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 46.05.04249.C3F6C035; Tue, 25 Feb 2014 11:23:56 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.2.347.0; Tue, 25 Feb 2014 11:23:55 +0100 Message-ID: <530C6F3C.1090709@ericsson.com> Date: Tue, 25 Feb 2014 11:23:56 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Harald Alvestrand , References: <530320F7.4090300@ericsson.com> <5303E578.3000207@alvestrand.no> <53046842.2010108@ericsson.com> <5304F3E0.1020206@alvestrand.no> In-Reply-To: <5304F3E0.1020206@alvestrand.no> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGfG3RtcmnyfY4OgOdYtjfV1sFmv/tbM7 MHlcmXCF1WPJkp9MAUxRXDYpqTmZZalF+nYJXBln77UyFpwUqPh68SRLA+Ne3i5GDg4JAROJ xjsGXYycQKaYxIV769m6GLk4hASOMErMPNPCDuEsZ5SYs3AlE0gVr4C2xJrJs8FsFgFViVdb djOC2GwCFhI3fzSygdiiAsESOw/8ZoSoF5Q4OfMJC4gtImAvcXHOSzBbWKBQ4siuHlaIBb2M Ej9ergRr4BTQlWh8e4sV4jpxiZ7GIJAws4CexJSrLYwQtrxE89bZzCC2ENA9DU0drBMYBWch WTcLScssJC0LGJlXMXIUpxYn5aYbGWxiBAblwS2/LXYwXv5rc4hRmoNFSZz341vnICGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2MBs+9/Gdl15QXBacaOW6o/sasfkus4OsOFembRv4bdTZ/ fPFFPm9PAnta7M5KZs8zLd8PZLz6u3KN1vLFTv5v10q5s9/58sXOUXP/u9YZ+g2O/76v+zPz uPaa9weaJysVsDJtclbVav7j/rnhvbGL6av7x0L/pGamiDT5GTwP2auVxvrSgLdGiaU4I9FQ i7moOBEA9+61qxgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0cTdfZXr8hal4q56T35U5L3uqbs Subject: Re: [rtcweb] Number of samples (ptime) to be supported by required codecs (draft-ietf-rtcweb-audio-05) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 10:24:00 -0000 On 2014-02-19 19:11, Harald Alvestrand wrote: > On 02/19/2014 09:16 AM, Magnus Westerlund wrote: >> On 2014-02-18 23:58, Harald Alvestrand wrote: >>> I may be a little simple-minded, but if we have a recommendation that >>> receivers MUST be able to receive all packetizations of G.711 and OPUS >>> up to 200 ms per packet, and that receivers should signal this by >>> sending "a=maxptime:200" in their SDP, what situations exist where >>> interoperability is not going to be achieved? >> Interoperability is going to be achieve in the direction towards this >> endpoint. The question is if we achieve interoperability in the >> direction from that endpoint. > > So, given that there is nothing in the G.711 specification about which > sample sizes a G.711 receiver has to support - the right approach seems > to be to amend the G.711 MIME registration with this information. Yes, it would for the future. But considering the wide-spread deployment of this payload format I don't see that having any short term effect on the interoperability. Also, the recommendations are actually context dependent. Thus, it is not obvious that a single recommendation is suitable. > > This is not a WebRTC issue; it is an absence of specification for the > non-WebRTC devices that use G.711. The RTCWEB specifications can > reasonably be expected to point to existing information about this > issue; it is not reasonable (in my mind) that the RTCWEB WG decide what > these values should be. > I would argue for this consideration based on that this is done in the WebRTC context, not any other context. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Feb 25 02:47: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 A52601A0696 for ; Tue, 25 Feb 2014 02:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, 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 3bY8ZMhZkYof for ; Tue, 25 Feb 2014 02:47:00 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB3F1A0682 for ; Tue, 25 Feb 2014 02:46:59 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-f5-530c74a10d31 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EB.93.10875.1A47C035; Tue, 25 Feb 2014 11:46:58 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.2.347.0; Tue, 25 Feb 2014 11:46:57 +0100 Message-ID: <530C74A1.3000203@ericsson.com> Date: Tue, 25 Feb 2014 11:46:57 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Harald Alvestrand , "rtcweb@ietf.org" , Harald Alvestrand References: <5304829E.20809@ericsson.com> <5304FC27.807@alvestrand.no> In-Reply-To: <5304FC27.807@alvestrand.no> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupiluLIzCtJLcpLzFFi42KZGfG3RndRCU+wwbrDLBbH+rrYLE7cOM1s sfZfO7sDs8eVCVdYPRZsKvVYsuQnUwBzFJdNSmpOZllqkb5dAlfGp3OL2Qr+J1YsXV/bwPjC t4uRk0NCwERi9pc7LBC2mMSFe+vZuhi5OIQEDjFKLHu5mhXCWc4ocWbJanaQKl4BbYl3k+cB dXBwsAioSny/bAsSZhOwkLj5o5ENxBYVCJbYeeA3I0S5oMTJmU/AykUEyiX+/JMHCQsLOEo8 eT0DrERIwE1iwcpOJhCbU0BTYvebuWwg5RIC4hI9jUEgYWYBPYkpV1sYIWx5ieats5khWrUl Gpo6WCcwCs5CsmwWkpZZSFoWMDKvYmTPTczMSS833MQIDM+DW37r7mA8dU7kEKM0B4uSOO+H t85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgbJFJl2KPufigzeB4/v1xjzpL6LfMfMSp2 K0ft2WW9ds6RVJnXqociD4g+NNvOFFOd/6NtsRjjGfZfkRNDSiI2KHMc7dX4Ms01abdwukmG 2v9vBfO118UmKco3Je5i3G/lEz0/8kxrxvukOaclzrxIfdidnvnHqcZ509eZVlO4aydsDJCJ Pq7EUpyRaKjFXFScCADeKf6sHQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vSABITBjqJ_r0RGYa3GJhRrVA8I Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 10:47:02 -0000 On 2014-02-19 19:47, Harald Alvestrand wrote: > On 02/19/2014 11:08 AM, Magnus Westerlund wrote: >> Hi, >> >> I have reviewed the Transports for RTCWEB >> (draft-ietf-rtcweb-transports-02) > Thanks! >> and have the following comments. >> >> 1. Section 1. >> >> This document focuses on the data >> transport protocos that are used by conforming implementations. >> >> Missing "l" in protocos. > Fixed. >> >> 2. Section 3.1: >> For both protocols, IPv4 and IPv6 support is assumed; applications >> MUST be able to utilize both IPv4 and IPv6 where available. >> >> What "applications" are intended in this sentence. I get a feeling that >> "applications" here could be replaced by "WebRTC implementations" > > Javascript applications. I think I should add the word "application" to > -overview's vocabulary; it is actually used in that meaning in that > document (also in the forms "Web application" and "browser-based > application". Sorry, then I find the above requirement a bit strangely targeted. I think we can require that IPv4 and IPv6 support for the applicable protocol pieces in what we define. But, on the JS application level? Also what explicit addressing information is visible on that level. It might be that this requirement needs to be split or at least apply to multiple levels. > >> >> >> 3. Section 3.1: >> For UDP, this specification assumes the ability to set the DSCP code >> point of the sockets opened on a per-packet basis, in order to >> achieve the prioritizations described in >> [I-D.dhesikan-tsvwg-rtcweb-qos] when multiple media types are >> multiplexed. It does not assume that the DSCP codepoints will be >> honored, and does assume that they may be zeroed or changed, since >> this is a local configuration issue. >> >> I wonder if this should be moved into 3.2 section instead. At least the >> part in 3.1 should focus on the DSCP setting part on the transport flow. >> The implications of it working or not should be moved to 3.2. A forward >> pointer to that second can be used instead. > > I think it fits better in 3.1 - this is about the assumptions that the > specifcation makes about the parts of the system that it is not a > specification for. I am fine with the first sentence staying, it is the second part that needs more discussion and I think it should be moved and expanded on. Thus a forward pointer may be appropriate here. > >> >> 4. Order of Section 3.2 and 3.3. >> >> I think the order should be swapped between 3.2. and 3.3. That way the >> Multiplexing section can provide definitions of all the stream concepts >> that exists in WebRTC and how they can be combined. More about this later. >> >> 5. Content of Section 3.2 >> >> This section needs to be expanded to start with a general discussion of >> how QoS can be applied to get a benefit. But, I think one need to be >> clear that it can't be assumed to be available in implementations or >> WebRTC based applications. > > I want to push back on this. It seems inappropriate that the RTCWEB QoS > specification start off with a tutorial on what QoS is and how one can > use it to gain a benefit. That material should be available elsewhere. > (Recommendations?) I would like to agree with you, however we are putting together the pieces in a way that stands some of the previous assumptions on their heads. Thus, we don't have easy access to pointers. I can see this discussion going into draft-ietf-avtcore-multiplex-guidelines when it concerns RTP. However, you also have the data channel to consider. Thus, there exist no references that I know that discusses this particular combination and its implications. > >> >> It needs to also discuss flow-based QoS mechanism. What are the >> implications if that is what is available and what choices does one have >> to address this by configuring the multiplexing different. > > I do not want to discuss material for which there are no references. > What particular flow-based mechanisms do you have in mind, and what are > the relevant references? RSVP we can start with, but I think equally applicable is 3GPP QoS. But finding the right reference here might be a bit problematic. I think one can cover the general property of flow based QoS in a single sentence. However, that usage has implications for the peer connection and its configuration. We have text in the rtp-usage that makes it clear about the requirement to be able to send multiple RTP sessions on different flows. But the combination with the data channel is not covered. Thus, I think that belongs in the transports document. The question is how much lead in material you need for that discussion? > >> I think this >> is the logical place to take the main discussion of that, as it can >> address both RTP streams and the data channel together. Please consider >> pointers to appropriate discussion in Section 12.1.3 in >> draft-ietf-rtcweb-rtp-usage. > > I do not think this document should repeat any material from rtp-usage, > but rtp-usage does not consider any aspect of QoS marking for multiple > streams using the same 5-tuple, nor does it say anything about > flow-based or DPI-based mechanisms apart from noting their existence. No, I am not talking about repeating. I am discussing the requirements on being able to separate the data channel on transport level (UDP) from the RTP sessions over their RTP, as well as being able to put them on common UDP flows. > > Agree that the multiplexing aspect should be discussed somewhere, but > I'm not sure where. >> >> I do note that writing this section appropriately is difficult until the >> content of draft-dhesikan-tsvwg-rtcweb-qos has firmed up. > > True. >> >> 6. Content of Section 3.3: >> >> I think this section should focus on making clear what different types >> of streams that exist in the WebRTC context, and what choices of >> multiplexing that are possible. Basically ensure that the full set of >> combinations are made clear. > > Isn't this material that really should be in > draft-ietf-avtcore-rtp-multi-stream or This is not appropriate place, this only discusses multiple SSRCs in the same RTP session. > draft-ietf-avtcore-multiplex-guidelines? This one definitely needs such discussion yes. Also draft-ietf-avtcore-multi-media-rtp-session has some parts of this, due to the potential for different needs based on media type. > > Again, this seems the wrong draft for having a discussion of those issues. However, adding the data channel into this, is something WebRTC specific, thus you are not getting away from dealing with it. >> >> A. All RTP packet streams and data channel over a single UDP flow. >> >> B. All RTP packet streams over one UDP flow and the data channel over >> another UDP flow. >> >> C. The RTP packet streams over different UDP flows based on content type >> and separate data channel. >> >> D. Each RTP packet stream over its own UDP flow (RTP session) and the >> data channel over its own UDP flow. >> >> The above with the additional dimension, that each RTP sessions, RTCP >> can be in its own UDP flow. >> >> There is also a question if the data channel can be aggregated with only >> one RTP session, where there are multiple ones configured. >> >> The QoS related discussion of this can be moved to the QoS section to >> keep that focused. >> >> However, the discussion of the pro and cons with having one or more flow >> is good and could even be expanded to list reasons such as legacy >> interop over a gateway. >> >> 7. Section 3.3: >> RTCWEB implementations MUST support the ability to send and receive >> multiple SSRCs on the same transport, and MUST support the ability to >> send and receive multiple SSRCs on multiple simultaneous transports, >> including the ability to send and receive audio and video on the same >> transport. >> >> I think this sentence is restating what is already required by Section >> 4.1 in draft-ietf-rtcweb-rtp-usage: If you want to enforce this, I >> suggest to do that by reference to that text rather than using RFC 2119 >> normative statements. > > Yes, rtp-usage contains these requirements. I can delete it from here. > Thanks! > > However, this removes the handle on which I hung the discussion of why > one would want to multiplex or not, which I inserted because you > requested it. This discussion also seems to be present in rtp-usage, so > it seems appropriate to delete that too. As I argue above, there is a need to take a full WebRTC level discussion of the multiplexing issues. I think the appropriate here is to try to ensure the AVTCORE documents contains the relevant pieces so you know what to reference and then try to put togheter a high level RTP + Data channel multiplexing considerations in this document. > >> >> >> 8. Section 3.4: >> ICE [RFC5245] MUST be supported. The implementation MUST be a full >> ICE implementation, not ICE-Lite. >> >> In order to deal with situations where both parties are behind NATs >> which perform endpoint-dependent mapping (as defined in [RFC5128] >> section 2.4), TURN [RFC5766] MUST be supported. >> >> These paragraph implies STUN and TURN server configuration. Should that >> configuration question be discussed with the appropriate pointers to the >> API? > This document has no pointers to the API at the moment, and I do not > want to add them - it's a layering violation of sorts. We can add > pointers to JSEP, which is kind of close to the API. > > But the main point seems to be that STUN and TURN servers MUST be > configurable, both from the browser setup and from the (JS) application. > I'm adding a sentence saying that. That is probably sufficient. > >> >> 9. Section 3.4: >> In order to deal with firewalls that block all UDP traffic, TURN >> using TCP between the client and the server MUST be supported, and >> TURN using TLS between the client and the server MUST be supported. >> See [RFC5766] section 2.1 for details. >> >> I think the following part: "TURN using TLS between" should be changed >> over "TURN using TLS over TCP between" to make it clear that this is >> using TLS/TCP rather than TLS/FOO. > Done. >> >> 10. Section 3.4: >> TURN TCP candidates [RFC6062] SHOULD be supported; this allows >> applications to achieve peer-to-peer communication when both parties >> are behind UDP-blocking firewalls using a single TURN server. (In >> this case, one can also achieve communication using two TURN servers >> that use TCP between the server and the client, and UDP between the >> TURN servers.) >> >> My understanding of RFC6062 is that it allows one to establish a vanilla >> TCP connection on the far side of the TURN server as well as connecting >> that one to an almost vanilla TCP connection (just a initial TURN >> ConnectionBind request) that A establish to the TURN server, i.e. >> WebRTC-A -(Turn/TCP)-> TURN_Server -(TCP)-> WebRTC-B. >> >> The end-result is that a relayed vanilla TCP connection is established >> between the WebRTC endpoints (A and B). As the WebRTC transport so far >> defined only works with datagrams, i.e. DTLS or RTP/RTCP packets they >> can't be sent natively over a TCP byte stream. Thus, if this mode of >> operation is to be supported a framing is required on this leg. >> >> A possibility here could be RFC 4571 if one want to go this way. > > I added a 4571 reference, and a note saying this is up for discussion. > If we frame RTP over TCP, we also have to decide what we do about the SCTP. Yes, I get the impression that the people arguing for the WebRTC over IP/TCP has not thought through the implications and I definitely like a discussion of this. Also, in which context are you wondering over SCTP in the above? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Feb 25 02:49: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 298B01A00DC for ; Tue, 25 Feb 2014 02:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 RTdolZJtZcUw for ; Tue, 25 Feb 2014 02:49:02 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAAA1A02DF for ; Tue, 25 Feb 2014 02:49:01 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-f5-530c751cabfe Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 98.BF.04853.C157C035; Tue, 25 Feb 2014 11:49:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 11:49:00 +0100 From: Christer Holmberg To: Michael Tuexen Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Some editorial comments on section 5 Thread-Index: Ac8nU+WsE4W5K/avTLyRu1AtQ1+x3gKnELsAAAk8zFA= Date: Tue, 25 Feb 2014 10:48:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1B89F8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D16D2A3@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.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvja5MKU+wwc3TGhYXm5YwWqz9187u wOSxZMlPJo8NLTuYApiiuGxSUnMyy1KL9O0SuDJm79vPVrBJqeLx2rlsDYzTpLsYOTkkBEwk /r86xwphi0lcuLeerYuRi0NI4ASjxMVtH1ggnCWMEqsmbAOq4uBgE7CQ6P6nDdIgImAqcXD5 PBYQm1lAXeLO4nPsILawQIHEyrsf2EHKRQQKJZ7MDoQot5Jo+XCQGcRmEVCV+Hz8JBOIzSvg K3G7ZQlYXEigg1Hi1342EJtTwFXi7IntYHFGoNu+n1rDBLFKXOLWk/lMEDcLSCzZc54ZwhaV ePn4H9QvihIfX+1jhKjXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDYLydhZSFpmIWmZhaRl ASPLKkbJ4tTi4tx0IwO93PTcEr3Uoszk4uL8PL3i1E2MwCg6uOW30Q7Gk3vsDzFKc7AoifNe Z60JEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC4KC+WJ/XEnqboN11WMoK1UxQ3vGwpLMgV +qAacHebkeE8deeEOQ5f5fkne77abxppseC7T7xmgcO5PXNXmigo+4mZciWuqLn5+bCOUfhk EZ2vouWqrXNSjvtdPb5WIuKL5NGgxqu7jnyv7511evHEnxpnm3/nfeSdPvWV1bNHX++rBYq5 JkxXYinOSDTUYi4qTgQA7q2aynACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6HQWJE6pwpzqQwdiRFz3Sa2L4Aw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Some editorial comments on section 5 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 10:49:04 -0000 Hi, >> Q1: >>=20 >> Section 5 says: >>=20 >> "SCTP as specified in [RFC4960] MUST be used in >> combination with the extension defined in [RFC3758] and provides the >> following interesting features for transporting non-media data >> between browsers:" >>=20 >> I suggest to say: >>=20 >> "The SCTP extension defined in [RFC3758] MUST be supported, and >> provides the following features: >> > But this implies that the listed features are provided by the extension d= efined in RFC 3758, which is not true. The features are provided by the com= bination of RFC 4960 and RFC 3758. Correct. My mistake. So, my suggestion would then be to remove "as specified in" and "interestin= g". "SCTP [RFC4960] MUST be used in combination with the extension defined in= [RFC3758] and=20 provides the following features for transporting non-media data between br= owsers:" The reference implicitly means "as specified in", in my opinon :) ---------- >> Q3: >>=20 >> Section 5 says: >>=20 >> "This value can be used to multiplex multiple protocols >> over a single SCTP association. The sender provides for each >> protocol a specific PPID and the receiver can demultiplex the >> messages based on the received PPID." >>=20 >> I think we discussed this earlier. The PPID value CAN NOT (at least not = as used by WebRTC) be used to multiplex multiple protocols=20 >> over a single SCTP association. If you create multiple channels, for mul= tiple protocols, the same PPID values may be used for each protocol. >>=20 >> The PPID CAN, however, be used within a data channel, e.g. to demultiple= x the DCP from channel data. > > I guess the problem is that I consider 'protocol' as something running on= top of SCTP like DCEP, Binary of String data, you consider 'protocol'=20 > as something running on top of Binary of String data and the 'protocol' b= eing identified in the JS protocol string. > > What about using: > > Each SCTP user message contains a Payload Protocol Identifier (PPID) t= hat is passed to SCTP by its upper layer on the sending side and provided t= o its upper layer on the receiving side. > The PPID can be used to multiplex/demultiplex multiple upper layers over = a single SCTP association. > In the WebRTP context, the PPID is used to distinguish between > UTF-8 encoded user data, binary encoded userdata and the Data Channel Est= ablishment Protocol defined in . > Please note that the PPID is not accessable via the Javascript API. > > Does this address your issue? Instead of talking about SCTP associations, could we talk about data channe= ls? I.e. the PPID can be used to multiplex/demultiplex multiple upper layer= s within a single data channel? Because, if you have multiple data channels on a single SCTP association, y= ou will use the stream IDs - not the PPIDs - to multiplex/demultiplex betw= een the channels. ---------- >> Q5: >>=20 >> Sometimes you say "SCTP" and sometimes "SCTP as defined in [RFC4960]". >>=20 >> I suggest to e.g. use the reference on the first occurrence, and then on= ly use "SCTP". > > I double checked: > SCTP as defined in [RFC4960] is used in > * In the Introduction (first occurrence) talking about SCTP / UDP > * In the Introduction to make sure which specifications are used: RFC 496= 0 and RFC 3758 In the 2nd paragraph of the Introduction, the text says: "SCTP as specified in [RFC4960] with the partial reliability extension def= ined in [RFC3758]" Could you remove "as specified in", and say? "SCTP [RFC4960] with the partial reliability extension defined in [RFC3758= ]" > * In section 5 when used with RFC 2119 language. I still think you could remove "as specified in", and say: "SCTP [RFC4960] MUST be used in combination with the extension defined..." > * In section 6 to make clear what relates to RFC 4960 and what to the NDA= TA extension. > > All of these are intentional. Which one do you think is not necessary? In section 6.6, I think you could remove "specified in", and say: "The SCTP base protocol [RFC4960]..." I am not religious about these things, but again: in my opinion adding the = reference means "as specified in", and makes the text easier to read :) Regards, Christer From nobody Tue Feb 25 02:58: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 5DA061A01B0 for ; Tue, 25 Feb 2014 02:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_82=0.6, 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 G_JaoBjk9RQ3 for ; Tue, 25 Feb 2014 02:58:47 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 49AFD1A03F9 for ; Tue, 25 Feb 2014 02:58:47 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-2a-530c77659d78 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B5.ED.23809.5677C035; Tue, 25 Feb 2014 11:58:45 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.2.347.0; Tue, 25 Feb 2014 11:58:43 +0100 Message-ID: <530C7763.1030105@ericsson.com> Date: Tue, 25 Feb 2014 11:58:43 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Barry Dingle References: <53077E7B.1070900@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+JvjW5qOU+wwYYVohaP79taXJ2xhNli 7b92dgdmj52z7rJ7LFnyk8njy+XPbAHMUVw2Kak5mWWpRfp2CVwZr2fuYClYJFjR/7eVpYHx DW8XIyeHhICJxLwF35ghbDGJC/fWs3UxcnEICRxilGiZdhTKWc4ocWfOPzaQKl4BbYm3q+Yy gdgsAqoSx2++ZgGx2QQsJG7+aASrERUIlth54DcjRL2gxMmZT8BqRIDq982eDNbLLBAl8fHu BaB6Dg5hAWeJ6bfNQMJCAgUSSz98ASvnFAiU2N+wGKxEQkBcoqcxCKJTU6J1+292CFteonnr bGaIVm2JhqYO1gmMQrOQLJ6FpGUWkpYFjMyrGNlzEzNz0suNNjECQ/fglt+qOxjvnBM5xCjN waIkzvvhrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbNf3f4wz+Y9d5snNeu86vU4ErK 8VP605z/uayZFsRx5YSwU8ur5Ws07qibu/+JlalijBH5fnfvWx4eSzetrR927FQsc+f5ufWW seyqlnOuvT03Tqo/VmvceH3pi+U1ss0ckxce3R/6MaXnzBHbh66ZxRVbJynk5IR52jHErzh8 26tKrlP41nElluKMREMt5qLiRADQeDKQKwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nuBWRuxVdrLouWNlepBr9-0g9Eg Cc: "rtcweb@ietf.org" , draft-ietf-rtcweb-data-channel@tools.ietf.org Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 10:58:49 -0000 On 2014-02-23 10:54, Barry Dingle wrote: > In reference to your first _Section 1 comments_, I agree that we need to > clearly differentiate the SRTP media and the SCTP media. (Note - SRTP - > not RTP !) So SRTP is an extension of RTP, in fact it is a profile, or rather two (RTP/SAVP or RTP/SAVPF). I wrote RTP because I meant no specific RTP configuration here, it can be any of the profiles and any of the extensions. I know and fully support that RTCWEB uses RTP/SAVPF for RTP transported media, however in the wider context and possible other usage of the defined mechanism this may or may not be true. Therefore I see a need to be generic in that discussion. If one want to emphasize the SRTP part, then use (S)RTP. > > I agree that there could be real-time media that can be sent over SCTP > Channels are still meet the criteria for 'real-time' as being 'received > within a few hundred milliseconds of being generated' - see WebRTC > Overview section 2.4. > > Maybe we need to differentiate the Channel types - and then refer to the > data going over those Channels. For instance,if we define "SRTP > Channels" and "SCTP Channels", we could then refer to 'SRTP Channel > media' which would have a specific meaning. Well, around RTP we aren't discussing "channels" at all. Thus, this becomes very ambiguous to what it means, unless you have a definition to go along with it. In the context of a PeerConnection we can have one or more RTP session. Also, I don't know what an SCTP channel is. There is an SCTP association, which is something between two endpoints. On top of this we have the SCTP Data channels. So what are you missing or want from these definitions? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Feb 25 04:48: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 7E6A21A036B; Tue, 25 Feb 2014 04:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.347 X-Spam-Level: X-Spam-Status: No, score=-7.347 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 1Bg25urGegp4; Tue, 25 Feb 2014 04:48:10 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 88A951A0644; Tue, 25 Feb 2014 04:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=59466; q=dns/txt; s=iport; t=1393332489; x=1394542089; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6MaWeVYEzJZU58qV9Wlpm2A6POSpXkA2UwOH37G5ztg=; b=dSeYD78HMfqm+66GuwnReEOIHMAp1yNfnRrqjTs1VDsH6Ke0KyXXQVma Xx8sjWoyv+6Y8u3KxoHQFyp61u7higPLiakBMzclZXi8tNNq8SXD1eJt2 KgXUnvb3PpWqQlqQftF/ErPFs3S+lhgBM+XXcaa64senIHyUyElyuesIw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsGAKKPDFOtJV2Y/2dsb2JhbABWA4JCRDtXq0CNOIgJT4EYFnSCJQEBAQQBAQEXA0oHCxACAQgRBAEBIQEGByEGCxQJCAIECgQFCRKHVgMRDb9IDYZxF4xPgUQBAS0SDAQGAQYLgxOBFASWR4FtgTKLLoVHgy2BcTk X-IronPort-AV: E=Sophos; i="4.97,540,1389744000"; d="scan'208,217"; a="22998448" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 25 Feb 2014 12:48:07 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1PCm6An000445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 12:48:07 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 06:48:06 -0600 From: "Pal Martinsen (palmarti)" To: Karl Stahl Thread-Topic: [tram] [rtcweb] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Thread-Index: AQHPMa7rPKSdbWG+c0KNNHF0bIvNNJrGUOCA Date: Tue, 25 Feb 2014 12:48:06 +0000 Message-ID: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ee01cf31ae$e296d500$a7c47f00$@stahl@intertex.se> In-Reply-To: <04ee01cf31ae$e296d500$a7c47f00$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.100.226] Content-Type: multipart/alternative; boundary="_000_B788D545BDC047A7BE1B76E2A5F60509ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ATxlr8lkkp-DcX2EpY0eA2bZ3DE Cc: Oleg Moskalenko , "rtcweb@ietf.org" , "tram@ietf.org" , "Yoakum, John H \(John\)" Subject: Re: [rtcweb] [tram] I-D Action: draft-thomson-tram-turn-bandwidth-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, 25 Feb 2014 12:48:14 -0000 --_000_B788D545BDC047A7BE1B76E2A5F60509ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 24 Feb 2014, at 23:22 pm, Karl Stahl > wrote: Hi P=E5l, You did not comment nor answer, in response to any of: http://www.ietf.org/mail-archive/web/tram/current/msg00275.html http://www.ietf.org/mail-archive/web/tram/current/msg00273.html Sorry about that. I did not notice any clear items to answer or comment on. whether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the appli= cation/browser to transfer relevant real-time traffic information (types an= d bandwidth) into every RTP package by using the already IETF standardized = RTP extension header RCF 5285, which could be used by any current or future= Internet (including OTT) network where WebRTC real-time traffic may flow. = It seems to have been standardized already 2008 to allow such usage. draft-martinsen-tram-discuss is intended to solve internal application stre= am prioritisation pr flow, i.e. it is more important for me to get the vide= o stream across than my application stream at this moment in time. Its inte= ntion is to describe the 5-topple the STUN message was sent on. Moving to a pr packet prioritisation is interesting as it can solve the bun= dle problem, and mark the relative importance of specific video frames (I-F= rames for example). Since its pr packet the network element might not keep = stream state so it might be easier that way. But the information needs to b= e in a fixed offset for quick network element processing. And we want to de= scribe other streams than just RTP. That makes RTP header extensions unsuit= able. QoS related step C) draft-martinsen-tram-discuss can then be taken out of T= RAM, and step D) (that was never intended to be handled by TRAM anyway) wil= l be handled elsewhere. I was hoping to argue that the draft is only new signalling of old concepts= (DSCP and ECN). In the end it is the WG that decides if there is enough in= terest. I have repeated my suggestion to RTCWEB WG from the October discussions on = the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-arch= ive/web/rtcweb/current/msg09129.html to introduce the QoS related step D) i= nto draft-ietf-rtcweb-rtp-usage suggesting usage of RFC 5285, where traffic= information in RTP packets simply would be filled by any browser under any= OS. Without step B), TRAM =93Enforcing the real-time traffic through the offere= d/discovered TURN servers=94, the real-time traffic may happen through the = IP default gateways often congested by data traffic and QoS insensitive str= eaming video and file sharing. Without specific QoS methods at those points= , the network raw bandwidth capacity may have to be 10-folded to achieve su= fficient QoE when WebRTC usage becomes popular. Methods like DISCUSS addres= ses such things occurring when STUN instead TURN is used (by allowing flows= into such congestion points), but only provides direct traffic info for ou= tgoing (not incoming) real-time traffic and locally, therefore are not even= applicable to reservation type of networks like Cable Networks and Mobile = OTT. If both clients supports draft-martinsen-tram-discuss you would get an bi-d= irectional end to end description of the flow that works through NAT. The information in the STUN packet can be used to remark DSCP bits to whate= ver values that is of best use for the network the packet is flowing though= . I dont see how TURN gives that ability. Once the channel is bound you only = have a channel number in front of the UDP payload. And TURN is designed to = carry alls sort of traffic. For this to work there must be some sort of onl= y webRTC traffic is allowed through this TURN server. (And Ill bet bitorren= t or others find a way to mimic webRTC to set up only a data channel..) That would leave certain network types to investing in raw bandwidth increa= se, instead of simply borrowing the bandwidth (from much larger data traffi= c and QoS insensitive streaming video and file sharing at no adverse effect= ) and making that borrowed no-cost bandwidth very valuable for the carriers= when delivering to their customers. I know a few of you Cisco guys are among the ones that have been fighting a= gainst the general =93it is all about bandwidth=94 and =93it will go away w= ith time=94-attitude within IETF work, e.g. see http://www.ietf.org/mail-ar= chive/web/rtcweb/current/msg09031.html, but the pointers given in the curre= nt QoS discussion within TRAM: (i) will *not allow* ISP=92s to use already available and currently deploya= ble quality IP pipes for real-time traffic to also be used for WebRTC gener= ated real-time traffic. (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OT= T) to borrow bandwidth from data traffic and QoS insensitive streaming vide= o and file sharing. All networks will *also be inhibited* from the very com= mon and used method of simply providing an extra IP pipe (often provided ov= er the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) Newer, fiber only type of networks, can still borrow bandwidth at no extra = cost, *by proprietary usage* of RFC 5285 by browsers. (iii) will leave most ISPs to *only use* raw bandwidth capacity increase th= at may has to be 10-folded to reach sufficient QoE when WebRTC usage become= s popular (if at all possible, since unmanaged IP pipes intermittently are = filled, whatever bandwidth is available). Further explainations about QoS methods and their implementation were given= a few days ago in: http://www.ietf.org/mail-archive/web/tram/current/msg00274.html (i), (ii) and (iii) will *seriously delay* usage of telepresence capable an= d quality demanding WebRTC (bandwidth being around 30 times higher over bes= t effort Internet, than telephony over quality managed networks) and will *= vastly increase cost* for ISPs to offer WebRTC with good QoE. Below you are giving pointers saying =93They are currently working on a pro= blem-statement draft and a use-case draft, any input to those would be very= helpful.=94 Those are unnecessary, risking leading to (i), (ii) and (iii) = above. We find them quite useful. It allows us to engage with potential users and = see if there are real problems to solve. If the customer/users do not see a= problem there is little incentive for us to invest in creating a solution = that nobody wants. That said, it is always the danger of crating a to compl= icated solution that solves to many problems. So are pointers such as: =93RMCAT where congestion avoidance for RTP is bei= ng developed=94. TRAMs Milestone 3 is for the purpose of directing real-tim= e traffic where congestion control isn=92t already in place. UsingRFC 5285 = available since 2008, to fill traffic information in RTP packets (step D)) = is probably a necessity for most future =93congestion control=94 discussed. There are some good example of RTP header extension usage. For example draf= t-avtext-berger-framemarking. But that information may very well be encrypt= ed and unavailable to the network element. .-. P=E5l-Erik This chicken-and-egg circular also applies to RTCWEB direction of QoS issue= s to: http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos focusing on DSCP-mapping without even mentioning RFC 5285 available since 2= 008, to fill traffic information in RTP packets where it is a necessity an= d will allow: (1) applications to directly convey QoS related real-time traffic info to t= he network at points where RTP flow is directed to by TRAM Milstone 3, to b= e used by *any network element implementing any suitable QoS methods for th= e particular network* for (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), under= *all* OSs, and *all* current and future IP networks (3) *without* having to be forced into application specific networks (PSTN,= IMS) instead of using the Internet (including OTT). The only activity required, is to call for ISPs=92 review whether the traff= ic information transferred by RFC 5285 is sufficient for current and future= needs in their network as suggested in http://www.ietf.org/mail-archive/we= b/rtcweb/current/msg09129.html =85two parameters (e.g. two bytes each) are encoded into the RTP header ext= ension: A) The maximum bandwidth requirement: Two bytes could contain everything fr= om some bps for real-time text to Gbps for future 3D supersize telepresence= =85 on a logarithmic scale. B) The quality characteristics for the stream, with the highest bit set to = 1, we could allocate a bit each for quality type e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensit= ive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X,= Variation Y, that could be combined as required to describe the stream. And with highest bit set to 0, there could instead be a number for special = usage that does not fit the general description of the individual bits. Then this could be assigned numbers to have the RFC in place. With TRAM milestone 3 also place, market forces will drive ISPs and browser makers to implement just that, wi= thout even having it MUST-established. =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari comes w= ith much better QoE?=94 and vice versa. l Please see further emails soon following this one, for details and history. /Karl Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Pal Martinsen (palmarti) Skickat: den 21 februari 2014 10:37 Till: tram@ietf.org Kopia: Karl Stahl; Oleg Moskalenko; Alan Johnston; Yoakum, John H (John) =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Hi, I agree the full QoS discussion should _not_ happen in TRAM. If you are int= erested in helping out in that area I suggest you looking into the AEON mai= ling list at: https://www.ietf.org/mailman/listinfo/aeon . They are current= ly working on a problem-statement draft and a use-case draft, any input to = those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-u= se-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-= 00). That said, STUN have a few nice characteristics that makes it a perfect can= didate for transporting some of the QoS information. IMHO that would be ex= tending the STUN spec and should be within the TRAM charter. The main goal= of draft-martinsen-tram-discuss was to show how already existing QoS mecha= nisms could be transported with STUN to provide more value, and to start th= e discussion if TRAM is the appropriate place to have those on the wire for= mat discussions. .-. P=E5l-Erik On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) > wrote: +1 I fully agree with the comments that QOS should be a low priority for the i= nitial focus of the TRAM efforts. There are other groups doing QOS work an= d frankly I engage in WebRTC multimedia interactions daily over the Interne= t, enterprise VPNs, and various combinations and seldom suffer egregious qu= ality issues. I am more concerned about carriers doing things to regulate = or degrade WebRTC flows than a failure of existing Internet mechanisms to e= nable them. Significant focus on QOS before we better enable TURN to be easily used in = a browser environment taking advantage or normal web characteristics (as op= posed to historic telephony constructs) would seem to be highly distracting= at this point. Cheers, John AVAYA 1.919.425.8446 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 12:43 PM To: Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.t= xt On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston > wrote: Personally, I am not sure how much QoS is actually in scope for TRAM. Have = you been following RMCAT where congestion avoidance for RTP is being develo= ped? I see some overlap in your goals and the goals of that work. - I'd concentrate on the TURN application-level functionality, for now, and I= 'd leave QoS for the future discussions. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_B788D545BDC047A7BE1B76E2A5F60509ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 24 Feb 2014, at 23:22 pm, Karl Stahl <karl.stahl@intertex.se> wrote:


Sorry about that. I did not notice any clear items to answer or commen= t on. 

whether step D) can obsolete step C) (DISCUSS/MALICE) by = allowing the application/browser to transfer relevant real-time traffic inf= ormation (types and bandwidth) into every RTP package by using the already IETF standardized RTP extension hea= der RCF 5285, which could be used by any current or future Internet (includ= ing OTT) network where WebRTC real-time traffic may flow. It seems to have = been standardized already 2008 to allow such usage.
 
draft-martinsen-tram-discuss is intended to solve internal application= stream prioritisation pr flow, i.e. it is more important for me to get the= video stream across than my application stream at this moment in time. Its= intention is to describe the 5-topple the STUN message was sent on. 

Moving to a pr packet prioritisation is interesting as it can solve th= e bundle problem, and mark the relative importance of specific video frames= (I-Frames for example). Since its pr packet the network element might not = keep stream state so it might be easier that way. But the information needs to be in a fixed offset for qui= ck network element processing. And we want to describe other streams than j= ust RTP. That makes RTP header extensions unsuitable. 

QoS related step C)=  draft-martinsen-tram-discuss can then be taken out of TRAM, and step D) (that was never intended to be hand= led by TRAM anyway) will be handled elsewhere.

I was hoping to argue that the draft is only new signalling of old con= cepts (DSCP and ECN). In the end it is the WG that decides if there is enou= gh interest. 

 
I have repeated my suggestion to RTCWEB WG from the Octob= er discussions on the relevant <= /span>[rtcweb] [avtext] [mmusic]&nb= sp;lists http://www.ietf.org/mail-a= rchive/web/rtcweb/current/msg09129.html to introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage suggesting usage of RFC 5285, where traffic information in RTP packets simply would be filled by a= ny browser under any OS.
 
Without step B), TRAM =93Enforci= ng the real-time traffic through the offered/discovered TURN servers=94, the = real-time traffic may happen through the IP default gateways often congeste= d by data traffic and QoS insensitive streaming video and file sharing. Wit= hout specific QoS methods at those points, the network raw bandwidth capacity may have to be 10-folded to ach= ieve sufficient QoE when WebRTC usage becomes popular. Methods like DISCUSS= addresses such things occurring when STUN instead TURN is used (by allowin= g flows into such congestion points), but only provides direct traffic info for outgoing (not incoming) real-tim= e traffic and locally, therefore are not even applicable to reservation typ= e of networks like Cable Networks and Mobile OTT.

If both clients supports draft-martinsen-tram-discuss you would get an= bi-directional end to end description of the flow that works through NAT.<= /div>
The information in the STUN packet can be used to remark DSCP bits to = whatever values that is of best use for the network the packet is flowing t= hough.

I dont see how TURN gives that ability. Once the channel is bound you = only have a channel number in front of the UDP payload. And TURN is designe= d to carry alls sort of traffic. For this to work there must be some sort o= f only webRTC traffic is allowed through this TURN server. (And Ill bet bitorrent or others find a way to m= imic webRTC to set up only a data channel..)

 
That would leave certain network types to investing in ra= w bandwidth increase, instead of simply borrowing the bandwidth (from much = larger data traffic and QoS insensitive streaming video and file sharing at no adverse effect) and making that bor= rowed no-cost bandwidth very valuable for the carriers when delivering to t= heir customers.
I know a few of you Cisco guys are among the ones that ha= ve been fighting against the general =93it is all about bandwidth=94 and = =93it will go away with time=94-attitude within IETF work, e.g. see http://www.ietf.org/mai= l-archive/web/rtcweb/current/msg09031.html, but the pointers given in the current QoS discussion within TRAM:
 
(i) will *not allow* ISP=92s to use already availa= ble and currently deployable quality IP pipes for real-time traffic to also= be used for WebRTC generated real-time traffic.
 
(ii) will *not allow* some network types (e.g. Cab= le Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS i= nsensitive streaming video and file sharing. All networks will *also be inhibited* from the very common= and used method of simply providing an extra IP pipe (often provided over = the same wire but level-2 separated) dedicated for real-time usage
(*by resisting TRAM implementation of step B*)
Newer, fiber only type of networks, can still borrow band= width at no extra cost, *by proprietary usage* of RFC 5285 by browse= rs.
 
(iii) will leave most ISPs to *only use* raw bandw= idth capacity increase that may has to be 10-folded to reach sufficient QoE= when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes intermittently are filled, whate= ver bandwidth is available).
 
Further explainations about QoS methods and their impleme= ntation were given a few days ago in:
 
(i), (ii) and (iii) will *seriously delay* usage o= f telepresence capable and quality demanding WebRTC (bandwidth being around= 30 times higher over best effort Internet, than telephony over quality managed networks) and will *vastly increase= cost* for ISPs to offer WebRTC with good QoE.
 
Below you are giving pointers saying =93They are currently working on a problem-statement draft and a us= e-case draft, any input to those would be very helpful.=94 Those are unnecessary, risking l= eading to (i), (ii) and (iii) above.
 
We find them quite useful. It allows us to engage with potential users= and see if there are real problems to solve. If the customer/users do not = see a problem there is little incentive for us to invest in creating a solu= tion that nobody wants. That said, it is always the danger of crating a to complicated solution that solves t= o many problems.  

So are pointers such as: =93R= MCAT where congestion avoidance for RTP is being developed=94. TRAMs Milestone 3 is for the purpose of directing real-time traffic where = congestion control isn=92t already in place. Using= RFC 5285 available since 2008, to fill traffic information in RTP packets (step D)) is probably a necessity for m= ost future =93congestion control=94 discussed.
 
There are some good example of RTP header extension usage. For example=  draft-avtext-berger-framemarking. But that information may very well = be encrypted and unavailable to the network element.


.-.
P=E5l-Erik







This chicken-and-egg circular also applies to RTCWEB dire= ction of QoS issues to:
focusing on DSCP-mapping without even mentioning RFC 5285= available since 2008, to fill traffic information in RTP packets where it =  is a necessity and will allow:
(1) applications to directly convey QoS related real-time= traffic info to the network at points where RTP flow is directed to by TRA= M Milstone 3, to be used by *any network element implementing any suitable QoS methods for the particular n= etwork* for
(2) *all* WebRTC browsers *and* dedicated c= lients (not using WebRTC), under *all* OSs, and *all* current= and future IP networks
(3) *without*&nb= sp;having to be forced into application specific networks (PSTN, IMS) instead of using = the Internet (including OTT).
 
The only activity required, is to call for ISPs=92 review= whether the traffic information transferred by RFC 5285 is sufficient for = current and future needs in their network as suggested in http://www.ietf.org/mail-a= rchive/web/rtcweb/current/msg09129.html
<snip>
=85two parameters (e.g. two bytes each) are encoded into the RTP heade= r extension:
 
A) The maximum bandwidth requirement: Two bytes could contain everythi= ng from some bps for real-time text to Gbps for future 3D supersize telepre= sence=85 on a logarithmic scale.
 
B) The quality characteristics for the stream, with the highest bit se= t to 1, we could allocate a bit each for quality type e.g:
Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Ins= ensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioriti= ze X, Variation Y, that could be combined as required to describe the stream.
 
And with highest bit set to 0, there could instead be a number for spe= cial usage that does not fit the general description of the individual bits= .
</snip>
 
Then this could be assigned numbers to have the RFC in pl= ace.
With TRAM milestone 3 also place,
market forces will drive ISPs and browser makers to imple= ment just that, without even having it MUST-established.<= /div>
=93Who does not want a =93WebRTC-Ready=94 Internet access= ?=94 and
=93Who wants to use Chrome, if Firefox, Internet Explorer= or Safari comes with much better QoE?=94 and vice versa.=
 l
Please see further emails soon following this one, for de= tails and history.
 
/Karl
 
Fr=E5n= : tram [mailto:tram-bounces@ietf.org]=  F=F6r Pal Martinsen (palmarti)
Skickat: den 21 fe= bruari 2014 10:37
Till: tram@ietf.org
Kopia: Karl Stahl;= Oleg Moskalenko; Alan Johnston; Yoakum, John H (John)
=C4mne: Re: [tram]= I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
 
Hi,
 
I agree the full QoS discussion should _not_ happen in TRAM. If you are int= erested in helping out in that area I suggest you looking into the AEON mai= ling list at: https://www.ietf.org/ma= ilman/listinfo/aeon . They are currently working on a problem-statement draft and a use-case dra= ft, any input to those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01= , http://to= ols.ietf.org/html/draft-eckel-aeon-problem-statement-00).
 
That said, STUN have a few nice characteristics that makes it a perfect can= didate for transporting some of the QoS information.  IMHO that would = be extending the STUN spec and should be within the TRAM charter.  The= main goal of draft-martinsen-tram-discuss was to show how already existing QoS mechanisms could be transported with = STUN to provide more value, and to start the discussion if TRAM is the appr= opriate place to have those on the wire format discussions.
 
.-.
P=E5l-Erik
 
 
 
 
 
 
On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) <yoakum= @avaya.com> wrote:


+1
I fully agree with the comments that QOS sh= ould be a low priority for the initial focus of the TRAM efforts.  The= re are other groups doing QOS work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterp= rise VPNs, and various combinations and seldom suffer egregious quality iss= ues.  I am more concerned about carriers doing things to regulate or d= egrade WebRTC flows than a failure of existing Internet mechanisms to enable them.
 
Significant focus on QOS before we better e= nable TURN to be easily used in a browser environment taking advantage or n= ormal web characteristics (as opposed to historic telephony constructs) would seem to be highly distracting at t= his point.
 
 
Cheers,
John=
 
AVAYA
1.919.425.8446
 
From:&nbs= p;tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Thursday, Fe= bruary 20, 2014 12:43 PM
To: Alan Johnston<= br> Cc: Karl Stahl; tram@ietf.org
Subject: Re: [tram= ] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
 
 

 

 
 
 
Personally, I am not sure how much QoS is actually in = scope for TRAM. Have you been following RMCAT where congestion avoidance fo= r RTP is being developed?  I see some overlap in your goals and the go= als of that work.
-
 
 

I'd concentrate on the TURN application-level function= ality, for now, and I'd leave QoS for the future discussions.


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

--_000_B788D545BDC047A7BE1B76E2A5F60509ciscocom_-- From nobody Tue Feb 25 04:55: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 AF1D71A06DB for ; Tue, 25 Feb 2014 04:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_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_82=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 r2Wcf3fM9Eke for ; Tue, 25 Feb 2014 04:55:37 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5661A03F2 for ; Tue, 25 Feb 2014 04:55:37 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hm4so4427068wib.2 for ; Tue, 25 Feb 2014 04:55:36 -0800 (PST) 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=6SSABJY1sNIWaaExGKspBdO3E/EybO7pt+4jla2iRho=; b=NNc4MV05iBYs2ices5vl0rTEnMyMjQ0fpBQtL+XALx/nnbah25U3O18tvgOecBjq6b 1fFun4vfbHewLRFfetDW9AKEUDX40dIPkx6V3EhONLSVAtWxLp6+tdxTsVKvi0ncUZhF 5M5pCWeVC5J8RoqK2VT+Yr1Cih/woFFDQRrpfrLci0zr/OLpSeOIEaMkYBYvjEjN2oV9 6QX/Ayn//ofAK9+fdkwwF6lQKCpZUsMz/04CkvIoTg2hyjdyv1m4fMGJCfISH1n3zpjt /x97hhx+FHrxDNI6y6aL+/04JMlpBqrub/k4hfLZ9xirJ2sJ17DrphNAst9Yu+VSN+cM HhsA== X-Received: by 10.194.109.68 with SMTP id hq4mr24789579wjb.12.1393332935623; Tue, 25 Feb 2014 04:55:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.87.165 with HTTP; Tue, 25 Feb 2014 04:55:15 -0800 (PST) In-Reply-To: <530C7763.1030105@ericsson.com> References: <53077E7B.1070900@ericsson.com> <530C7763.1030105@ericsson.com> From: Barry Dingle Date: Tue, 25 Feb 2014 23:55:15 +1100 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=089e0102e6daae89c704f33a9a98 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/d1hjVfaDq8DydfyKGiGjR55LoVc Cc: "rtcweb@ietf.org" , draft-ietf-rtcweb-data-channel@tools.ietf.org Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 12:55:39 -0000 --089e0102e6daae89c704f33a9a98 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 25, 2014 at 9:58 PM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-02-23 10:54, Barry Dingle wrote: > > In reference to your first _Section 1 comments_, I agree that we need t= o > > clearly differentiate the SRTP media and the SCTP media. (Note - SRTP - > > not RTP !) > > So SRTP is an extension of RTP, in fact it is a profile, or rather two > (RTP/SAVP or RTP/SAVPF). I wrote RTP because I meant no specific RTP > configuration here, it can be any of the profiles and any of the > extensions. I know and fully support that RTCWEB uses RTP/SAVPF for RTP > transported media, however in the wider context and possible other usage > of the defined mechanism this may or may not be true. Therefore I see a > need to be generic in that discussion. If one want to emphasize the SRTP > part, then use (S)RTP. > > I see your point about being generic - and it is consistent with draft-ietf-rtcweb-rtp-usage. > > > I agree that there could be real-time media that can be sent over SCTP > > Channels are still meet the criteria for 'real-time' as being 'received > > within a few hundred milliseconds of being generated' - see WebRTC > > Overview section 2.4. > > > > Maybe we need to differentiate the Channel types - and then refer to th= e > > data going over those Channels. For instance,if we define "SRTP > > Channels" and "SCTP Channels", we could then refer to 'SRTP Channel > > media' which would have a specific meaning. > > Well, around RTP we aren't discussing "channels" at all. Thus, this > becomes very ambiguous to what it means, unless you have a definition to > go along with it. > > In the context of a PeerConnection we can have one or more RTP session. > > Also, I don't know what an SCTP channel is. There is an SCTP > association, which is something between two endpoints. On top of this we > have the SCTP Data channels. So what are you missing or want from these > definitions? > > I was trying to find a way to identify (a) 'all the SCTP Streams' (or maybe "all the SCTP Channels") as well as (b) "all the (S)RTP Streams". As you suggested, the term "SCTP Association" seems to work for (a). Does "RTP Session" work for (b) ?? Cheers, /Barry Dingle > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --089e0102e6daae89c704f33a9a98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 25, 2014 at 9:58 PM, Magnus Westerlund &l= t;magnu= s.westerlund@ericsson.com> wrote:
On 2014-02-23 10:54, Barr= y Dingle wrote:
> In reference to your first _Section 1 comments_, I agree that we need = to
> clearly differentiate the SRTP media and the SCTP media. (Note - = SRTP -
> not RTP !)

So SRTP is an extension of RTP, in fact it is a profile, or rather tw= o
(RTP/SAVP or RTP/SAVPF). I wrote RTP because I meant no specific RTP
configuration here, it can be any of the profiles and any of the
extensions. I know and fully support that RTCWEB uses RTP/SAVPF for RTP
transported media, however in the wider context and possible other usage of the defined mechanism this may or may not be true. Therefore I see a
need to be generic in that discussion. If one want to emphasize the SRTP part, then use (S)RTP.

I see your point about being generic - and= it is consistent with draft-ietf-rtcweb-rtp-usage.


>
> I agree that there could be real-time media that can be sent over SCTP=
> Channels are still meet the criteria for 'real-time' as being = 'received
> within a few hundred milliseconds of being generated' - see WebRTC=
> Overview section 2.4.
>
> Maybe we need to differentiate the Channel types - and then refer to t= he
> data going over those Channels. For instance,if we define "SRTP > Channels" and "SCTP Channels", we could then refer to &= #39;SRTP Channel
> media' which would have a specific meaning.

Well, around RTP we aren't discussing "channels" at all= . Thus, this
becomes very ambiguous to what it means, unless you have a definition to go along with it.

In the context of a PeerConnection we can have one or more RTP session.

Also, I don't know what an SCTP channel is. There is an SCTP
association, which is something between two endpoints. On top of this we have the SCTP Data channels. So what are you missing or want from these
definitions?

I was trying to find a way to i= dentify
(a) 'all the SCTP Streams' (or maybe "all the SCTP= Channels") as well as
(b) "all the (S)RTP Streams".

As you suggested, the term "SCTP Association" seem= s to work for (a). Does "RTP Session" work for (b) ??

Cheers,
/Barry Dingle

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Phone= =C2=A0+46 10 7148287
F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--089e0102e6daae89c704f33a9a98-- From nobody Tue Feb 25 06:17: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 688DD1A045D; Tue, 25 Feb 2014 06:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 1GfnjjMgq80V; Tue, 25 Feb 2014 06:17:15 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACAB1A06EB; Tue, 25 Feb 2014 06:17:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,540,1389772800"; d="asc'?scan'208";a="145318948" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 25 Feb 2014 06:17:12 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.211]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 06:17:13 -0800 From: "Eggert, Lars" To: "saag@ietf.org" , "rmcat@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [irsg] Final agenda for the IRTF Open Meeting at IETF-89 Thread-Index: AQHPMjHEOa1omgdxKEScYanJgU4jJg== Date: Tue, 25 Feb 2014 14:17:11 +0000 Message-ID: References: <4FF88464-9C2F-453F-A157-188D291BC564@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.18] Content-Type: multipart/signed; boundary="Apple-Mail=_27FD192F-14B9-414B-89C6-0F47D07DCD8A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/H-biV-J7bpn7XIv8tUBNFD9d95Q Subject: [rtcweb] Fwd: [irsg] Final agenda for the IRTF Open Meeting at IETF-89 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 14:17:17 -0000 --Apple-Mail=_27FD192F-14B9-414B-89C6-0F47D07DCD8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The two ANRP award talks may be of interest to folks on this list. Begin forwarded message: > From: "Eggert, Lars" > Subject: [irsg] Final agenda for the IRTF Open Meeting at IETF-89 > Date: February 25, 2014 at 14:59:14 GMT+1 > To: "irtf-discuss@irtf.org" , = "irtf-announce@irtf.org" > Reply-To: "irtf-discuss@irtf.org" >=20 > The preliminary agenda for the IRTF Open Meeting at IETF-88 is now = online: http://www.ietf.org/proceedings/89/agenda/agenda-89-irtfopen >=20 > Lars >=20 > -- >=20 > Preliminary Agenda > IRTF Open Meeting @ IETF-89 > London, UK > WEDNESDAY, March 5, 2014 > 0900-1130 Morning Session I >=20 > [Slot lengths below indicate presentation+discussion time.] >=20 > State of the IRTF > Lars Eggert > 5+5 min >=20 > Applied Networking Prize (ANRP) Award Talks > 30+10 min (x2) >=20 > *** Kenny Paterson *** on finding and documenting new attacks > against TLS and DTLS: >=20 > N. J. Al Fardan and K. G. Paterson. Lucky Thirteen: Breaking > the TLS and DTLS Record Protocols. Proc. IEEE Symposium on > Security and Privacy, pp. 526-540, San Francisco, CA, USA, > May 2013. >=20 > *** Keith Winstein *** on designing a transport protocol for > interactive applications that desire high throughput and low delay: >=20 > Keith Winstein, Anirudh Sivaraman, and Hari Balakrishnan > Stochastic Forecasts Achieve High Throughput and Low Delay > over Cellular Networks. Proc. 10th USENIX Symposium on > Networked Systems Design and Implementation (NSDI), Lombard, > IL, USA, April 2013. >=20 > Keith will talk about our work building Sprout, a transport > protocol for interactive traffic over cellular networks, and = Remy, a > tool that generates congestion-control protocols automatically. >=20 >=20 --Apple-Mail=_27FD192F-14B9-414B-89C6-0F47D07DCD8A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUwyl59ZcnpRveo1xAQKJLAQAgaxyeLtxZgG3umsw2U338WjgVKblS7w6 4a8PihuGFL6ZOrfXGTwY9rT09QpScFr1RiL/ufvexK1LI9Ev6G1iVsazJMdxOtaf xzZtkqZUe78Svp0GBwVh6mmTt+qfKBfivGyhSRJ9lLUaLk2/pJJ8FdgA9C0zBNfF T2O2Y0sJV8c= =Pt7A -----END PGP SIGNATURE----- --Apple-Mail=_27FD192F-14B9-414B-89C6-0F47D07DCD8A-- From nobody Tue Feb 25 07:52: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 1F5661A0134; Tue, 25 Feb 2014 07:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 eZLkvqmBOBAB; Tue, 25 Feb 2014 07:52:21 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 45B911A0115; Tue, 25 Feb 2014 07:52:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3359; q=dns/txt; s=iport; t=1393343540; x=1394553140; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ywdrgw4vIZ5CJh+M+UTi9LlzASMdLz8A7wJHnTrF7w0=; b=TngmorOE9jLH/VLo5i9k3oPEhplYHlHbC+31RjmHtAc+ZIeZYAXQz1SZ eI5Oq0e7KowqMR3ZvgU7HjEVcO0ORD3c9q33v0HQ9f39ZFHTjSPay4Owy trKPWVE2gy0fax4hAThtb9EJj2oIcFe1dmEFeU1j7k0n0VxhuNy67rxEu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPG7DFOtJV2c/2dsb2JhbABZgwY7V8FRgRgWdIImAQEEAQEBCVsHCxACAQgSLQcnCxQDDgIEAQ0FCRKHag3GaheOEwEBTwIFhDgEiRCPJIEykHWDLYFxOQ X-IronPort-AV: E=Sophos;i="4.97,540,1389744000"; d="scan'208";a="306201743" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 25 Feb 2014 15:52:20 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1PFqKHL021141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 15:52:20 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 09:52:19 -0600 From: "Charles Eckel (eckelcu)" To: Magnus Westerlund , Karl Stahl Thread-Topic: [tram] [rtcweb] Payload Types assignments Thread-Index: AQHPMgUpm6jL6hsIxEqt4QadBq4rXJrF/YCA Date: Tue, 25 Feb 2014 15:52:19 +0000 Message-ID: References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> <530C56CD.3010003@ericsson.com> In-Reply-To: <530C56CD.3010003@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.71.202] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <243E87F768614F4EB4D58382F038CE64@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ePDpf5LiD10Nn6I8WTDHwiZBOB8 Cc: "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [rtcweb] [tram] Payload Types assignments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 15:52:23 -0000 It may have been mentioned previously, but those interested in this may well want to have a look at the following drafts being discussed on the AEON list (aeon@ietf.org): http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00 http://tools.ietf.org/html/draft-eckel-aeon-use-cases-00 While QoS is not the sole focus of this work, it is one of the important work flows prevalent in networks today that is more challenging in the face of emerging communication applications such as those enabled by WebRTC. One of the goals of the AEON effort is to provide a framework such as the one mentioned by Magnus. Comments on the AEON list are welcome, as is your attendance at the AEON side meeting at IETF 89: http://www.ietf.org/mail-archive/web/aeon/current/msg00018.html Cheers, Charles On 2/25/14, 12:39 AM, "Magnus Westerlund" wrote: >Karl, >(As individual) > >I also wish for more usable QoS mechanisms. However, I don't see that >being achieved by your proposal. In addition I agree with Colin about >the issues with putting the information in the RTP header extension. I >would also note that this would be very RTP specific, and not at all >help with the data channels multiple streams and their priorities. There >might be data channel information that is more crucial than any of the >RTP media stream packets. > >You are pushing for a small piece in the middle. A piece that will not >help with the more general issue of QoS. How does the application and >the multiple ISPs that carries the traffic reach an agreement on what >properties that can be provided, that the application in this instance >have the right to request those properties and that any cost is >correctly associated with the user or the user's agent in regards to >carrying the associated cost. > >When it comes to setting DSCP from user land in the OS, that is >restricted due to the security implications. If those implications where >resolved, then OS could open up those interfaces. There are many >interlinked reasons why things look like they do today. I don't believe >in tugging on a single random thread in ball of yarn and hope that it >comes out without any knots and ties on it. > >Show me the framework for the QoS functions you have in mind that at >least has less issues than the currently deployed and take care of at >least some of the bigger issues. If that requires information in the RTP >streams for some reasons, then let us talk about how to best encoded it. >But, we need that framework first, the architecture that makes this a >better solution than the current Diffserv architecture or any other QoS >architecture. > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Tue Feb 25 07:52: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 9CE3A1A07C8 for ; Tue, 25 Feb 2014 07:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 uyPhRQgOaA_B for ; Tue, 25 Feb 2014 07:52:43 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8E91F1A07CA for ; Tue, 25 Feb 2014 07:52:43 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1PFqdId022522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 09:52:39 -0600 (CST) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s1PFqdQT005691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 10:52:39 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Tue, 25 Feb 2014 10:52:39 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Richard Ejzak Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EP/+ONLQ//ubSND/9sa4AA== Date: Tue, 25 Feb 2014 15:52:38 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B839A@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PoYNT8bt7vhKXrsZusoHWbyHO_c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 15:52:45 -0000 Hi Crister, Thanks. Please see my comments inline. > Hi Raju, >=20 > >> Anyway, can you give me an example of a case where you want to use > >> SDP, and where you need to negotiate the re-transmission values etc? > > > > [Raju] A simple example would be 2 browsers talking thru an intermedia > proxy, which wants to know what protocols are > > being negitiated and used as part of the session. >=20 > Sure. I don't question the use-case/need for using SDP to negotiate chann= el > usages. >=20 > > 1. Calling client creates data channel (using > http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel) > with desired > > attributes and sets negotiated=3Dtrue. So, calling browser saves the > attributes for the data channel but won't use DCP. > > 2. These attributes are sent via SDP to peer client (via proxy). > > 3. Peer client sets these same attributes while creating data channel a= nd > sets negotiated=3Dtrue but won't do DCP. > > 4. Peer client echo the same attributes back in SDP answer. > > > > Now, data channel stacks on both ends will use same attributes, similar= to > DCP use case, with the only difference being DCP is not used here. >=20 > My question was regarding the re-transmission values etc. >=20 > Why do the peers need to negotiate those? Why would an intermediary need = to > know about those? Why not simply define those in the protocol description= , > and each endpoint supporting the protocol will then know what values to u= se? [Raju] Peers need to negotiate those so that both ends of the data channel = can use same timers (similar to DCP). Intermediate entities pass these values to the peer in some cases and need = to know these in other cases so that they can be passed down to data channe= l entity which is terminating the data channel (and interworking to other t= ransports like TCP). IMHO, these attributes are specific to data channel thus they should remain= associated to data channel (DCP or external negotiation; making them part = of other protocols is not only wrong but also causes unenecessary modificat= ions adding overhead to these protocols. Best Regards Raju From nobody Tue Feb 25 08:56: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 CA8691A077A for ; Tue, 25 Feb 2014 08:56:54 -0800 (PST) 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 i1tpsuJZxgNO for ; Tue, 25 Feb 2014 08:56:53 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 6507D1A07CD for ; Tue, 25 Feb 2014 08:56:53 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta03.westchester.pa.mail.comcast.net with comcast id WbxF1n0050vyq2s53gwsFW; Tue, 25 Feb 2014 16:56:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id Wgws1n00B3ZTu2S3Rgwstm; Tue, 25 Feb 2014 16:56:52 +0000 Message-ID: <530CCB54.4000106@alum.mit.edu> Date: Tue, 25 Feb 2014 11:56:52 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393347412; bh=gqnBRLe4rG5PIW4/jXJvrQaNoiSqaHG0UMsKvjNPbmM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QdlcpZHyPiLqPlKLbZ4oF89khoXdKQj+uc1X6E/gS6AbHv5fm0ugQX7okPJY+6/MK uSE1lXQcBnDsvRgITpf0sNKfB/EdZDFY3fZJoe1X68ypcsQlz+6uuKjg6SgL9oQUrf GeNORDpsDnjHiEh49qWFTvXuRC8q+gEpbQ0H90vAlH/RhzLhEM5GZadfsegauw7MIB qHUqL0p28qVcOLACDLdTf/tPv8KrY/w+XvERb91QBjqlMNIPhR7T9EO3SmunF/bjHH SKQQfrBf+X6ER3VIxpJCA0IyZ7Vb7lOIy4c4uq9BDWO1zMvmR970h5gaQeIua25LR8 3X6VVK5ELqW6w== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bajP3mqGfSvbxmOa9EZ148ZA_vQ Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 16:56:55 -0000 Christer - comment at end On 2/25/14 4:08 AM, Christer Holmberg wrote: > Hi Raju, > >>> Anyway, can you give me an example of a case where you want to use >>> SDP, and where you need to negotiate the re-transmission values etc? >> >> [Raju] A simple example would be 2 browsers talking thru an intermedia proxy, which wants to know what protocols are >> being negitiated and used as part of the session. > > Sure. I don't question the use-case/need for using SDP to negotiate channel usages. > >> 1. Calling client creates data channel (using http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel) with desired >> attributes and sets negotiated=true. So, calling browser saves the attributes for the data channel but won't use DCP. >> 2. These attributes are sent via SDP to peer client (via proxy). >> 3. Peer client sets these same attributes while creating data channel and sets negotiated=true but won't do DCP. >> 4. Peer client echo the same attributes back in SDP answer. >> >> Now, data channel stacks on both ends will use same attributes, similar to DCP use case, with the only difference being DCP is not used here. > > My question was regarding the re-transmission values etc. > > Why do the peers need to negotiate those? Why would an intermediary need to know about those? Why not simply define those in the protocol description, and each endpoint supporting the protocol will then know what values to use? IIUC, the webrtc people are "humoring* us by making provision for registered subprotocol names, and using SDP to negotiate channels. I suspect that for the most part they have no intention of using those. (The subprotocol name is *optional*.) So these parameters are needed to properly initialize a channel when the subprotocol is not specified. Also, we still have an open question about what attributes must be present in a subprotocol specification. It is at least possible that some subprotocols may work with a variety of settings of these attributes. This draft should probably say more about this. It could say that: * the SDP MUST be consistent with the attributes specified in the subprotocol definition, OR * the SDP MUST NOT specify attributes specified in the subprotocol definition, OR * attributes specified in the SDP override those specified in the subprotocol definition. Thanks, Paul From nobody Tue Feb 25 09:50: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 AA67B1A0111 for ; Tue, 25 Feb 2014 09:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 z-R4W8KY1zM9 for ; Tue, 25 Feb 2014 09:49:56 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id C37A31A0105 for ; Tue, 25 Feb 2014 09:49:55 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta13.westchester.pa.mail.comcast.net with comcast id WdJD1n0010vyq2s5DhpucR; Tue, 25 Feb 2014 17:49:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id Whpu1n0073ZTu2S3RhpuPx; Tue, 25 Feb 2014 17:49:54 +0000 Message-ID: <530CD7C2.7050106@alum.mit.edu> Date: Tue, 25 Feb 2014 12:49:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Tuexen References: <530965D5.9090105@alum.mit.edu> <1B3F1D52-0F89-4F87-AB70-C1FAA73EC8EC@lurchi.franken.de> In-Reply-To: <1B3F1D52-0F89-4F87-AB70-C1FAA73EC8EC@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393350594; bh=Ffr90wqnV2gDujqiZuCi+qv6jvRsjh/PuKqmU1nYVXQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UrWV5Ii/sSiyeDpoVE8T6rUeJOHKD7pAsqmkM6F16vftZsJrXqGKtleFn61KuTMQu fDzkHRlbJG3f9+ai2xD9i57V++vYb0z6hWcuR1vNMnqOHI5sUh/jZUDMe9OJ0TbL3U A/jB2C4O8iuuVgsXMmwj5WK7iNpi2tCZWj8+YhCupndWQPUtav/xncS5aI+rDeaCbz cBgVUPmf1xhFcJnYX8oPVCGBto3m8uNvbL6c+B7HuiHAOjxhTKynZjpizmxpmkrLdf ezrYZptVmffyKuniSX0AHDrux4a8o7iZCxhhHGiB+CzNLYsiWmvENatn4dSmn7Yob6 SAhMi/tkKQPKA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lwBGbeNpEv5IZPdewbmbV8wJ0AU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-protocol-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 17:49:57 -0000 Inline On 2/24/14 5:12 AM, Michael Tuexen wrote: > On Feb 23, 2014, at 4:07 AM, Paul Kyzivat wrote: > >> A few comments on this draft: >> >> * Section 5.1: >> >> DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel provides >> a partial reliable in-order bi-directional Communication >> channel. User messages might not be transmitted or >> retransmitted after a specified life-time given in milli- >> seconds in the Reliability Parameter. This life-time starts >> when providing the user message to the Javascript engine. >> >> The last sentence above is troubling. This protocol won't always be used via Javascript. Can we please have a definition that > OK. What about replacing the last sentence with > > This life-time starts when providing the user > message to the protocol stack. *which* protocol stack? This is part of the problem. As the documents are currently structured, there is a "data channel establishment protocol", but there is no "data channel protocol". But in reality there *is* a (thin) data channel protocol. It just isn't described explicitly. In a browser it is perhaps just the code behind the data channel API. But in other environments it may need to be more explicit. It has some obligations. Presumably enforcing this "lifetime" parameter is one of them. Enforcing the use of sequenced messages between a DCEP open and receipt of ACK is another. >> doesn't depend on that? Is the timing being done by SCTP, or are you assuming that a data channel layer on top of SCTP is doing this? Is it specific to SCEP, or is it still applicable when the channel has been established via external negotiation? > It is actually the time when the message is provided to the SCTP stack, but I think > there might be some code running between the SCTP code and the user code (let it be > JS or anything else). I'm assuming that there is no substantial buffering happening > there. >> >> Does use of this option imply that retransmission continues until this time limit is reached? Or might it stop after some implementation defined number of retransmissions? > The only way the retransmissions don't happen until the time limit is reached, is that > SCTP decides that the association is broken because of excessive retransmissions. >> >> The description of the reliability parameter says: >> >> This field is ignored if a reliable channel is used. >> >> IMO folk wisdom says that some specific value (e.g., 0) should be prescribed to be used in such cases. That makes things more deterministic and provides more flexibility in extending the protocol in the future. > What about: > > For reliable channels this field MUST be set to 0 on the sending side > and MUST be ignored no the receiving side. WFM >> The name "Protocol" (and "Protocol Length") here is troublesome, because it is ambiguous with other sorts of uses. (See my comment about this point earlier today wrt draft-ietf-rtcweb-data-channel-07.) Others (including draft-ejzak-mmusic-data-channel-sdpneg-00 and websockets) call this "subprotocol". Using that would make it a little less confusing. > In the W3C specification it is also called protocol, but the text talks about sub-protocol. Maybe we should do > the same here. I'm not following the W3C part. I'm just interested in getting consistency, and avoiding confusion. Right now there is a lot of confusion around the use of "protocol". >> Also, ISTM that all of these things are applicable to externally negotiated channels, and so ought to be defined by draft-ietf-rtcweb-data-channel. (But of course their use in the DATA_CHANNEL_OPEN message belongs here.) > Reliability is discussed there, but I agree, we need to discuss label and protocol there, too. Good! >> * Section 8.4: >> >> ISTM there ought to be a template of the minimum information that the specification for a registered (sub)protocol MUST (SHOULD?) include. E.g., >> >> - what Channel Type(s) are valid for this (sub)protocol > I assumed all... ISTM that in *most* cases a if a (sub)protocol is designed for use with a reliable channel it won't work correctly with an unreliable channel. And while things designed to work with an unreliable channel will probably continue to work with a reliable channel, they might not have the intended properties. That's why its good to have some guidelines about what the specification must contain. It prevents people providing something sloppy and incomplete that isn't sufficient to use the (sub)protocol. >> - A contact for more information about this protocol > You need to provide a reference for the protocol. Isn't that enough? Depends on the form of the reference. Is the reference required to be publicly available? Stable? Note the definition of FCFS policy in 5226: First Come First Served - Assignments are made to anyone on a first come, first served basis. There is no substantive review of the request, other than to ensure that it is well-formed and doesn't duplicate an existing assignment. However, requests must include a minimal amount of clerical information, such as a point of contact (including an email address) and a brief description of how the value will be used. Additional information specific to the type of value requested may also need to be provided, as defined by the namespace. For numbers, the exact value is generally assigned by IANA; with names, specific text strings can usually be requested. Having a sufficient definition of what must be in the registry, and what must be in a reference from the registry is *more* important for FCFS than it is for some of the more restrictive policies. The policies that get careful review can perhaps depend on the reviewers stopping something that is incomplete. IMO the registry ought to provide, directly or indirectly, enough information to implement/use the (sub)protocol. Thanks, Paul > Best regards > Michael >> >> Thanks, >> Paul >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > From nobody Tue Feb 25 09:51: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 21EDD1A0108 for ; Tue, 25 Feb 2014 09:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 1D6pwn9mZ_Pb for ; Tue, 25 Feb 2014 09:51:43 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id DF4AB1A013A for ; Tue, 25 Feb 2014 09:51:38 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-a0-530cd8281639 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 91.5B.04853.928DC035; Tue, 25 Feb 2014 18:51:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 18:51:36 +0100 From: Christer Holmberg To: Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EP/+ONLQ//ubSND/9sNUAP/taKmw Date: Tue, 25 Feb 2014 17:51:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1B9882@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> <530CCB54.4000106@alum.mit.edu> In-Reply-To: <530CCB54.4000106@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI 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+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvja7mDZ5gg89/eC1WbDjAarH2Xzu7 A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxpWUWe8E0vopfSz6wNDAu5u5i5OSQEDCR eH5vBTOELSZx4d56ti5GLg4hgROMEn8PbWWBcJYwSnz/cQTI4eBgE7CQ6P6nDdIgIuAr0Xv5 HCOILSwQK7H76HpGiHicxKMH29gh7DyJFwengy1gEVCV+DrrKJjNC9Q7s2k71LLNrBL/JzQx gSQ4BXQktu8/DlbECHTR91NrwOLMAuISHw5eh7pUQGLJnvNQtqjEy8f/WCFsJYnGJU9YIep1 JBbs/sQGYWtLLFv4GmqxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUbI4tbg4N93IQC83 PbdEL7UoM7m4OD9Przh1EyMwYg5u+W20g/HkHvtDjNIcLErivNdZa4KEBNITS1KzU1MLUovi i0pzUosPMTJxcEo1MFav079ftTbVaavsLZVrUlwCcXtldvY+v6R8mmP/brY6TaZP2ZaMprEC lm3fo/ue7btqWKb06/PqubZvpWOF1tzfsDFVbureZCauuQfFJkuyRYnuFKusm+J13Wk2ywqv 0uipF6RKTy6cvyPqysIlbtui8kX+PUnQvy78UaX/NMffD9GqN4+941diKc5INNRiLipOBACY bf7jZgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fXCEz0OxAmi9A4cj9Q26x0I2lug Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 17:51:44 -0000 Hi Paul, >> My question was regarding the re-transmission values etc. >> >> Why do the peers need to negotiate those? Why would an intermediary need= to know about=20 >> those? Why not simply define those in the protocol description, and each= endpoint supporting the >> protocol will then know what values to use? > > IIUC, the webrtc people are "humoring* us by making provision for registe= red subprotocol names, > and using SDP to negotiate channels. I suspect tha= t for the most part they have no intention of=20 > using those.=20 > (The subprotocol name is *optional*.) > > So these parameters are needed to properly initialize a channel when the = subprotocol is not=20 > specified. Why would someone NOT specify the subprotocol? Especially considering Richard's draft, I thought the whole idea was to be = able to negotiate the subprotocol using SDP. > Also, we still have an open question about what attributes must be presen= t in a subprotocol=20 > specification. It is at least possible that some subprotocols may work wi= th a variety of settings of=20 > these attributes. Well, in that case the subprotocol specification should define the addition= al SDP attributes needed. > This draft should probably say more about this. It could say that: > > * the SDP MUST be consistent with the attributes specified in the subprot= ocol definition, OR > > * the SDP MUST NOT specify attributes specified in the subprotocol defini= tion, OR > > * attributes specified in the SDP override those specified in the subprot= ocol definition. If people see a need for these attributes, fine. But, I still have not seen= an example where it would be needed (e.g. the UDP RFC does not specify the= timers for SIP - RFC 3261 does :) Regards, Christer From nobody Tue Feb 25 09: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 220FC1A017D for ; Tue, 25 Feb 2014 09:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 l5IiBtGkqE-a for ; Tue, 25 Feb 2014 09:53:48 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 8474F1A016E for ; Tue, 25 Feb 2014 09:53:48 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1PHrdQ1005050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 11:53:40 -0600 (CST) 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 s1PHrZcd006639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 18:53:35 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 25 Feb 2014 18:53:35 +0100 From: "DRAGE, Keith (Keith)" To: Magnus Westerlund , Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Number of samples (ptime) to be supported by required codecs (draft-ietf-rtcweb-audio-05) Thread-Index: AQHPLIfGv046F+n6zEmM5NYdM3BT9pq7j+oAgAFTQ6GACNpgAIAAc0kA Date: Tue, 25 Feb 2014 17:53:34 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B13943C@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <530320F7.4090300@ericsson.com> <5303E578.3000207@alvestrand.no> <53046842.2010108@ericsson.com> <5304F3E0.1020206@alvestrand.no> <530C6F3C.1090709@ericsson.com> In-Reply-To: <530C6F3C.1090709@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8lxh24LsRP69ED_Cczwln4NbMkI Subject: Re: [rtcweb] Number of samples (ptime) to be supported by required codecs (draft-ietf-rtcweb-audio-05) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 17:53:53 -0000 I agree with Haralds comments on this. I do not see any point in writing RTCWEB specific requirements on this. Keith=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 > Magnus Westerlund > Sent: 25 February 2014 10:24 > To: Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] Number of samples (ptime) to be=20 > supported by required codecs (draft-ietf-rtcweb-audio-05) >=20 > On 2014-02-19 19:11, Harald Alvestrand wrote: > > On 02/19/2014 09:16 AM, Magnus Westerlund wrote: > >> On 2014-02-18 23:58, Harald Alvestrand wrote: > >>> I may be a little simple-minded, but if we have a recommendation=20 > >>> that receivers MUST be able to receive all packetizations=20 > of G.711=20 > >>> and OPUS up to 200 ms per packet, and that receivers=20 > should signal=20 > >>> this by sending "a=3Dmaxptime:200" in their SDP, what=20 > situations exist=20 > >>> where interoperability is not going to be achieved? > >> Interoperability is going to be achieve in the direction=20 > towards this=20 > >> endpoint. The question is if we achieve interoperability in the=20 > >> direction from that endpoint. > >=20 > > So, given that there is nothing in the G.711 specification=20 > about which=20 > > sample sizes a G.711 receiver has to support - the right approach=20 > > seems to be to amend the G.711 MIME registration with this=20 > information. >=20 > Yes, it would for the future. But considering the wide-spread=20 > deployment of this payload format I don't see that having any=20 > short term effect on the interoperability. >=20 > Also, the recommendations are actually context dependent.=20 > Thus, it is not obvious that a single recommendation is suitable. >=20 > >=20 > > This is not a WebRTC issue; it is an absence of=20 > specification for the=20 > > non-WebRTC devices that use G.711. The RTCWEB specifications can=20 > > reasonably be expected to point to existing information about this=20 > > issue; it is not reasonable (in my mind) that the RTCWEB WG decide=20 > > what these values should be. > >=20 >=20 > I would argue for this consideration based on that this is=20 > done in the WebRTC context, not any other context. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From nobody Tue Feb 25 09:55: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 9248F1A013E for ; Tue, 25 Feb 2014 09:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 HTbiV-6JtK5E for ; Tue, 25 Feb 2014 09:55:01 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CBECC1A017A for ; Tue, 25 Feb 2014 09:54:56 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1PHsrSw022766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 11:54:54 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s1PHsrKa030474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 12:54:53 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Tue, 25 Feb 2014 12:54:53 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EP/+ONLQ//sW+yX/9iL+AA== Date: Tue, 25 Feb 2014 17:54:53 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> <530CCB54.4000106@alum.mit.edu> In-Reply-To: <530CCB54.4000106@alum.mit.edu> 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/VXxg-u_x9dQavpk-o1mHH6Yfn1g Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 17:55:04 -0000 Hi Paul, Please see comments inline. > Christer - comment at end >=20 > On 2/25/14 4:08 AM, Christer Holmberg wrote: > > Hi Raju, > > > >>> Anyway, can you give me an example of a case where you want to use > >>> SDP, and where you need to negotiate the re-transmission values etc? > >> > >> [Raju] A simple example would be 2 browsers talking thru an intermedia > proxy, which wants to know what protocols are > >> being negitiated and used as part of the session. > > > > Sure. I don't question the use-case/need for using SDP to negotiate > channel usages. > > > >> 1. Calling client creates data channel (using > http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel) > with desired > >> attributes and sets negotiated=3Dtrue. So, calling browser saves the > attributes for the data channel but won't use DCP. > >> 2. These attributes are sent via SDP to peer client (via proxy). > >> 3. Peer client sets these same attributes while creating data channel = and > sets negotiated=3Dtrue but won't do DCP. > >> 4. Peer client echo the same attributes back in SDP answer. > >> > >> Now, data channel stacks on both ends will use same attributes, simila= r > to DCP use case, with the only difference being DCP is not used here. > > > > My question was regarding the re-transmission values etc. > > > > Why do the peers need to negotiate those? Why would an intermediary nee= d > to know about those? Why not simply define those in the protocol > description, and each endpoint supporting the protocol will then know wha= t > values to use? >=20 > IIUC, the webrtc people are "humoring* us by making provision for > registered subprotocol names, and using SDP to negotiate channels. I > suspect that for the most part they have no intention of using those. > (The subprotocol name is *optional*.) >=20 > So these parameters are needed to properly initialize a channel when the > subprotocol is not specified. [Raju] If I understand correctly, these parameters simply define the=20 data channel transport properties. Yes, they may have some correletion with= =20 subprotocol, but that's not a one-to-one mapping. For example, a given subprotocol could run on a reliable or=20 unreliable transport; depending on app needs it may use unreliable=20 transport and deal with reliablity at subprotocol stack (or ignore it). >=20 > Also, we still have an open question about what attributes must be > present in a subprotocol specification. It is at least possible that > some subprotocols may work with a variety of settings of these attributes= . [Raju] Right, this fits into my explanation above. >=20 > This draft should probably say more about this. It could say that: >=20 > * the SDP MUST be consistent with the attributes specified in the > subprotocol definition, OR >=20 > * the SDP MUST NOT specify attributes specified in the subprotocol > definition, OR >=20 > * attributes specified in the SDP override those specified in the > subprotocol definition. [Raju] Good point. I like item 1 above; sure we can add it to this=20 draft. Then individual subprotocol drafts=20 (e.g. draft-ejzak-dispatch-msrp-data-channel-00) could get into the details of what that consistency is. Best Regards Raju From nobody Tue Feb 25 10:26: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 439061A0126 for ; Tue, 25 Feb 2014 10:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 ug4EG0AqsUVo for ; Tue, 25 Feb 2014 10:26:32 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0271A0111 for ; Tue, 25 Feb 2014 10:26:32 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1PIQSF0029700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 12:26:28 -0600 (CST) 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 s1PIQR7R015876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 13:26:28 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Tue, 25 Feb 2014 13:26:27 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EP/+ONLQ//ubSND/9sNUAP/taKmw/9rN9bA= Date: Tue, 25 Feb 2014 18:26:26 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> <530CCB54.4000106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1B9882@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B9882@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Bqmd4P64fzW22sfFhRhH1GNgQwA Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 18:26:34 -0000 Hi Christer, Please find my comments inline. >=20 > Especially considering Richard's draft, I thought the whole idea was to b= e > able to negotiate the subprotocol using SDP. >=20 > > Also, we still have an open question about what attributes must be pres= ent > in a subprotocol > > specification. It is at least possible that some subprotocols may work > with a variety of settings of > > these attributes. >=20 > Well, in that case the subprotocol specification should define the > additional SDP attributes needed. >=20 > > This draft should probably say more about this. It could say that: > > > > * the SDP MUST be consistent with the attributes specified in the > subprotocol definition, OR > > > > * the SDP MUST NOT specify attributes specified in the subprotocol > definition, OR > > > > * attributes specified in the SDP override those specified in the > subprotocol definition. >=20 > If people see a need for these attributes, fine. But, I still have not se= en > an example where it would be needed (e.g. the UDP RFC does not specify th= e > timers for SIP - RFC 3261 does :) [Raju] Aren't the attributes we are talking here are data channel propertie= s? DCP explains the following type of data channel as: DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel provides a partial reliable in-order bi-directional Communication channel. User messages might not be transmitted or retransmitted after a specified life-time given in milli- seconds in the Reliability Parameter. This life-time starts when providing the user message to the Javascript engine. Fo example,'maxRetransmitTime' value specified by createDataChannel API (SD= P's maxtime) here is realized by data channel stack, NOT by the application= . The timer value given by the client may be a generic value rather than sp= ecific to a subprotocol. To draw comparision to TCP, Linux allows TCP_USER_= TIMEOUT sockopt which allows application to specify max timer value for any= unacknowledged data. 'maxRetransmitTime' is similar. The SIP analogy mentioned above is for subprotocol level timers but not for= transport level retransmissions timers. A subprotocol could have it's own = retransmission timer for lack of response for a req. Lack of subprotocol re= sponse could still happen, if the peer application drops the request, even = when data channel successfully sent the request.=20 So, I think timers (parameters) at both data channel stack and subprotocol = have clear semantics and mostly independent of each other. Best Regards Raju From nobody Tue Feb 25 11:27: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 4DCC51A0213 for ; Tue, 25 Feb 2014 11:27:17 -0800 (PST) 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 1_Vw0qvzpqCZ for ; Tue, 25 Feb 2014 11:27:10 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D47771A01D3 for ; Tue, 25 Feb 2014 11:26:58 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id bs8so4972883wib.6 for ; Tue, 25 Feb 2014 11:26:57 -0800 (PST) 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=VUiWvcBnJw+PeTRGlmmXnNCCps16P5YGwlwYnWBDaOY=; b=SQwi2YBFlsICCfBvNh5p/w6il8WeUlWfPaVQzMAje+wCV8g11fTCBs/tJ4Bk955jzf 9Mt7Ex8iR3ObPtZZF67RyRZiR1aK5W8922j0xHGndlvNUYUdtPMqeuBqy/O5TXzUjS5c WzgHGtRzSdAK1uSv77T+3J00RmIZVv1Q6k9XEebvBDD5AC0prpE3lyP/MHOBO1rPx3aw qBiiwMNIARBqss3EZdXR4Ntf7OkmojM2l4mPI46WpqojZSE4Ar+JKeQ0Tz3lq6r6X8kW kTiLlTwBhQf3nLfsh/rkNSrvKuSKTiMTzx6r3RfmRAv6PpN3NJd85Y+rzvo3K2Tp4u4A likA== MIME-Version: 1.0 X-Received: by 10.194.82.69 with SMTP id g5mr338401wjy.85.1393356417460; Tue, 25 Feb 2014 11:26:57 -0800 (PST) Received: by 10.217.96.195 with HTTP; Tue, 25 Feb 2014 11:26:57 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> Date: Tue, 25 Feb 2014 13:26:57 -0600 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bb047944eefc504f340125e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NhWtV1Rr4RwHctowYtDE2EWxBx4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 19:27:17 -0000 --047d7bb047944eefc504f340125e Content-Type: text/plain; charset=ISO-8859-1 Why are we having this discussion on the RTCWEB mailing list rather than the MMUSIC mailing list? This document was dispatched to MMUSIC at IETF-88: http://trac.tools.ietf.org/wg/dispatch/trac/wiki And, the nifty datatracker tool tells us that this (expired) document has been replaced by an individual draft that has been submitted to the MMUSIC WG: http://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-channel-sdpneg/ It seems there's a lot of interest in this document, so if folks want it to be considered for adoption in the MMUSIC WG, PLEASE move the discussion to the MMUSIC WG list. The chairs need the discussion there in order to get a sense of WG interest, so you might want to include a link to this thread of discussion in a NEW email to the MMUSIC WG mailing list and point this discussion to that thread. But, please do not crosspost. Thanks, Mary. On Mon, Feb 24, 2014 at 7:18 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg: > > > > *Q1:* > > > > Instead of defining a new SDP webrtc-DataChannel attribute, would it be > possible to define the parameters as extension parameters to the SDP > sctpmap attribute (yes, I know the ABNF currently does not allow that)? > > > > Example: > > > > *a=sctpmap:1000 webrtc-datachannel 1;stream=6;subprotocol="CLUE"* > > > > I am not saying this would be good or bad - at this point I just want to > understand whether it would work. > > > > > > *Q2:* > > > > Would it be possible, for subprotocol values, use the same IANA > registry/values as for the WebRTC Data Channel Protocol? > > > > > > *Q3:* > > > > It would be good to clarify, if only one data channel is requested (or, > even required), that the stream value must be the same in the Offer and > Answer. > > > > > > *Q4:* > > > > I have issues with the max_retr, max_time and unordered parameters. > > > > First, they seem to specify SENDING capabilities, rather than RECEIVING > capabilities. > > > > Second, they seem to describe characteristics associated with the > subprotocol, in which case they could be specified in the associated > subprotocol specification. > > > > Regards, > > > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7bb047944eefc504f340125e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Why are we having this discussion on the RTCWEB mailing li= st rather than the MMUSIC mailing list?   This document was dispatched= to MMUSIC at IETF-88: http://trac.tools.ietf.org/wg/dispatch/trac/wiki
And, the nifty datatracker tool tells us that this (expired) document has b= een replaced by an individual draft that has been submitted to the MMUSIC W= G: 

It seems there's a lot of interest in this document= , so if folks want it to be considered for adoption in the MMUSIC WG, PLEAS= E move the discussion to the MMUSIC WG list.  The chairs need the disc= ussion there in order to get a sense of WG interest, so you might want to i= nclude a link to this thread of discussion in a NEW email to the MMUSIC WG = mailing list and point this discussion to that thread. But, please do not c= rosspost.  

Thanks,
Mary. 


On Mon, Fe= b 24, 2014 at 7:18 AM, Christer Holmberg <christer.holmberg@e= ricsson.com> wrote:

Hi,

 

A few questions on  draft-= ejzak-dispatch-webrtc-data-channel-sdpneg:

 

Q1:=

 

Instead of defining a new SDP w= ebrtc-DataChannel attribute, would it be possible to define the parameters = as extension parameters to the SDP sctpmap attribute (yes, I know the ABNF = currently does not allow that)?

 

Example:

 

a=3Dsctpmap:1000 webrtc-datachannel 1;stream=3D6;subprotocol=3D”CLUE= "

 

I am not saying this would be g= ood or bad – at this point I just want to understand whether it would= work.

 

 

Q2:=

 

Would it be possible, for subpr= otocol values, use the same IANA registry/values as for the WebRTC Data Cha= nnel Protocol?

 

 

Q3:=

 

It would be good to clarify, if= only one data channel is requested (or, even required), that the stream va= lue must be the same in the Offer and Answer.

 

 

Q4:=

 

I have issues with the max_retr= , max_time and unordered parameters.

 

First, they seem to specify SEN= DING capabilities, rather than RECEIVING capabilities.

 

Second, they seem to describe c= haracteristics associated with the subprotocol, in which case they could be= specified in the associated subprotocol specification.

 

Regards,=

 

Christer


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


--047d7bb047944eefc504f340125e-- From nobody Tue Feb 25 14:00: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 83BFB1A07A5 for ; Tue, 25 Feb 2014 14:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.5 X-Spam-Level: * X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[BAYES_60=1.5, RCVD_IN_DNSWL_NONE=-0.0001] 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 XRJqWV6i-jjv for ; Tue, 25 Feb 2014 14:00:50 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 511211A01E5 for ; Tue, 25 Feb 2014 14:00:50 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:4843 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1WIQ3U-0005Sq-TV for rtcweb@ietf.org; Tue, 25 Feb 2014 16:00:49 -0600 Message-ID: <530D1244.5090001@jesup.org> Date: Tue, 25 Feb 2014 16:59:32 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53077E7B.1070900@ericsson.com> In-Reply-To: <53077E7B.1070900@ericsson.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 - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SX4PmABLgGEaH2x6dPBSLwuRsXU Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 22:00:51 -0000 On 2/21/2014 11:27 AM, Magnus Westerlund wrote: > 5. Section 3.2: > U-C 7: Proxy browsing, where a browser uses data channels of a > PeerConnection to send and receive HTTP/HTTPS requests and > data, for example to avoid local Internet filtering or > monitoring. > > >From a data channel perspective this doesn't look strange at all, > however I get the shivers from the security implications of this. To my > understanding Peer A using Peer B to proxy browse must have B fetch all > elements that A needs into its sandbox and then transfer it to A over > the PeerConnections Data Channel. Thus, all you do are revealed to B, > massive privacy consideration. Or am I missing someway that A can tunnel > its HTTP request through B without having B see the content of those > requests, I am especially concerned with HTTPS. > > If this use case is going to stay, I do want some security consideration > discussion around it. I'll note that there are active projects looking to use this. Yes, it will likely expose non-https data to the proxy. https traffic should in theory be as protected as it normally is against proxies. This usage would support various forms of monitoring-avoidance (and avoidance of relying on local network resources such as in a WiFi hotspot). It's not a direct replacement for Tor, but it's also much less intrusive than Tor. It inherently requires some level of trust of the person proxying for you. We can expose some of the security considerations, but the primary ones would be dependent on how this is used, not that this protocol has the characteristics that would support such a use. This is mostly saying "we want it to be low overhead for stream creation and initial messages and support a bunch of them at once". -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Tue Feb 25 14:23: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 75ACC1A02AF for ; Tue, 25 Feb 2014 14:22:59 -0800 (PST) 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 Ib1OYAeVNNFf for ; Tue, 25 Feb 2014 14:22:58 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 74B591A079D for ; Tue, 25 Feb 2014 14:22:50 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta06.westchester.pa.mail.comcast.net with comcast id Wj4x1n0091c6gX856mNp9L; Tue, 25 Feb 2014 22:22:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id WmNp1n0053ZTu2S3jmNptg; Tue, 25 Feb 2014 22:22:49 +0000 Message-ID: <530D17B8.1070105@alum.mit.edu> Date: Tue, 25 Feb 2014 17:22:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "rtcweb@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> <530CCB54.4000106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1B9882@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B9882@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393366969; bh=cnOqsy4ZWawInf8PUPvwVNwwERBO0LfxOlM4pEIw9NI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UYapEti+UwowiKzmuJsVtvj/9WE8evT9LpBLZjJutoGeASEqudBg7CdzjGWYUnjhC QMbmUR06sHM+u7KRla5imPDMVlahK8la/BOSBMqynmjFeiqkEN/r/nDh7FkWZsU6zo Y+lHGHVMhcj+ExVZEkHA9nBtY1yI+KA2CZ72wiCEufu0qs5AXfbWpq/JrTmfe6e/Bh Vjk0J1iSUvlJTA53sRy+XLK6qqUSAzx2eYwC8M+bY64weg5ECiaZ2R7dJ/EnvXqGyx TYxRGWUgFHUCThLzimYNU5rrs4CuwDaFsyDaWQ3vBhWXEhaGKjL8YaWYd88NOoLmJT cytdpvHR9Iieg== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CwHBHW64lnKloVRsb1I_uCl9yeg Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 22:23:00 -0000 On 2/25/14 12:51 PM, Christer Holmberg wrote: > Hi Paul, > >>> My question was regarding the re-transmission values etc. >>> >>> Why do the peers need to negotiate those? Why would an intermediary need to know about >>> those? Why not simply define those in the protocol description, and each endpoint supporting the >> protocol will then know what values to use? >> >> IIUC, the webrtc people are "humoring* us by making provision for registered subprotocol names, > and using SDP to negotiate channels. I suspect that for the most part they have no intention of >> using those. >> (The subprotocol name is *optional*.) >> >> So these parameters are needed to properly initialize a channel when the subprotocol is not >> specified. > > Why would someone NOT specify the subprotocol? Because there is no defined subprotocol for what they are doing? In the common webrtc use case with two browsers talking to the same web service, and the web service feeding the needed javascript to the browsers, they just "know" the protocol they are using. So they may just "make it up", and have nothing registered. It is when they need to interoperate with something else that it becomes important to name and register the protocol. > Especially considering Richard's draft, I thought the whole idea was to be able to negotiate the subprotocol using SDP. That's for us, not them. :-) They will be using DCEP. >> Also, we still have an open question about what attributes must be present in a subprotocol >> specification. It is at least possible that some subprotocols may work with a variety of settings of >> these attributes. > > Well, in that case the subprotocol specification should define the additional SDP attributes needed. > >> This draft should probably say more about this. It could say that: >> >> * the SDP MUST be consistent with the attributes specified in the subprotocol definition, OR >> >> * the SDP MUST NOT specify attributes specified in the subprotocol definition, OR >> >> * attributes specified in the SDP override those specified in the subprotocol definition. > > If people see a need for these attributes, fine. But, I still have not seen an example where it would be needed (e.g. the UDP RFC does not specify the timers for SIP - RFC 3261 does :) I was talking in general. The answers may be different for each attribute. Thanks, Paul From nobody Tue Feb 25 14:24: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 41A7F1A0298 for ; Tue, 25 Feb 2014 14:24:11 -0800 (PST) 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, 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 FTQuwTjr0s3g for ; Tue, 25 Feb 2014 14:24:06 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C43AF1A02AF for ; Tue, 25 Feb 2014 14:24:06 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:4948 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1WIQQ1-000EVs-O0 for rtcweb@ietf.org; Tue, 25 Feb 2014 16:24:05 -0600 Message-ID: <530D17B9.6090007@jesup.org> Date: Tue, 25 Feb 2014 17:22:49 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <530627C7.30906@ericsson.com> <53070996.9040707@ericsson.com> <530B194F.4040909@ericsson.com> In-Reply-To: <530B194F.4040909@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GEXPKodtcKshAG6MM6LkO8OPENc Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 22:24:11 -0000 On 2/24/2014 5:05 AM, Magnus Westerlund wrote: > On 2014-02-22 02:14, Martin Thomson wrote: > >> >> Maybe Magnus is looking for the mechanism described in >> http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00, >> which might allow for control below the limit that the congestion >> control permits. I basically abandoned this, because it's small >> potatoes. It's trivial to revoke consent if you notice a misbehaving >> peer and then you only have to wait until the consent timer runs out >> on the sender. 30s. >> >> > My position is that the above mitigation is unlikely to have significant > impact on this attack. This as it is difficult to know what values to > set. They vary over time and depending on network attachment, what > services the user tries to use etc. > > There are two reasons I wanted this attack to be considered. First, it > provides a clear requirement on having congestion control as first level > mitigation. > > Secondly, I think this could become a significant issue as data channel > PeerConnections can be opened without user consent. A malicious JS that > is sufficient well spread with a well working find and connect could > establish a large mesh of peer connections that could come close to > saturate each endpoints local access link, resulting in very heavy loads > on the network, even with congestion control. With congestion control > you can likely prevent congestion collapse, but you should be fully > capable of driving a network into a state of "mostly useless", > especially a network suffering from buffer bloat inside of the ingress > nodes. Of course, any smart attacker could do the same today by opening large numbers of http or WebSocket connections that cross the same networks, especially if the target isn't the remote endpoint but intermediary networks as you indicated. A difference is that it may be harder to find destination nodes that will accept such connections and return or accept data across the link you want to attack, though the open requests themselves can be an attack. However, in real terms, there are usually nodes in an access network that return some data to requests (such as routers with remote admin turned on, servers (or rogue servers), especially on non-standard ports (not 80), etc. Simply finding routers that respond on 80 or 8080, etc and you can send large bogus HTTP request to or get to return static images repeatedly might be enough to construct an equivalent attack. (Even more-so perhaps with IW10). So: congestion control: of course. Perhaps this makes it a little simpler to set up certain types of indirect attacks - but I don't think it adds a fundamental class of attacks. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Tue Feb 25 14:25: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 2A8C31A02BF for ; Tue, 25 Feb 2014 14:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.506 X-Spam-Level: X-Spam-Status: No, score=-0.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, 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 Mrrh7f5Ki_I9 for ; Tue, 25 Feb 2014 14:25:28 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id B1D611A0298 for ; Tue, 25 Feb 2014 14:25:27 -0800 (PST) Received: from [192.168.1.103] (p508F31B7.dip0.t-ipconnect.de [80.143.49.183]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B7E381C1042E2; Tue, 25 Feb 2014 23:25:24 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <530B740E.4090707@ericsson.com> Date: Tue, 25 Feb 2014 18:07:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <530B740E.4090707@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uPd7wY2Yhax0Bwd5T3Umwi1Nbjw Cc: draft-ietf-rtcweb-data-protocol@tools.ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 22:25:31 -0000 On Feb 24, 2014, at 5:32 PM, Magnus Westerlund = wrote: > Hi, > (as individual) Hi Magnus, thank you very much for the detailed review. Please see my comments = in-line. Best regards Michael >=20 > I have reviewed the WebRTC Data Channel Establishment protocol > (draft-ietf-rtcweb-data-protocol-03) and have some comments: >=20 > 1. Section 4: > Shouldn't this section discuss the priority field? I added in the list of consistent properties: the priority of the data Channel. and in the text below that enumeration: ?????? >=20 > 2. Section 4: >=20 > The method > used to determine which side uses odd or even is based on the > underlying DTLS connection role when used in WebRTC, with the side > acting as the DTLS client using even stream identifiers. >=20 > Isn't this unnecessary using the vague word of WebRTC instead of = simply > pointing to the DTLS roles of the established data channel? The point is that in the WebRTC you use DCEP/SCTP/DTLS/UDP and therefore you can refer to the DTLS role. However, you could use DCEP/SCTP/IP or DCEP/SCTP/UDP/IP or DCEP/SCTP over something not involving DTLS. In that case DTLS is not used and you can not refer to the DTLS role. That is why the restriction is used. >=20 > 3. Section 5.1: > DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel provides > a partial reliable in-order bi-directional Communication > channel. User messages might not be transmitted or > retransmitted after a specified life-time given in milli- > seconds in the Reliability Parameter. This life-time starts > when providing the user message to the Javascript engine. >=20 > I think the use of "Javascript engine" in the last sentence is = unclear. > Can we provide a implementation neutral definition, like "This = life-time > starts when requesting transmission of the user message."? This comment was already made on the list and I changed the text to This life-time starts when providing the user message to the protocol = stack. OK? >=20 > 4. Section 5.1: > Label: Variable Length (sequence of characters) > The name of the channel. This may be an empty string. >=20 > Protocol: Variable Length (sequence of characters) > The protocol for the channel. If this is an empty string the > protocol us unspecified. If it is an non-empty string, it > specifies an IANA-registered protocol (see Section 8.4). >=20 > Both of these fields are strings, shouldn't a particular encoding be > specified here? Like UTF-8. Secondly, what values are allowed, the = full > set of Unicode? You are right. Any need for restrictions? We only need to be able to transform it to a DomString. So I changed it to: The name of the channel as a UTF-8 encoded string. This may be an empty string. The protocol for the channel as a UTF-8 encoded string. If this is an empty string the protocol us unspecified. If it is an non-empty string, it specifies an IANA-registered protocol (see ). >=20 > 5. Section 6: > All Data Channel Establishment Protocol messages MUST be sent > requesting ordered delivery and using reliable transmission. >=20 > I wonder of the use of requesting ordered delivery and using reliable > transmission, from an SCTP stream perspective, wouldn't using in both > places be appropriate? Or is how object which has been requested to be > transmitted unordered interact in SCTP with the ordered ones? I'm sorry, I don't understand what you are asking... The reason of this restriction is that this restriction combined with However, before the DATA_CHANNEL_ACK message or any other message has = been received on a data channel, all other messages containing user data and belonging to this data channel MUST be sent ordered, no matter whether = the data channel is ordered or not. makes sure that the SCTP at the peer delivers the DATA_CHANNEL_OPEN = message first on a stream. > 6. Section 7: >=20 > I think this section can be beefed up a bit. First make clear that the > Data Channel's required usage of DTLS ensures that the message = integrity > and possible source authentication as well as confidentiality. Then > going over any security risks with a malicous peer using this = protocol. > Can a malicous side screw up the peer using this protocol? What are = the > implications? Just to double check: Aren't the referenced documents the ones which discuss all security stuff in one place? >=20 > 7. Section 8.2: >=20 > This registry reserves 0xff without any motivation, please add one. I added: The value 0xff has been reserved for future extensibility. >=20 > 8. Section 8.3: > If I define a channel behavior that allows mixed ordered and = unordered, > how would I register this? You can't. For SCTP properties like ordered/unordered delivery are on a per message base. In RTCWeb it was decided to make per channel base. So you can't have a data channel supporting a mixtures of ordered and unordered messages. >=20 > 9. Section 8.4: >=20 > I have a suggestion for this registries name, instead of "Protocol > Registry" I propose "DCEP Protocol Identification Registry" The problem I have with this definition is the following: Your name suggests that the use of this entity is restricted to DCEP. But isn't the protocol a property of a data channel, no matter whether negotiated by used DCEP or not? >=20 > 10. Section 8.4: >=20 > There is missing any specification of what type of strings I may > register. Also, no length limitation, although the protocol allows at > maximum of 255 octets of encoded characters. I don't understand the limitation to 255 octets. The length field is 16 bit, so you can have up to 65535 octets. Therefore I changed: A name for the protocol; to A name for the protocol which length is smaller than 65536 when using an UTF-8 encoding; >=20 > 11. This comments concerns the relation to the Data Channel > specification. So my interpretation is that the WebRTC Data channel > draft has become both the base for this specification as well as the = one > that specifies that the DCEP shall be implemented and supported. For > WebRTC I don't think this matters much, but if someone likes to re-use > the basic Data Channel specification, this structure makes it more > difficult and have no need for the bi-directional negotiated parameter > settings that the DCEP provides. In that case one have to sub-set the I think the data channel draft discusses the data channels independent how they are opened. This covers data parameters, user data transmission and closing of data channels. The data channel protocol draft discusses an in-band protocol for setting up data channels. > data channel specification. I wonder if it would be better to move = some > normative statements around, so that the chain of implementation > requirement goes draft-ietf-rtcweb-transports -> > draft-ietf-rtcweb-data-protocol -> draft-ietf-rtcweb-data-channel thus > providing a cleaner and more modular build up of the protocols. I think you can implement draft-ietf-rtcweb-data-channel without draft-ietf-rtcweb-data-protocol, but not vice versa. So you don't like the statement: A simple protocol for internal negotiation is specified in [I-D.ietf-rtcweb-data-protocol] and MUST be supported. from draft-ietf-rtcweb-data-channel. What would you suggest? >=20 > This a suggestion based on that it looks like others, like CLUE is = going > to use the Data Channel specification, but I am uncertain if they want > DCEP or not. Understood. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Tue Feb 25 14:26: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 928C91A02BF for ; Tue, 25 Feb 2014 14:26:43 -0800 (PST) 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 oM1nE4_Fq_ak for ; Tue, 25 Feb 2014 14:26:42 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id D75191A0298 for ; Tue, 25 Feb 2014 14:26:40 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta10.westchester.pa.mail.comcast.net with comcast id Wdm41n0041YDfWL5AmSfPe; Tue, 25 Feb 2014 22:26:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id WmSf1n00e3ZTu2S3gmSfEv; Tue, 25 Feb 2014 22:26:39 +0000 Message-ID: <530D189F.8020804@alum.mit.edu> Date: Tue, 25 Feb 2014 17:26:39 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , "rtcweb@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> <530CCB54.4000106@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393367199; bh=4sk0b6R8xCpQ3ESyGiDYXt6/w5R0wPm3Sj2DHymimuc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qRtMC26ja9DjCzv0F/XJuAalXkkVCEbtfB6YEaWNgRnfth42vd+hZrDnacNkz4DbQ xvE6Ekb48S0VrwMCszAjFeXcjVTen1xJGwg05v6JTs+cTzHf7c3HSBksG0hzvqijcv wSKnGjjW4bxYpGTXTQkHvFJkH5SOxPTYhG94nezzQPrh74BqhitzMDplRGvOCQi7Oo AgbH/xB8cvnjKjR/Uw07OJSPhdaNtt2hEqSs1a4SMo65Dlk2dUq7UfG/v1DVvKE3LX ETJ+wrHyfphPz9oOe2vpJ0PLERWX/6xD1qMy3vIUBvGYrELQXT+sh1RTWke1UyyfDI XgHW96FXZB0Wg== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ipb9YgZd9jYfFcDYgmN7ZRsptQo Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 22:26:43 -0000 On 2/25/14 12:54 PM, Makaraju, Maridi Raju (Raju) wrote: > Hi Paul, > > Please see comments inline. > >> Christer - comment at end >> >> On 2/25/14 4:08 AM, Christer Holmberg wrote: >>> Hi Raju, >>> >>>>> Anyway, can you give me an example of a case where you want to use >>>>> SDP, and where you need to negotiate the re-transmission values etc? >>>> >>>> [Raju] A simple example would be 2 browsers talking thru an intermedia >> proxy, which wants to know what protocols are >>>> being negitiated and used as part of the session. >>> >>> Sure. I don't question the use-case/need for using SDP to negotiate >> channel usages. >>> >>>> 1. Calling client creates data channel (using >> http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel) >> with desired >>>> attributes and sets negotiated=true. So, calling browser saves the >> attributes for the data channel but won't use DCP. >>>> 2. These attributes are sent via SDP to peer client (via proxy). >>>> 3. Peer client sets these same attributes while creating data channel and >> sets negotiated=true but won't do DCP. >>>> 4. Peer client echo the same attributes back in SDP answer. >>>> >>>> Now, data channel stacks on both ends will use same attributes, similar >> to DCP use case, with the only difference being DCP is not used here. >>> >>> My question was regarding the re-transmission values etc. >>> >>> Why do the peers need to negotiate those? Why would an intermediary need >> to know about those? Why not simply define those in the protocol >> description, and each endpoint supporting the protocol will then know what >> values to use? >> >> IIUC, the webrtc people are "humoring* us by making provision for >> registered subprotocol names, and using SDP to negotiate channels. I >> suspect that for the most part they have no intention of using those. >> (The subprotocol name is *optional*.) >> >> So these parameters are needed to properly initialize a channel when the >> subprotocol is not specified. > > [Raju] If I understand correctly, these parameters simply define the > data channel transport properties. Yes, they may have some correletion with > subprotocol, but that's not a one-to-one mapping. > For example, a given subprotocol could run on a reliable or > unreliable transport; depending on app needs it may use unreliable > transport and deal with reliablity at subprotocol stack (or ignore it). In some cases. But in general it is easy and common to define a protocol that needs a reliable transport, and it won't work without one. What if every application in the world that uses TCP had the option to specify if it was reliable or not? How many would screw it up? >> Also, we still have an open question about what attributes must be >> present in a subprotocol specification. It is at least possible that >> some subprotocols may work with a variety of settings of these attributes. > > [Raju] Right, this fits into my explanation above. > >> >> This draft should probably say more about this. It could say that: >> >> * the SDP MUST be consistent with the attributes specified in the >> subprotocol definition, OR >> >> * the SDP MUST NOT specify attributes specified in the subprotocol >> definition, OR >> >> * attributes specified in the SDP override those specified in the >> subprotocol definition. > > [Raju] Good point. I like item 1 above; sure we can add it to this > draft. Then individual subprotocol drafts > (e.g. draft-ejzak-dispatch-msrp-data-channel-00) could get into the > details of what that consistency is. Thanks, Paul From nobody Tue Feb 25 14:27: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 5F83E1A0298 for ; Tue, 25 Feb 2014 14:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, 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 wTjPxFW0SCGI for ; Tue, 25 Feb 2014 14:27:00 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 362791A079F for ; Tue, 25 Feb 2014 14:27:00 -0800 (PST) Received: from [192.168.1.103] (p508F31B7.dip0.t-ipconnect.de [80.143.49.183]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 61C271C1042E2; Tue, 25 Feb 2014 23:26:58 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <53077E7B.1070900@ericsson.com> Date: Tue, 25 Feb 2014 20:44:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <76FD47BE-EF7F-40C7-A574-FCF8C92E760F@lurchi.franken.de> References: <53077E7B.1070900@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tUJ-5v_y_kbTj8RkvryVsR2epbk Cc: "rtcweb@ietf.org" , draft-ietf-rtcweb-data-channel@tools.ietf.org Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 22:27:05 -0000 Hi Magnus, thank you very much for the detailed review. Please see my comments below. Best regards Michael On Feb 21, 2014, at 5:27 PM, Magnus Westerlund = wrote: > Hi, > (as individual) >=20 > I have reviewed the WebRTC Data Channels draft > (draft-ietf-rtcweb-data-channel-07) and have some comments. >=20 > 1. Section 1: > Non-media data types in the context of WebRTC are handled by using > SCTP [RFC4960] encapsulated in DTLS [RFC6347]. >=20 > There are many places in this draft where "media data" is a reference = to > the RTP transport media. I would suggest to review this and consider = to > change this to "RTP Transport media", or "RTP media". The reason is = that > I expect also real-time media to flow over the data channel. OK. Based on another suggestion on the mailing list, I use SRTP media. Although 'non SRTP media' looks strange... >=20 > 2. Section 1: > As the other SCTP extensions are discussed in the introduction, I = wonder > why NADA and PR-Policy isn't. most likely they were not required when this text was written... So I changed it to: SCTP as specified in with the partial = reliability extension defined in and the additional = policies defined in provides multiple streams natively with reliable, and the relevant=20 partially-reliable delivery modes for user messages. [...] Using allows to interleave large messages to avoid the monopolization and adds the support of prioritising of SCTP streams. >=20 > 3. Section 1: > Section 5 arguments SCTP over DTLS over UDP; >=20 > "arguments" looks strange in the above sentence fragment. Replaced by "discusses". >=20 > 4. Section 3.1: > Note that > at any time there may be no media channels, or all media > channels may be inactive, and that there may also be = reliable > data channels in use. >=20 > "no media channels" is a bit strange here as we not really call = anything > regarding RTP channels. I would suggest to change this to "RTP Packet > Streams" or "RTP Stream". According to the above change it reads now: Note that at any time there may be no SRTP media channels, or all SRTP = media channels may be inactive, and that there may also be reliable data = channels in use. >=20 > 5. Section 3.2: > U-C 7: Proxy browsing, where a browser uses data channels of a > PeerConnection to send and receive HTTP/HTTPS requests and > data, for example to avoid local Internet filtering or > monitoring. >=20 >> =46rom a data channel perspective this doesn't look strange at all, > however I get the shivers from the security implications of this. To = my > understanding Peer A using Peer B to proxy browse must have B fetch = all > elements that A needs into its sandbox and then transfer it to A over > the PeerConnections Data Channel. Thus, all you do are revealed to B, > massive privacy consideration. Or am I missing someway that A can = tunnel > its HTTP request through B without having B see the content of those > requests, I am especially concerned with HTTPS. >=20 > If this use case is going to stay, I do want some security = consideration > discussion around it. Lets discuss whether this will stay or not... I find it an interesting use case, would prefer to keep it, and would therefore prefer to deal with it appropriately in the security considerations. >=20 > 6. Section 5: > " o The congestion control is modifiable for integration with media > stream congestion control." >=20 > As this statement is only partial correct. There is no current = mechanism > to negotiate congestion control, nor does it exist any alternative > defined SCTP congestion control. Thus, I would like to have this > sentence modified. I am however not certain to what the authors = consider > important. It is the fact that it is possible in the future to define = a > new CC algorithm and use that? Correct. >=20 > 7. Section 5: > o provides privacy for the SCTP control information. >=20 > Is "privacy" really the right word here? Either being explicit, = "source > authentication, integrity and confidentiality" or something like = "security"? The bullet list focuses on the benefits of using SCTP/DTLS/UDP instead of DTLS/SCTP/UDP as indicated by the sentence before the bullet list. Source authentication and integrity for SCTP control information is also provided by DTLS/SCTP/UDP, since you can protect it by the AUTH = chunk. Privacy, however, for this information can't be provided by = DTLS/SCTP/UDP, since only the user data is encrypted. So I guess the bullet point as cited above is correct. >=20 > 8. section 5: >=20 > DTLS implementations used for this stack SHOULD support controlling > fields of the IP layer like the Don't Fragment (DF)-bit in case of > IPv4 and the Differentiated Services Code Point (DSCP) field = required > for supporting [I-D.ietf-rtcweb-qos]. >=20 > First of all this reference must be changed. What I am currently > uncertain of is what it should point on, most likely > draft-dhesikan-tsvwg-rtcweb-qos-04. But, I am not yet certain how the > scope is going to be divided between that document and > draft-ietf-rtcweb-transports. I think it is much better to move the DSCP text to I-D.ietf-tsvwg-sctp-dtls-encaps, where corresponding text regarding the = DF bit already exists and just get rid of the above paragraph. If OK, this might be a WG LC comment on I-D.ietf-tsvwg-sctp-dtls-encaps >=20 > 9. Section 5: >=20 > The initial Path MTU > at the IP layer MUST NOT exceed 1200 bytes for IPv4 and 1280 for > IPv6. >=20 > I have to say that I think MUST NOT in the above is to strict. I think > SHOULD NOT is appropriate. The reason is that a deployment may = actually > know that a larger initial MTU is better. This value may also change = due > to how the networks develop in the future. Changed. >=20 > 10. Section 5: >=20 > Since SCTP does not support the > negotiation of a congestion control algorithm yet, alternate > congestion controls SHOULD either only require a different sender > side behavior using existing information carried in the association > or need also specify a negotiation of of a congestion control > algorithm. >=20 > First of all I don't like the SHOULD in this sentence. >=20 > Secondly, I think we need to get a good agreement and statement what = to > do with SCTP's congestion control algorithm in the future. I don't = like > this statement saying basically agree on anything and use that. I = think > the IETF specification should specify something to use that we know is > safe to deploy. Thus, I would strongly prefer this to simply to be > changed to say that: We know we want a new congestion control that > better can handle interaction the the RTP packet streams and its > congestion control, but that will not be initially available. Thus use > the specified congestion control and consider these issues. And if a = new > CC algo becomes available that can be used and should be negotiated > between the endpoints somehow. The intention of the above sentence to make clear that such a CC can = either be a sender side only mechanism or needs to add negotiation within the association setup. Not more. Not less. This goes back to a discussion at an IETF session. For me the paragraph basically covers what you want. Could you be more specific, where you disagree? >=20 > 11. Section 6.1: > Once support for message interleaving as currently being discussed = in > [I-D.ietf-tsvwg-sctp-ndata] is available, it SHOULD be supported. >=20 > I don't know why you have formulated this, so awkward? NDATA is > currently listed as a normative reference. This document is going to ... put a consensus from an RTCWeb meeting into my words... > hand in the RFC-editor queue until it becomes available or an AD = orders > some rewriting. Thus, why not simply write a simpler statement making > clear that one SHOULD support it. OK. Makes sense to me. What about: The support for message interleaving as defined in SHOULD be used. >=20 > I would also note that there are disagreement between this and the = text > in Section 6.6.: >=20 > To overcome this > limitation, [I-D.ietf-tsvwg-sctp-ndata] defines an extension to > support message interleaving. Once this extension is available, it > MUST be used. >=20 > Thus pick the level of requirement and then simply state that with the > motivation why. Personally I think SHOULD would be acceptable. There = are > clear motivation why (in 6.6) why one SHOULD implelement it, and the > basic functionality is still there if it is not supported and its = usage > will be negotiated as SCTP association creation. OK. Changed to: To overcome this limitation, defines an extension to support message interleaving, which SHOULD be = used. So it is consistently SHOULD. The question is why SHOULD. So when not to use it? Currently the problem is the availability of stable code, but that is not an argument for a SHOULD vs. a MUST, right? >=20 > 12. Section 6.2: > Additionally, > the negotiation SHOULD include some type of congestion control > selection. >=20 > Another congestion control statement that I am not happy with. See = issue > 10. There is no default and it is also not clear on what to really > negotiate. The default is the standard one. Currently there is no other and there is no way for negotiation. So how to deal with it? Add a statement about the default? Or remove the negotiation now and add it to a document defining an alternate CC? >=20 > 13. Section 6.3: >=20 > SCTP defines a stream as a unidirectional logical channel existing > within an SCTP association one to another SCTP endpoint. >=20 > The "one" looks spurious. Removed. >=20 > 14. Section 6.4: > These priorities MUST NOT be strict priorities. >=20 > Ok, this is one part of the agreement from the earlier meeting. There > was also agreement on using weighted fair queuing to solve the > priorities. The inter stream priority handling needs much firmer > specification. My question: What are the requirements from user JS application. I would like to leave as much room as possible for implementing these requirements...So up to know I have heard non-strict priorities... This needs to be in tune with the W3C... >=20 > 15. Section 6.5: > "This can be based on the DTLS role (the client picks > even stream identifiers, the server odd stream identifiers) or done > in a different way." >=20 > This is very unclear and you can't know what will happen. I think it > would be better to say: Unless otherwise defined or negotiated, the > streams are picked based on th DTLS role. ... OK. It reads now: Unless otherwise defined or negotiated, the streams are picked based on the DTLS role (the client picks even stream identifiers, the server odd stream identifiers). >=20 > 16. Section 6.5: > "In addition to choosing a stream, the application SHOULD also > inform the protocol of the options to use for sending messages." >=20 > So what is the application, and what is the protocol in this sentence? Good question... The whole paragraph reads strange... So I changed its end to: [...] In addition to choosing a stream, the application SHOULD also determine = the the options to use for sending messages. The application MUST ensure in an application-specific manner that the application at the peer will also know selected stream to be used, and the options for sending data from that side. >=20 > 17. Section 7. >=20 > I find this insufficient. I would this section to answer the following > questions: >=20 > 1. Any security issues that arise from the combination of mechanism. > 2. Any significant issue that one needs to know about the behavior of > the mechanisms, any of the normative specs that should be highlighted? > 3. Clarification on what security properties one achieve with the > defined mechanism. Isn't/shouldn't all this be handled in the referenced documents? >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Tue Feb 25 14:27: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 B064F1A0298 for ; Tue, 25 Feb 2014 14:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_82=0.6, RP_MATCHES_RCVD=-0.547, 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 RFv9qYDoxK9J for ; Tue, 25 Feb 2014 14:27:05 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id A1E7F1A07C1 for ; Tue, 25 Feb 2014 14:27:01 -0800 (PST) Received: from [192.168.1.103] (p508F31B7.dip0.t-ipconnect.de [80.143.49.183]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D3A791C1042EC; Tue, 25 Feb 2014 23:26:59 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Tue, 25 Feb 2014 20:50:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53077E7B.1070900@ericsson.com> To: Barry Dingle X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Mr8k2isFYwhn6defJrFppZtvwQs Cc: "rtcweb@ietf.org" , draft-ietf-rtcweb-data-channel@tools.ietf.org Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 22:27:07 -0000 On Feb 23, 2014, at 10:54 AM, Barry Dingle wrote: > In reference to your first Section 1 comments, I agree that we need to = clearly differentiate the SRTP media and the SCTP media. (Note - SRTP - = not RTP !) I changed it to SRTP media... >=20 > I agree that there could be real-time media that can be sent over SCTP = Channels are still meet the criteria for 'real-time' as being 'received = within a few hundred milliseconds of being generated' - see WebRTC = Overview section 2.4.=20 >=20 > Maybe we need to differentiate the Channel types - and then refer to = the data going over those Channels. For instance,if we define "SRTP = Channels" and "SCTP Channels", we could then refer to 'SRTP Channel = media' which would have a specific meaning.=20 >=20 > The best place for the definition of SRTP Channel and SCTP Channel is = probably in the WebRTC Overview document.=20 I agree... Best regards Michael >=20 > Cheers, > /Barry Dingle >=20 >=20 >=20 > On Sat, Feb 22, 2014 at 3:27 AM, Magnus Westerlund = wrote: > Hi, > (as individual) >=20 > I have reviewed the WebRTC Data Channels draft > (draft-ietf-rtcweb-data-channel-07) and have some comments. >=20 > 1. Section 1: > Non-media data types in the context of WebRTC are handled by using > SCTP [RFC4960] encapsulated in DTLS [RFC6347]. >=20 > There are many places in this draft where "media data" is a reference = to > the RTP transport media. I would suggest to review this and consider = to > change this to "RTP Transport media", or "RTP media". The reason is = that > I expect also real-time media to flow over the data channel. >=20 > 2. Section 1: > As the other SCTP extensions are discussed in the introduction, I = wonder > why NADA and PR-Policy isn't. >=20 > 3. Section 1: > Section 5 arguments SCTP over DTLS over UDP; >=20 > "arguments" looks strange in the above sentence fragment. >=20 > 4. Section 3.1: > Note that > at any time there may be no media channels, or all media > channels may be inactive, and that there may also be = reliable > data channels in use. >=20 > "no media channels" is a bit strange here as we not really call = anything > regarding RTP channels. I would suggest to change this to "RTP Packet > Streams" or "RTP Stream". >=20 > 5. Section 3.2: > U-C 7: Proxy browsing, where a browser uses data channels of a > PeerConnection to send and receive HTTP/HTTPS requests and > data, for example to avoid local Internet filtering or > monitoring. >=20 > >=46rom a data channel perspective this doesn't look strange at all, > however I get the shivers from the security implications of this. To = my > understanding Peer A using Peer B to proxy browse must have B fetch = all > elements that A needs into its sandbox and then transfer it to A over > the PeerConnections Data Channel. Thus, all you do are revealed to B, > massive privacy consideration. Or am I missing someway that A can = tunnel > its HTTP request through B without having B see the content of those > requests, I am especially concerned with HTTPS. >=20 > If this use case is going to stay, I do want some security = consideration > discussion around it. >=20 > 6. Section 5: > " o The congestion control is modifiable for integration with media > stream congestion control." >=20 > As this statement is only partial correct. There is no current = mechanism > to negotiate congestion control, nor does it exist any alternative > defined SCTP congestion control. Thus, I would like to have this > sentence modified. I am however not certain to what the authors = consider > important. It is the fact that it is possible in the future to define = a > new CC algorithm and use that? >=20 > 7. Section 5: > o provides privacy for the SCTP control information. >=20 > Is "privacy" really the right word here? Either being explicit, = "source > authentication, integrity and confidentiality" or something like = "security"? >=20 > 8. section 5: >=20 > DTLS implementations used for this stack SHOULD support controlling > fields of the IP layer like the Don't Fragment (DF)-bit in case of > IPv4 and the Differentiated Services Code Point (DSCP) field = required > for supporting [I-D.ietf-rtcweb-qos]. >=20 > First of all this reference must be changed. What I am currently > uncertain of is what it should point on, most likely > draft-dhesikan-tsvwg-rtcweb-qos-04. But, I am not yet certain how the > scope is going to be divided between that document and > draft-ietf-rtcweb-transports. >=20 > 9. Section 5: >=20 > The initial Path MTU > at the IP layer MUST NOT exceed 1200 bytes for IPv4 and 1280 for > IPv6. >=20 > I have to say that I think MUST NOT in the above is to strict. I think > SHOULD NOT is appropriate. The reason is that a deployment may = actually > know that a larger initial MTU is better. This value may also change = due > to how the networks develop in the future. >=20 > 10. Section 5: >=20 > Since SCTP does not support the > negotiation of a congestion control algorithm yet, alternate > congestion controls SHOULD either only require a different sender > side behavior using existing information carried in the association > or need also specify a negotiation of of a congestion control > algorithm. >=20 > First of all I don't like the SHOULD in this sentence. >=20 > Secondly, I think we need to get a good agreement and statement what = to > do with SCTP's congestion control algorithm in the future. I don't = like > this statement saying basically agree on anything and use that. I = think > the IETF specification should specify something to use that we know is > safe to deploy. Thus, I would strongly prefer this to simply to be > changed to say that: We know we want a new congestion control that > better can handle interaction the the RTP packet streams and its > congestion control, but that will not be initially available. Thus use > the specified congestion control and consider these issues. And if a = new > CC algo becomes available that can be used and should be negotiated > between the endpoints somehow. >=20 > 11. Section 6.1: > Once support for message interleaving as currently being discussed = in > [I-D.ietf-tsvwg-sctp-ndata] is available, it SHOULD be supported. >=20 > I don't know why you have formulated this, so awkward? NDATA is > currently listed as a normative reference. This document is going to > hand in the RFC-editor queue until it becomes available or an AD = orders > some rewriting. Thus, why not simply write a simpler statement making > clear that one SHOULD support it. >=20 > I would also note that there are disagreement between this and the = text > in Section 6.6.: >=20 > To overcome this > limitation, [I-D.ietf-tsvwg-sctp-ndata] defines an extension to > support message interleaving. Once this extension is available, it > MUST be used. >=20 > Thus pick the level of requirement and then simply state that with the > motivation why. Personally I think SHOULD would be acceptable. There = are > clear motivation why (in 6.6) why one SHOULD implelement it, and the > basic functionality is still there if it is not supported and its = usage > will be negotiated as SCTP association creation. >=20 > 12. Section 6.2: > Additionally, > the negotiation SHOULD include some type of congestion control > selection. >=20 > Another congestion control statement that I am not happy with. See = issue > 10. There is no default and it is also not clear on what to really > negotiate. >=20 > 13. Section 6.3: >=20 > SCTP defines a stream as a unidirectional logical channel existing > within an SCTP association one to another SCTP endpoint. >=20 > The "one" looks spurious. >=20 > 14. Section 6.4: > These priorities MUST NOT be strict priorities. >=20 > Ok, this is one part of the agreement from the earlier meeting. There > was also agreement on using weighted fair queuing to solve the > priorities. The inter stream priority handling needs much firmer > specification. >=20 > 15. Section 6.5: > "This can be based on the DTLS role (the client picks > even stream identifiers, the server odd stream identifiers) or done > in a different way." >=20 > This is very unclear and you can't know what will happen. I think it > would be better to say: Unless otherwise defined or negotiated, the > streams are picked based on th DTLS role. ... >=20 > 16. Section 6.5: > "In addition to choosing a stream, the application SHOULD also > inform the protocol of the options to use for sending messages." >=20 > So what is the application, and what is the protocol in this sentence? >=20 > 17. Section 7. >=20 > I find this insufficient. I would this section to answer the following > questions: >=20 > 1. Any security issues that arise from the combination of mechanism. > 2. Any significant issue that one needs to know about the behavior of > the mechanisms, any of the normative specs that should be highlighted? > 3. Clarification on what security properties one achieve with the > defined mechanism. >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=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 Tue Feb 25 14:29: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 5E6201A0187 for ; Tue, 25 Feb 2014 14:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 znR3g6WosPRO for ; Tue, 25 Feb 2014 14:29:26 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 13D9F1A0790 for ; Tue, 25 Feb 2014 14:29:25 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-af-530d1944efa5 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 51.D1.23809.4491D035; Tue, 25 Feb 2014 23:29:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 23:29:23 +0100 From: Christer Holmberg To: Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: VS: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EP/+ONLQ//ubSND/9sNUAP/taKmw/9qUQQD/tRccgA== Date: Tue, 25 Feb 2014 22:29:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1BA5A7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> <530CCB54.4000106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1B9882@ESESSMB209.ericsson.se> <530D17B8.1070105@alum.mit.edu> In-Reply-To: <530D17B8.1070105@alum.mit.edu> 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+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvja6LJG+wQftzcYsVGw6wWqz9187u wOTx9/0HJo8lS34yBTBFcdmkpOZklqUW6dslcGXMX/eYseAie8Xyo1+ZGhj/s3YxcnJICJhI NDzYzQhhi0lcuLeerYuRi0NI4BCjxMJvz1lAEkICSxglrp8U72Lk4GATsJDo/qcNEhYR8JXo vXwOrFdYIFHizvnpzBDxJIl9fSdZIew6ibNTZoDZLAKqErvvzmcDsXmBeqeeu8EKsWsmm8SD O8fBmjkFdCSmn9nEBGIzAh30/dQaMJtZQFzi1pP5TBCHCkgs2XOeGcIWlXj5+B/UM0oSi25/ hqrXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkb23MTMnPRy o02MwFg4uOW36g7GO+dEDjFKc7AoifN+eOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoEx ZF2J+1ruvzrRoqrHLJtFTzhwx89yDWBuOXlX1KhXo7SuMqP9LyOTZ/IrEe53h3MXXr3cd9C5 7uaXv+JhiR1bEkRz6lJ97Eq0dk1MZXaTfxfTl7Ms/n7lwr3ChSbBrEFmlQcTisMDSu6F3Tnj 5v9hJweDWuuyB49v/+sp3dHwxWPhjklV0kosxRmJhlrMRcWJAKJvsxdTAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/T-pJz4TolhobEQxG5HvDFNIm39M Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 22:29:32 -0000 Hi, >>> So these parameters are needed to properly initialize a channel when=20 >>> the subprotocol is not specified. >> >> Why would someone NOT specify the subprotocol? > > Because there is no defined subprotocol for what they are doing? > > In the common webrtc use case with two browsers talking to the same web s= ervice, and the web=20 > service feeding the needed javascript to the browsers, they just "know" t= he protocol they are using. > So they may just "make it up", and have nothi= ng registered. > > It is when they need to interoperate with something else that it becomes = important to name and=20 > register the protocol. > >> Especially considering Richard's draft, I thought the whole idea was to = be able to negotiate the=20 >> subprotocol using SDP. > > That's for us, not them. :-) > > They will be using DCEP. Sure, but my question is about the usage of the attributes in SDP (Richard'= s draft). Regards, Christer From nobody Tue Feb 25 14:33: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 8DD221A079F for ; Tue, 25 Feb 2014 14:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_82=0.6, RP_MATCHES_RCVD=-0.547, 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 03uOiqLSNQUF for ; Tue, 25 Feb 2014 14:33:39 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id DFC691A079D for ; Tue, 25 Feb 2014 14:33:38 -0800 (PST) Received: from [192.168.1.103] (p508F31B7.dip0.t-ipconnect.de [80.143.49.183]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3FB631C0E97AE; Tue, 25 Feb 2014 23:33:37 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <530C7763.1030105@ericsson.com> Date: Tue, 25 Feb 2014 23:33:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53077E7B.1070900@ericsson.com> <530C7763.1030105@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/chekujj5lO3lebUvKyo9tE-xDkA Cc: "rtcweb@ietf.org" , draft-ietf-rtcweb-data-channel@tools.ietf.org Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 22:33:40 -0000 On Feb 25, 2014, at 11:58 AM, Magnus Westerlund = wrote: > On 2014-02-23 10:54, Barry Dingle wrote: >> In reference to your first _Section 1 comments_, I agree that we need = to >> clearly differentiate the SRTP media and the SCTP media. (Note - SRTP = - >> not RTP !) >=20 > So SRTP is an extension of RTP, in fact it is a profile, or rather two > (RTP/SAVP or RTP/SAVPF). I wrote RTP because I meant no specific RTP > configuration here, it can be any of the profiles and any of the > extensions. I know and fully support that RTCWEB uses RTP/SAVPF for = RTP > transported media, however in the wider context and possible other = usage > of the defined mechanism this may or may not be true. Therefore I see = a > need to be generic in that discussion. If one want to emphasize the = SRTP > part, then use (S)RTP. OK, I'll use (S)RTP media... Best regards Michael >=20 >>=20 >> I agree that there could be real-time media that can be sent over = SCTP >> Channels are still meet the criteria for 'real-time' as being = 'received >> within a few hundred milliseconds of being generated' - see WebRTC >> Overview section 2.4. >>=20 >> Maybe we need to differentiate the Channel types - and then refer to = the >> data going over those Channels. For instance,if we define "SRTP >> Channels" and "SCTP Channels", we could then refer to 'SRTP Channel >> media' which would have a specific meaning. >=20 > Well, around RTP we aren't discussing "channels" at all. Thus, this > becomes very ambiguous to what it means, unless you have a definition = to > go along with it. >=20 > In the context of a PeerConnection we can have one or more RTP = session. >=20 > Also, I don't know what an SCTP channel is. There is an SCTP > association, which is something between two endpoints. On top of this = we > have the SCTP Data channels. So what are you missing or want from = these > definitions? >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Feb 25 14:41: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 8884A1A02F4 for ; Tue, 25 Feb 2014 14:41:32 -0800 (PST) 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 ehrUI1P9F05l for ; Tue, 25 Feb 2014 14:41:29 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 4146C1A0338 for ; Tue, 25 Feb 2014 14:41:29 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by QMTA11.westchester.pa.mail.comcast.net with comcast id WbzW1n0051wpRvQ5BmhUBA; Tue, 25 Feb 2014 22:41:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id WmhT1n0193ZTu2S3emhUX3; Tue, 25 Feb 2014 22:41:28 +0000 Message-ID: <530D1C17.9020703@alum.mit.edu> Date: Tue, 25 Feb 2014 17:41:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "rtcweb@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> <530CCB54.4000106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1B9882@ESESSMB209.ericsson.se> <530D17B8.1070105@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1BA5A7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1BA5A7@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393368088; bh=/+FQS+qp86ZqoEtKMX8/cDC26jW5kdpVuI8E6mC2X6Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Jgb0Flf1OSkwVGxfMqKvKrF01S3P82/8N2ETif+jUvXhhOLpGG+i1AlmrL8ooIe2E mgSS0lJTcExh7r14FtZbcBLUEDo2x/7jj9Z8zr3jRi8tDVIqddlq9gA0qtpGYxAC+D +zD/an8wZKFJ4eS+DbTh6KiEMb/MUpvlT+2Q6cNh+hpXI+rUOUI4fdddcUJfgqQNIa Le3OzeUgLwpbGdmxOCMCu9VwAHEjgxX+nW93opti7sfpKThQQ2J/aNOdDBgTfIv2wA /nE2KXsiuIRUpzKvXTjMkeWZN3hnL8DTDlpqZLVrO/D6AtSw1LBtlAIw5rP42PJ1VC m3rPVyjtxbcWQ== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3XZ2p0en12oEycTrmNzLvyWlscg Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 22:41:32 -0000 On 2/25/14 5:29 PM, Christer Holmberg wrote: > Hi, > >>>> So these parameters are needed to properly initialize a channel when >>>> the subprotocol is not specified. >>> >>> Why would someone NOT specify the subprotocol? >> >> Because there is no defined subprotocol for what they are doing? >> >> In the common webrtc use case with two browsers talking to the same web service, and the web >> service feeding the needed javascript to the browsers, they just "know" the protocol they are using. > So they may just "make it up", and have nothing registered. >> >> It is when they need to interoperate with something else that it becomes important to name and >> register the protocol. >> >>> Especially considering Richard's draft, I thought the whole idea was to be able to negotiate the >>> subprotocol using SDP. >> >> That's for us, not them. :-) >> >> They will be using DCEP. > > Sure, but my question is about the usage of the attributes in SDP (Richard's draft). Are you then suggesting that the subprotocol MUST be supplied in the SDP? I think we need some careful consideration of what rules are common to all data channels, and which ones can be different when using SDP rather than DCEP. That should consider how something first built using DCEP can be migrated to using SDP when it is discovered that it needs to interoperate with a sip server. Unclear if that discussion should take place on rtcweb or mmusic. Thanks, Paul From nobody Tue Feb 25 14:42: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 B303C1A079D for ; Tue, 25 Feb 2014 14:42:23 -0800 (PST) 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, 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 LqNnVvMIvfKE for ; Tue, 25 Feb 2014 14:42:21 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9431F1A0338 for ; Tue, 25 Feb 2014 14:42:21 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:1075 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1WIQhg-00042J-Iq for rtcweb@ietf.org; Tue, 25 Feb 2014 16:42:20 -0600 Message-ID: <530D1C00.7080701@jesup.org> Date: Tue, 25 Feb 2014 17:41:04 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/M5poZTM5gL9FurzBqndXosnR5H4 Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 22:42:23 -0000 On 2/24/2014 10:21 AM, Christer Holmberg wrote: > > I still don't think the information belong to SDP - they define protocol characteristics. The protocol specification should define re-transmission timers etc. > > Anyway, we can argue about it later. At this moment I think the focus should be on whether to move forward with the mechanism to begin with, and the main feature of the mechanism - which is about negotiating usage of channels :) This (whether to move forward) is my concern (in addition to Mary's about this being the wrong group - MMUSIC is where the SDP should be and has been). The apparent justification for this document is "This document defines SDP-based out-of-band negotiation procedures to establish WebRTC data channels for transport of well-defined sub- protocols." This seems a pretty sparse justification. We very purposely avoided using SDP for channel setup (after MUCH discussion at Boston and elsewhere). That isn't to say that for non-webrtc usage, one could define an SDP used to externally-negotiate the settings for DataChannels, which this appears to be. But I think there should a clearer statement as to "why" we should invest the time to standardize this now, not just that we "can". For example, if CLUE really wants to use this instead of in-band opens, then maybe there's a reason to do so - but don't expect webrtc endpoints to implement this. And if so, it should be done in CLUE by request to MMUSIC. At this point I don't see need to move forward with this, and certainly not here. And I certainly don't want this to delay finalizing the stuff needed in MMUSIC for WebRTC use of DataChannels -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Tue Feb 25 14:55: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 48AE91A07C8 for ; Tue, 25 Feb 2014 14:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 QUNdop0vifdG for ; Tue, 25 Feb 2014 14:55:23 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9700D1A079F for ; Tue, 25 Feb 2014 14:55:18 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-c1-530d1f545527 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D0.FB.10875.45F1D035; Tue, 25 Feb 2014 23:55:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 23:55:16 +0100 From: Christer Holmberg To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzwgAIpVwD//+vjwA== Date: Tue, 25 Feb 2014 22:55:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1BA62A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <530D1C00.7080701@jesup.org> In-Reply-To: <530D1C00.7080701@jesup.org> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+JvjW6oPG+wwbanjBZnt2VZrP3Xzu7A 5LFkyU8mjw/L17EFMEVx2aSk5mSWpRbp2yVwZXRP+Mlc0CVcsWaVQwPjTv4uRk4OCQETiT2n exkhbDGJC/fWs3UxcnEICRxilDg68w4TSEJIYAmjxKyz7l2MHBxsAhYS3f+0QcIiAoESR393 sYPYwgKxEu2PdzBBxOMkHj3Yxg5hh0ns/vIDLM4ioCrx8uxisF28Ar4SP8++YocY38QsMfeR AIjNKaAp0TKxhw3EZgS65/upNWC9zALiEreezGeCuFNAYsme88wQtqjEy8f/WCFsJYkV2y8x QtTrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFSN7bmJmTnq5 4SZGYBQc3PJbdwfjqXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDo w7nmkanui3fTKvXbrfivhZi6BOtw+J5YGLlc337VUT4NixvlG99//XLu4sv7anL8t1lni1Ub L/U78I+nbv8iKf7rWblFDklc4gZrt8ockZ2SYPnXi/+dws3URd8DDk6+tWRSiXv2+ieSX+/M meCU+qI7eG2e5JkMNR5zoWfVZ1LXHcgzmp+rxFKckWioxVxUnAgAtn8pmVACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4Z7y90S-AQ8I9nXZ4rvbQ-_0iZ4 Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 22:55:26 -0000 Hi Randell, I am not sure whether an WebRTC endpoint (e.g. a browser) would have to imp= lement this. The JS Application can insert the information into the SDP bef= ore sending it out on the wire (in cases where SDP is used on the wire). Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Randell Jesup Sent: 26 February 2014 00:41 To: rtcweb@ietf.org Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-c= hannel-sdpneg-00 On 2/24/2014 10:21 AM, Christer Holmberg wrote: > > I still don't think the information belong to SDP - they define protocol = characteristics. The protocol specification should define re-transmission t= imers etc. > > Anyway, we can argue about it later. At this moment I think the focus=20 > should be on whether to move forward with the mechanism to begin with,=20 > and the main feature of the mechanism - which is about negotiating=20 > usage of channels :) This (whether to move forward) is my concern (in addition to Mary's about t= his being the wrong group - MMUSIC is where the SDP should be and has been)= . The apparent justification for this document is "This document defines SDP-= based out-of-band negotiation procedures to establish WebRTC data channels = for transport of well-defined sub- protocols." This seems a pretty sparse j= ustification. We very purposely avoided using SDP for channel setup (after MUCH discussio= n at Boston and elsewhere). That isn't to say that for non-webrtc usage, o= ne could define an SDP used to externally-negotiate the settings for DataCh= annels, which this appears to be. But I think there should a clearer state= ment as to "why" we should invest the time to standardize this now, not jus= t that we "can". For example, if CLUE really wants to use this instead of = in-band opens, then maybe there's a reason to do so - but don't expect webr= tc endpoints to implement this. =20 And if so, it should be done in CLUE by request to MMUSIC. At this point I don't see need to move forward with this, and certainly not= here. And I certainly don't want this to delay finalizing the stuff neede= d in MMUSIC for WebRTC use of DataChannels -- Randell Jesup -- rjesup a t mozilla d o t com _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Feb 25 14:59: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 098A71A033A for ; Tue, 25 Feb 2014 14:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 4kkr99CIMDJH for ; Tue, 25 Feb 2014 14:59:37 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4621A0338 for ; Tue, 25 Feb 2014 14:59:36 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-53-530d2056c7b5 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EB.34.23809.6502D035; Tue, 25 Feb 2014 23:59:34 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 23:59:33 +0100 From: Christer Holmberg To: Christer Holmberg , Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzwgAIpVwD//+vjwAAFQT74 Date: Tue, 25 Feb 2014 22:59:32 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <530D1C00.7080701@jesup.org>, <7594FB04B1934943A5C02806D1A2204B1D1BA62A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1BA62A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+JvjW6YAm+wwdXVQhZnt2VZrP3Xzu7A 5LFkyU8mjw/L17EFMEVx2aSk5mSWpRbp2yVwZXRtX8dWcFi0Yu7BKYwNjPsFuxg5OSQETCQu 3d3BBmGLSVy4tx7I5uIQEjjEKPF3yX5GCGcJo8S738eBMhwcbAIWEt3/tEHiIgKtjBJXV0xm BekWFoiVONiylRHEFhGIk3j0YBs7hB0l0fUBIs4ioCpx+N0sMJtXwE1ibksDM8SCI8wSLedn sYIs4BTwk7i0JA6khhHoou+n1jCB2MwC4hK3nsxngrhUQGLJnvPMELaoxMvH/1ghanQkFuz+ xAZha0ssW/iaGWKXoMTJmU9YJjCKzEIyahaSlllIWmYhaVnAyLKKkT03MTMnvdxoEyMw5A9u +a26g/HOOZFDjNIcLErivB/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYNzV/Jb7347a 3IcHz3940Sct7JB3avZta69ftTOj+pny1y8SuVRT/r20u51DIPhbo5NSgE+b68Vj253NSo6u 5Xx0abP4QsHZ+9k/7ndfY6H/TrypWVhkndbN/KMKAjKcMhH/F8g15WbJtwfOyN+0+u7W3/OU /h/YVPbnXtWWX1dmBn99VL/lvIkSS3FGoqEWc1FxIgDpzT0ORwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QIeUipp1Rvv0q_J9KkdRNdzS_-c Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 22:59:40 -0000 Anyhow, I agree we should move this discussion elsewhere. Regards, Christer Sent from my Sony Ericsson Xperia arc S Christer Holmberg wrote: Hi Randell, I am not sure whether an WebRTC endpoint (e.g. a browser) would have to imp= lement this. The JS Application can insert the information into the SDP bef= ore sending it out on the wire (in cases where SDP is used on the wire). Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Randell Jesup Sent: 26 February 2014 00:41 To: rtcweb@ietf.org Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-c= hannel-sdpneg-00 On 2/24/2014 10:21 AM, Christer Holmberg wrote: > > I still don't think the information belong to SDP - they define protocol = characteristics. The protocol specification should define re-transmission t= imers etc. > > Anyway, we can argue about it later. At this moment I think the focus > should be on whether to move forward with the mechanism to begin with, > and the main feature of the mechanism - which is about negotiating > usage of channels :) This (whether to move forward) is my concern (in addition to Mary's about t= his being the wrong group - MMUSIC is where the SDP should be and has been)= . The apparent justification for this document is "This document defines SDP-= based out-of-band negotiation procedures to establish WebRTC data channels = for transport of well-defined sub- protocols." This seems a pretty sparse j= ustification. We very purposely avoided using SDP for channel setup (after MUCH discussio= n at Boston and elsewhere). That isn't to say that for non-webrtc usage, o= ne could define an SDP used to externally-negotiate the settings for DataCh= annels, which this appears to be. But I think there should a clearer state= ment as to "why" we should invest the time to standardize this now, not jus= t that we "can". For example, if CLUE really wants to use this instead of = in-band opens, then maybe there's a reason to do so - but don't expect webr= tc endpoints to implement this. And if so, it should be done in CLUE by request to MMUSIC. At this point I don't see need to move forward with this, and certainly not= here. And I certainly don't want this to delay finalizing the stuff neede= d in MMUSIC for WebRTC use of DataChannels -- Randell Jesup -- rjesup a t mozilla d o t com _______________________________________________ rtcweb mailing 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 Feb 25 15:45: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 9ADE21A01E0 for ; Tue, 25 Feb 2014 15:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, 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 00EreHeIBv3P for ; Tue, 25 Feb 2014 15:44:50 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id BD40B1A01CB for ; Tue, 25 Feb 2014 15:44:49 -0800 (PST) Received: from [192.168.1.103] (p508F31B7.dip0.t-ipconnect.de [80.143.49.183]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 601811C0C0BF4 for ; Wed, 26 Feb 2014 00:44:48 +0100 (CET) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> Date: Wed, 26 Feb 2014 00:44:47 +0100 To: "rtcweb@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YlBUQUzvc1Moy_aio4XQBt3NzTo Subject: [rtcweb] Open data channel issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 23:44:53 -0000 Dear all, Magnus asked me to send a list of open issues regarding data channels to the list. Here is my current list: * Priority The W3C hasn't defined it yet. Neither for the (S)RTP media nor for = the data channels. We agreed on using a non strict policy for the data = channels (some sort of wighted fair queueing). That is all. * Protocol It seems not to be clear what needs to be provided when registering a (sub)-protocol at IANA. And the name of the registry is unclear... * SCTP parameters. There was discussed the issue how to set SCTP parameters, especially = path.max.retrans and association.max.retrans. Also HB.Interval might be of interest. RFC 4060 recommends path.max.retrans=3D5, association.max.retrans=3D10, = but has multihoming in mind. To avoid the dormant state, path.max.retrans =3D = association.max.retrans should be used. I would suggest 10 for this value. Should HEARTBEATs be disabled? * U-C 7: Proxy browsing * Alternate CC for SCTP Currently there is only the standard CC. However, in some places = negotiation of CC is mentioned. I'm currently going through the backlog of comments regarding the data = channels ID and I'll try to address the issues. If I find other issues, I send an = update to the above list. Best regards Michael From nobody Tue Feb 25 15:49: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 22DFF1A030E; Tue, 25 Feb 2014 15:49:20 -0800 (PST) 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 1F-y2RmQwFoJ; Tue, 25 Feb 2014 15:49:15 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 576671A07A3; Tue, 25 Feb 2014 15:49:14 -0800 (PST) Received: from [81.187.2.149] (port=47374 helo=[192.168.0.15]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WIRkG-0002ra-A0; Tue, 25 Feb 2014 23:49:09 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_B2EC0CF9-4C12-4B53-B965-573E2AE51D13" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Colin Perkins In-Reply-To: <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> Date: Tue, 25 Feb 2014 23:49:01 +0000 Message-Id: References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> To: Karl Stahl X-Mailer: Apple Mail (2.1874) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hbjY5fwJQHYWmmN_j6wpCXnxIlg Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [rtcweb] [tram] Payload Types assignments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Feb 2014 23:49:20 -0000 --Apple-Mail=_B2EC0CF9-4C12-4B53-B965-573E2AE51D13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Karl, I sympathise with your goal, but I really do not think RTP header = extensions are appropriate for this purpose. Ignoring the semantic mismatch, in order to identify an RTP header = extension, you need access to the signalling data, and if you have = access to the signalling, you can signal the QoS parameters without = using RTP.=20 You state that only the payload is encrypted in SRTP. That is not = necessarily true. RTP header extensions can be encrypted when RFC 6904 = is in use, and rtcweb-rtp-usage draft recommends this be done in some = cases. The signalling channel is also likely encrypted end-to-end in new = applications, so making it difficult to extract the information you need = to parse the RTP header extension, even if it is unencrypted.=20 Besides these focussed issues, I would also urge you to consider the = much broader comments Magnus made. The QoS problem is broad, and a point = solution based on RTP header extensions - even if it were workable, = which I doubt - would address only a small part of the problem space. Colin On 25 Feb 2014, at 01:45, Karl Stahl wrote: > Colin, > =20 > If the below were the case, it would be =93DPI guesswork=94 that I = also advice against. RTP doesn=92t even have unique protocol header = within UDP =96 it can even be confused with other UDP payload. > =20 > However, if the RTP is captured in a TURN-flow, as in TRAM Milestone = 3, the network point that this flow is directed to and can apply QoS = methods relevant to the network (which is not diffserve in Mobile OTT = and Cable Networks) has not a too difficult tasks. Linking each RTP-flow = by its ID and sequence number, and picking exactly the right traffic = type and bandwidth parameters is doable (see inline below, we at Ingate = do it already)! > =20 > Also DiffServ DSCP-bits are seldom maintained crossing network = boundaries, thus carrying no relevant information at the receiving end, = while the RTP extension header remains unchanged end-to-end. In = DSCP-bits, there is no bandwidth requirement information when entering = networks requiring reservation. That is always (and dynamically set) = available in the RTP extension header for each packet. > =20 > And, I am sure you are aware of the difficulties of getting DSCP-bits = through OS sockets, which is even worse with multiple streams over the = same UDP-port > =20 > Further, defining the QoS RTP extension header as in RFC5285, does not = in anyway conflict with other RTP extension headers or DSCP transfer or = settings. > =20 > /Karl > =20 > Fr=E5n: Colin Perkins [mailto:csp@csperkins.org]=20 > Skickat: den 24 februari 2014 23:52 > Till: Karl Stahl > Kopia: rtcweb@ietf.org; Magnus Westerlund; tram@ietf.org; Harald = Alvestrand > =C4mne: Re: [rtcweb] [tram] Payload Types assignments > =20 > Karl, > =20 > I strongly disagree with this suggestion. An RTP header extension, = located at an unknown and variable offset into a packet that does not = have a well-defined magic number in the header, > This is how to find the traffic info: > The payload of the classifier header extension element can be = encoded > using either the one-byte or two-byte header defined in [rfc5285] = and > shown below in Figure 1 and 2 below. > =20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ID | len=3D1 | Namespace | Value | 0 (pad) = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > Figure 1: Classifier Using the One-Byte Header > =20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ID | len=3D2 | Namespace | Value = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > =20 > Figure 2: Classifier Using the Two-Byte Header > =20 > indicated using a dynamically assigned identifier that is conveyed in = an out-of-band > --- It is the TURN flow!!! Requested by the ICE protocol for the = specific media to come! > and encrypted signalling channel, > --- Only the payload is encrypted in SRTP =96 leaving id, seq no and = header ext to be used as intended! > --- Thus being the appropriate place=85 > is not an appropriate place to put QoS information that has to be = processed on a per-packet basis. > If you want DiffServ, you know where to find it. > --- True, but if it cannot be used=85 > Colin > =20 > =20 > On 24 Feb 2014, at 22:09, Karl Stahl wrote: > I suggest to the RTCWEB WG that the below from the September and = October discussions on the relevant [rtcweb] [avtext] [mmusic] lists = http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is = introduced into draft-ietf-rtcweb-rtp-usage for usage of RFC 5285, to = allow: > =20 > (1) WebRTC applications to directly convey QoS related real-time = traffic info to the network at points where RTP flow is directed to by = TRAM Milstone 3, to be used by *any network element implementing any = suitable QoS methods for the particular network* for > (2) *all* WebRTC browsers *and* clients, under *all* OSs, and *all* = current and future IP network, to achieve best QoE > (3) *without* having to force WebRTC into application specific = networks (such as IMS) instead of using the Internet (including OTT). > =20 > The only further activity required, is to call for ISPs=92 to review = whether the traffic information transferred by RFC 5285 is sufficient = for current and future needs in their network as suggested in below = repeated = http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html > > =85two parameters (e.g. two bytes each) are encoded into the RTP = header extension: > =20 > A) The maximum bandwidth requirement: Two bytes could contain = everything from some bps for real-time text to Gbps for future 3D = supersize telepresence=85 on a logarithmic scale. > =20 > B) The quality characteristics for the stream, with the highest bit = set to 1, we could allocate a bit each for quality type e.g: > Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay = Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, = Prioritize X, Variation Y, that could be combined as required to = describe the stream. > =20 > And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the = individual bits. > > =20 > Then this could be assigned numbers to have an RFC in place. > =20 > With TRAM milestone 3 also place, > market forces will drive ISPs and browser makers to implement just = this, without even having it MUST-established. > =20 > =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and > =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. > =20 > Please see further emails soon following this one, for details and = history. > =20 > /Karl > =20 > =20 > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Karl Stahl > Skickat: den 22 oktober 2013 16:37 > Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus Westerlund' > Kopia: 'Colin Perkins' > =C4mne: [rtcweb] [avtext] Payload Types assignments was Re: SV: = [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 > =20 > Harald, I mostly agree with the quality requirements of different = real-time traffic that the WebRTC browser/application may use. But = rather than asking the application, let's convey the bandwidth and = priority requirements to the network. Just like with the Payload type = (that is hard to squeeze that information into) it must be visible to = the network (and not changed by the network, like diffserv bits are). = Such marking must also be available for incoming traffic, which is = especially important in RSVP type of networks, that has to reserve = bandwidth for it. =20 > =20 > There is actually a good way to show these needs to the network = (without using the PT, or diffserv bits, which aren=92t sufficient = anyway). > =20 > Let's use the RTP header extension field that also is visible outside = the encrypted payload. A week ago came = http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that = outlines the usage of the extension field for classification of traffic! = This document does not yet outline what to put in there and how to = encode it though. > =20 > Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 = discusses other webrtc usages of the RTP header extension in 5.2 (there = can be many header extensions according to RFC 5285) and in 9 there is = "WebRTC Use of RTP: Future Extensions". > =20 > So, it looks obvious to use the RTP header extension to show the = characteristics and bandwidth requirements to the network. It should not = introduce any backward incompatibilities either. > =20 > Such marking is done in every RTP packet so it can be set individually = for each stream and could even be changed during a session (e.g. when = limiting the bandwidth based on RTCP feedback). RFC 5286 also specifies = how RTP extension header usage can be negotiated in SDP. I think this = could be easily done by the WebRTC browser for "all current and future = needs" if properly specified now. > =20 > I suggest that two parameters (e.g. two bytes each) are encoded into = the RTP header extension: > =20 > A) The maximum bandwidth requirement: Two bytes could contain = everything from some bps for real-time text to Gbps for future 3D = supersize telepresence=85 on a logarithmic scale. > =20 > B) The quality characteristics for the stream, with the highest bit = set to 1, we could allocate a bit each quality e.g: > Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay = Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, = Prioritize X, Variation Y, that could be combined as required to = describe the stream. > =20 > And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the = individual bits. > =20 > Please note the totally different requirements a diffserv and an RSVP = network have to know, so let=92s put all into these bytes. (E.g. a = diffserv network don't need the bandwidth usage, but RSVP reservation = networks (e.g. cable and 3G/4G OTT) do. There one should initially = reserve the maximum bandwidth indicated, but can later re-reserve.) > =20 > /Karl > =20 > PS Microsoft seems to have done work in this field, defining a = proprietary attribute =93MS Service Quality=94; > However that seems to apply to the TURN server allocation request and = would therefore: > --- Apply to the whole UDP flow, and could not be set for each stream = individually (with different requirements), and > --- Does not handle the bandwidth requirement for incoming real-time = traffic (required to reserve in RSVP type of networks) > However the quality attributes conveyed and their encoding may be = considered. > =20 > This is 2.2.2.19 MS-Service Quality Attribute from > http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx=20= > =20 > MS-Service Quality Attribute > The MS-Service Quality attribute is used to convey information about = the data stream that the protocol client is intending to transfer over = an allocated port. The protocol client SHOULD<21> include this attribute = as part of an Allocate request message. A TURN server SHOULD use the = information in this attribute to make decisions about resource = allocation, bandwidth prioritization, and data delivery methods. If the = attribute is not present in the Allocate request message, the TURN = server SHOULD assume that the data stream is audio with best effort = delivery. The format of this attribute is as follows... > ... > The following stream types are supported in this extension. All other = stream types are reserved for future use. > =A7 "0x0001": Audio > =A7 "0x0002": Video > =A7 "0x0003": Supplemental Video > =A7 "0x0004": Data > Service Quality (2 bytes): The service quality level required by the = protocol client for the stream. > The following service quality levels are supported in this extension. = All other service quality levels are reserved for future use. > =A7 "0x0000": Best effort delivery. > =A7 "0x0001": Reliable delivery. > =20 > =20 > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Harald Alvestrand > Skickat: den 8 oktober 2013 13:01 > Till: rtcweb@ietf.org > =C4mne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] = WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 > =20 > On 10/08/2013 09:17 AM, Karl Stahl wrote: > > Hej Magnus, > >=20 > >> Also, are you really interested in knowing that it is VP9 vs H.264,=20= > >> isn't > > the questions this is video of this priority that is important? > >> I think you need to more carefully consider what are the goals you > >> try to > > achieve them. > >=20 > > Actually, my concern is to get an idea of the maximum bandwidth that > > could be required for a WebRTC (ICE) setup media flow. Both voice = and > > video should be prioritized over data (their individual priority is = of > > less importance as long as there is sufficient bandwidth for both). > =20 > You don't know that without knowing what the application is for. > In, for instance, a shooter game with voice backchannels, the movement = and event information (data) is MORE time sensitive than the voice data. > =20 > >=20 > > With diffserv you don=92t need to know the bandwidth requirement, = but=20 > > with RSVP reservation (like in cable and mobile networks) you need = to > > know how much to reserve. Voice is like 100's kbit/s, video VP8 or > > H.264 is like 3,5 mbps. > =20 > Again, without knowing the application, you don't know that. > The application could decide to use QCIF or HD, and the bandwidth = variation of screencast (semi-static with sudden, large changes) is = completely different from that of a talking head, which is again = completely different from a high-movement scene. > =20 > >=20 > > To add to the complication of codec variants, the video codecs in=20 > > question for WebRTC have variable bandwidth, and when there is a = poor=20 > > connection we see Chrome reducing the video window size to reduce = the bandwidth used... > >=20 > > I think the payload type field at best can reflect a maximum = bandwidth > > to initially reserve bandwidth for, and thereafter make new > > reservations if the bandwidth changes during the call. So could we > > change RTP to show maximum bandwidth instead of payload type in that > > field outside the encrypted payload :) ... Or maybe that is not a = joke? > =20 > I think these ruminations only lead to one conclusion: > =20 > You can't tell what the needed bandwidth is up front without asking = the application. > You can't tell what the right priority ranking is without asking the = application. > =20 > If you need to know the bandwidth or the priority up front, the = application has to tell you. Anything else is pure heuristics. > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > =20 > =20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ > =20 > =20 > =20 --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_B2EC0CF9-4C12-4B53-B965-573E2AE51D13 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Karl,

I sympathise with your = goal, but I really do not think RTP header extensions are appropriate = for this purpose.

Ignoring the semantic = mismatch, in order to identify an RTP header extension, you need access = to the signalling data, and if you have access to the signalling, you = can signal the QoS parameters without using = RTP. 

You state that only the payload is = encrypted in SRTP. That is not necessarily true. RTP header extensions = can be encrypted when RFC 6904 is in use, and rtcweb-rtp-usage draft = recommends this be done in some cases. The signalling channel is also = likely encrypted end-to-end in new applications, so making it difficult = to extract the information you need to parse the RTP header extension, = even if it is unencrypted. 

Besides these = focussed issues, I would also urge you to consider the much broader = comments Magnus made. The QoS problem is broad, and a point solution = based on RTP header extensions - even if it were workable, which I doubt = - would address only a small part of the problem = space.

Colin


<= div>

On 25 Feb 2014, at 01:45, Karl Stahl = <karl.stahl@intertex.se> = wrote:

Colin,

 

If the below were the case, it would be =93DPI = guesswork=94 that I also advice against. RTP doesn=92t even have unique = protocol header within UDP =96 it can even be confused with other UDP = payload.

 

However, if the RTP is captured in a TURN-flow, as in = TRAM Milestone 3, the network point that this flow is directed to and = can apply QoS methods relevant to the network (which is not diffserve in = Mobile OTT and Cable Networks) has not a too difficult tasks. Linking = each RTP-flow by its ID and sequence number, and picking exactly the = right traffic type and bandwidth parameters is doable (see inline below, = we at Ingate do it already)!

 

Also DiffServ DSCP-bits are seldom maintained crossing = network boundaries, thus carrying no relevant information at the = receiving end, while the RTP extension header remains unchanged = end-to-end. In DSCP-bits, there is no bandwidth requirement information = when entering networks requiring reservation. That is always (and = dynamically set) available in the RTP extension header for each = packet.

 

And, I am sure you are aware of the difficulties of = getting DSCP-bits through OS sockets, which is even worse with multiple = streams over the same UDP-port

 

Further, defining the QoS RTP extension header as in = RFC5285, does not in anyway conflict with other RTP extension headers or = DSCP transfer or settings.

 

/Karl

 

Fr=E5n: Colin Perkins [mailto:csp@csperkins.org] =
Skickat: den 24 februari 2014 23:52
Till: Karl = Stahl
Kopia: rtcweb@ietf.org; Magnus Westerlund; = tram@ietf.org; Harald = Alvestrand
=C4mne: Re: [rtcweb] [tram] Payload Types = assignments

 

Karl,

 

I strongly disagree with this suggestion. An RTP = header extension, located at an unknown and variable offset into a = packet that does not have a well-defined magic number in the header, =

This is how to find the traffic info:

   The payload of the classifier header extension = element can be encoded

   using either the one-byte or two-byte header = defined in [rfc5285] and

   shown below in Figure 1 and 2 = below.

 

      = 0            &= nbsp;      = 1            &= nbsp;      = 2            &= nbsp;      3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |  ID   | len=3D1 = |   Namespace   |    = Value      |    0 = (pad)    |

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

          &nb= sp;  Figure 1: Classifier Using the One-Byte = Header

 

      0     =             &n= bsp; 1          &nb= sp;        = 2            &= nbsp;      3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |      = ID       |    = len=3D2      |   = Namespace   |    = Value      |

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

          &nb= sp;  Figure 2: Classifier Using the Two-Byte = Header

 

indicated using a dynamically assigned identifier that is = conveyed in an out-of-band

--- It is the TURN flow!!! Requested by the ICE = protocol for the specific media to come!

and encrypted signalling = channel,

--- Only the payload is encrypted in SRTP =96 leaving = id, seq no and header ext to be used as = intended!

--- Thus being the appropriate = place=85

is not an appropriate place to put QoS information that = has to be processed on a per-packet basis.

If you want DiffServ, you know = where to find it.

--- True, = but if it cannot be used=85

Colin

 

 

On 24 Feb 2014, at 22:09, Karl Stahl <karl.stahl@intertex.se> = wrote:

I suggest to the RTCWEB WG that the below from the = September and October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = is introduced into draft-ietf-rtcweb-rtp-usage= for usage of RFC 5285, to = allow:

 

(1) WebRTC applications to directly convey QoS related = real-time traffic info to the network at points where RTP flow is = directed to by TRAM Milstone 3, to be used by *any network element = implementing any suitable QoS methods for the particular network* = for

(2) *all* WebRTC browsers *and* clients, = under *all* OSs, and *all* current and future IP network, = to achieve best QoE

(3) *without* having to force WebRTC into application specific = networks (such as IMS) instead of using the Internet (including = OTT).

 

The only further activity required, is to call for = ISPs=92 to review whether the traffic information transferred by RFC = 5285 is sufficient for current and future needs in their network as = suggested in below repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip>

=85two parameters (e.g. two bytes each) are encoded into the RTP = header extension:

 

A) The maximum bandwidth requirement: Two bytes could contain = everything from some bps for real-time text to Gbps for future 3D = supersize telepresence=85 on a logarithmic = scale.

 

B) The quality characteristics for the stream, with the highest = bit set to 1, we could allocate a bit each for quality type = e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay = Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, = Prioritize X, Variation Y, that could be combined as required to = describe the stream.

 

And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the = individual bits.

</snip>

 

Then this could be assigned numbers to have an RFC in = place.

 

With TRAM milestone 3 also place, =

market forces will drive ISPs and browser makers to = implement just this, without even having it = MUST-established.

 

=93Who does not want a =93WebRTC-Ready=94 Internet = access?=94 and

=93Who wants to use Chrome, if Firefox, Internet = Explorer or Safari comes with much better QoE?=94 and vice = versa.

 

Please see further emails soon following this one, for = details and history.

 

/Karl

 

 

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org= ] F=F6r Karl Stahl
Skickat: den 22 oktober 2013 = 16:37
Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus = Westerlund'
Kopia: 'Colin Perkins'
=C4mne: [rtcweb] = [avtext] Payload Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

Harald, I mostly agree with the quality requirements of = different real-time traffic that the WebRTC browser/application may use. = But rather than asking the application, let's convey the bandwidth and = priority requirements to the network. Just like with the Payload type = (that is hard to squeeze that information into) it must be visible to = the network (and not changed by the network, like diffserv bits are). = Such marking must also be available for incoming traffic, which is = especially important in RSVP type of networks, that has to reserve = bandwidth for it.  

 

There is actually a good = way to show these needs to the network (without using the PT, or = diffserv bits, which aren=92t sufficient anyway). =

 

Let's use the RTP header extension field that also is = visible outside the encrypted payload. A week ago came ht= tp://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 =  that outlines the usage of the extension field for classification = of traffic! This document does not yet outline what to put in there and = how to encode it though.

 

Today's http://= tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 discusses other = webrtc usages of the RTP header extension in 5.2 (there can be many = header extensions according to RFC 5285) and in 9 there is "WebRTC Use = of RTP: Future Extensions".

 

So, it looks obvious to use = the RTP header extension to show the characteristics and bandwidth = requirements to the network. It should not introduce any backward = incompatibilities either.

 

Such marking is done in = every RTP packet so it can be set individually for each stream and could = even be changed during a session (e.g. when limiting the bandwidth based = on RTCP feedback). RFC 5286 also specifies how RTP extension header = usage can be negotiated in SDP. I think this could be easily done by the = WebRTC browser for "all current and future needs" if properly specified = now.

 

I suggest that two parameters (e.g. two bytes each) are = encoded into the RTP header extension:

 

A) The maximum bandwidth = requirement: Two bytes could contain everything from some bps for = real-time text to Gbps for future 3D supersize telepresence=85 on a = logarithmic scale.

 

B) The quality characteristics for the stream, with the = highest bit set to 1, we could allocate a bit each quality = e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, = Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable = Delivery, Prioritize X, Variation Y, that could be combined as required = to describe the stream.

 

And with highest bit set to = 0, there could instead be a number for special usage that does not fit = the general description of the individual bits.

 

Please note the totally = different requirements a diffserv and an RSVP network have to know, so = let=92s put all into these bytes. (E.g. a diffserv network don't need = the bandwidth usage, but RSVP reservation networks (e.g. cable and 3G/4G = OTT) do. There one should initially reserve the maximum bandwidth = indicated, but can later re-reserve.)

 

/Karl

 

PS Microsoft= seems to have done work in this field, defining a proprietary attribute = =93MS Service Quality=94;

However = that seems to apply to the TURN server allocation request and would = therefore:

--- = Apply to the whole UDP flow, and could not be set for each stream = individually (with different requirements), and

--- = Does not handle the bandwidth requirement for incoming real-time traffic = (required to reserve in RSVP type of networks)

However = the quality attributes conveyed and their encoding may  be = considered.

 

This is = 2.2.2.19 MS-Service Quality Attribute from

http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx<= /a> 

 

MS-Servic= e Quality Attribute

The = MS-Service Quality attribute is used to convey information about the = data stream that the protocol client is intending to transfer over an = allocated port. The protocol client SHOULD<21> include this = attribute as part of an Allocate request message. A TURN server SHOULD = use the information in this attribute to make = decisions about resource allocation, bandwidth prioritization, and data = delivery methods. If the attribute is not present in the Allocate = request message, the TURN server SHOULD assume that the data stream is = audio with best effort delivery. The format of this attribute is as = follows...

...

The = following stream types are supported in this extension. All other stream = types are reserved for future use.

=A7 = "0x0001":= Audio

=A7 "0x0002":= Video

=A7 "0x0003":= Supplemental Video

=A7 = "0x0004":= Data

Service = Quality (2 bytes): The service quality level required by the protocol = client for the stream.

The = following service quality levels are supported in this extension. All = other service quality levels are reserved for future = use.

=A7 "0x0000":= Best effort delivery.

=A7 = "0x0001":= Reliable delivery.

 

 

-----Ursprungligt = meddelande-----

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org= ] F=F6r Harald Alvestrand

Skickat:= den 8 oktober 2013 13:01

Till: = rtcweb@ietf.org

=C4mne: Re: [rtcweb] Payload = Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

On 10/08/2013 09:17 AM, = Karl Stahl wrote:

> Hej Magnus,

> 

>> Also, are you = really interested in knowing that it is VP9 vs H.264, =

>> isn't

> the questions this is = video of this priority that is important?

>> I think you need to = more carefully consider what are the goals you

>> try = to

> achieve them.

> 

> Actually, my concern is = to get an idea of the maximum bandwidth that

> could be required for a = WebRTC (ICE) setup media flow. Both voice and

> video should be = prioritized over data (their individual priority is of =

> = less importance as long as there is sufficient bandwidth for = both).

 

You don't know that without knowing what the application = is for.

In, for instance, a shooter game with voice backchannels, = the movement and event information (data) is MORE time sensitive than = the voice data.

 

> 

> With diffserv you don=92t= need to know the bandwidth requirement, but

> with RSVP reservation = (like in cable and mobile networks) you need to

> know how much to = reserve. Voice is like 100's kbit/s, video VP8 or =

> = H.264 is like 3,5 mbps.

 

Again, without knowing the = application, you don't know that.

The application could decide = to use QCIF or HD, and the bandwidth variation of screencast = (semi-static with sudden, large changes) is completely different from = that of a talking head, which is again completely different from a = high-movement scene.

 

> 

> To add to the = complication of codec variants, the video codecs in =

> = question for WebRTC have variable bandwidth, and when there is a poor =

> = connection we see Chrome reducing the video window size to reduce the = bandwidth used...

> 

> I think the payload = type field at best can reflect a maximum bandwidth =

> = to initially reserve bandwidth for, and thereafter make new =

> = reservations if the bandwidth changes during the call. So could we =

> = change RTP to show maximum bandwidth instead of payload type in that =

> = field outside the encrypted payload :) ... Or maybe that is not a = joke?

 

I think these ruminations only lead to one = conclusion:

 

You can't tell what the needed bandwidth is up front = without asking the application.

You can't tell what the = right priority ranking is without asking the = application.

 

If you need to know the bandwidth or the priority up = front, the application has to tell you. Anything else is pure = heuristics.

 

_______________________________________________=

rtcweb mailing = list

rtcweb@ietf.org

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

 

 

-- 

Colin = Perkins

 

 

 




-- 
Colin Perkins



= --Apple-Mail=_B2EC0CF9-4C12-4B53-B965-573E2AE51D13-- From nobody Tue Feb 25 17: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 65FD81A07C2; Tue, 25 Feb 2014 17:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.048 X-Spam-Level: X-Spam-Status: No, score=-110.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 cxSYv_cbsDCK; Tue, 25 Feb 2014 17:05:42 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id D3B1C1A02B7; Tue, 25 Feb 2014 17:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=935; q=dns/txt; s=iport; t=1393376741; x=1394586341; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yNIMfGZtx/M87S1vSY2rtv3mckbqwIPScAeDpkRjC0Q=; b=GNlDzGs3ZLtwtLpQkSTSFSBWU6QrKg2GDd0FWWw+swdfdJ7Io13j4q7n EYbUnI7XCpa/s14Q2pW1KeipCAw7n2bm1WcKDHvitntpt2XRhdZgQ7zGB EQKFMJxm8ghNBR6wNEKn4F1mKGPTgfWJe5DxYHHDN2T0g48sBUbgdKzNO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAKo8DVOtJV2Y/2dsb2JhbABZgwaBEsEAgRYWdIIlAQEBAwF5BQsCAQg7CzIlAgQBDQWHfQjITxeOHTMHgySBFAEDiRGPJZIogW+BPoIq X-IronPort-AV: E=Sophos;i="4.97,543,1389744000"; d="scan'208";a="23188606" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 26 Feb 2014 01:05:38 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1Q15dO2015243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 01:05:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 19:05:38 -0600 From: "Cullen Jennings (fluffy)" To: Karl Stahl , IESG IESG Thread-Topic: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPMbSdf/e29IVb6Eq4DfCgCp5RAprHHxqA Date: Wed, 26 Feb 2014 01:05:38 +0000 Message-ID: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> In-Reply-To: <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.131] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <92E892439623E54DB28673572FBE9B78@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kvA0Z4KNuvUxIzJyUVPL5CcATiQ Cc: "tram@ietf.org" , Spencer Dawkins , "rtcweb@ietf.org" Subject: Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 01:05:45 -0000 On Feb 25, 2014, at 7:02 AM, Karl Stahl wrote: > To the TRAM WG and RTCWEB WG and ADs: > =20 > It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed an= d encouraged to route quality demanding WebRTC media into their IP pipes th= at are capable of transporting real-time traffic without quality issues, us= ing TURN servers. > =20 Reading the charter, the above is *not* at all a clear objective of the WG = (note I am not the chair of this WG or the responsible AD).=20 That said, I think you have pointed out this charter is abysmally vague - i= t does not say what the WG is not going to do. If I decided to do BGP for r= outing updates over TURN it would be within the scope of this charter.=20 My advice to the responsible AD is recharter this WG before IETF 90 or clos= e it. I would be glad to help write a charter that is not an infinite blank= cheque.=20 From nobody Tue Feb 25 17:08: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 65E781A081D; Tue, 25 Feb 2014 17:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 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.547, SPF_PASS=-0.001, 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 FyYRhFPCjTe1; Tue, 25 Feb 2014 17:08:10 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 250671A07E6; Tue, 25 Feb 2014 17:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1168; q=dns/txt; s=iport; t=1393376889; x=1394586489; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4Qs9+nTll9I033HCkpX0hQUbPUAzdcmj8dLGg2AZ5uE=; b=N5lGxS8zpkIFbHbCUFYd+v7U/1mYWf32n1gXsCgZfXKDOysGUH9sib60 KWJxF0meuqoJbBT3kVG+tsnqGXrIQa3KYAm4I+cePd0xzcZiZ3hCsgYTw T+1FC7kb7WLNwEvpXGGsjTB7/tqA8Zwsby52lSYZBL4Xdb7xhuAAJAaeQ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAIo9DVOtJV2Z/2dsb2JhbABZgwiBDbx7gRcWAXSDfQEBAQMBeRACAQgYIwsyJQIEAQ0Fh3wIwCUXjkEBARwzB4MjgRMBA4kLjwuSFIFtgT6BcTk X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208";a="303476557" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 26 Feb 2014 01:08:09 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1Q188Jb029714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 01:08:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 19:08:08 -0600 From: "Cullen Jennings (fluffy)" To: Karl Stahl , IESG IESG Thread-Topic: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPMbSdf/e29IVb6Eq4DfCgCp5RAprHHxqAgAAAs4A= Date: Wed, 26 Feb 2014 01:08:08 +0000 Message-ID: <6031F972-6ECA-4E56-A36C-E2F4A336B718@cisco.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.131] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8A70C41710040141BF2BD55E91D0D999@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5Fo8Z1zaAZgZwarDgHFCJL3I29w Cc: "rtcweb@ietf.org" , "tram@ietf.org" , Spencer Dawkins Subject: Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 01:08:15 -0000 resend because the IETF mail lists said I had to many people in the to line= =20 On Feb 26, 2014, at 9:05 AM, Cullen Jennings wrote: >=20 >=20 > On Feb 25, 2014, at 7:02 AM, Karl Stahl wrote: >=20 >> To the TRAM WG and RTCWEB WG and ADs: >>=20 >> It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed a= nd encouraged to route quality demanding WebRTC media into their IP pipes t= hat are capable of transporting real-time traffic without quality issues, u= sing TURN servers. >>=20 >=20 > Reading the charter, the above is *not* at all a clear objective of the W= G (note I am not the chair of this WG or the responsible AD).=20 >=20 > That said, I think you have pointed out this charter is abysmally vague -= it does not say what the WG is not going to do. If I decided to do BGP for= routing updates over TURN it would be within the scope of this charter.=20 >=20 > My advice to the responsible AD is recharter this WG before IETF 90 or cl= ose it. I would be glad to help write a charter that is not an infinite bla= nk cheque.=20 >=20 >=20 >=20 >=20 >=20 >=20 From nobody Tue Feb 25 17:08: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 819C41A0831; Tue, 25 Feb 2014 17:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 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.547, SPF_PASS=-0.001, 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 38nDPWu6tkvS; Tue, 25 Feb 2014 17:08:23 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id AC1491A0829; Tue, 25 Feb 2014 17:08:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1168; q=dns/txt; s=iport; t=1393376903; x=1394586503; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4Qs9+nTll9I033HCkpX0hQUbPUAzdcmj8dLGg2AZ5uE=; b=Wcdar7//LJrHkn6IceQ6MzmPjqFBAzxteBbpt0ALWB1ixx4Qbg8yR2MS iFtiSXQLSNh6dUbpiVTVQ+WnkJjM+hNvEi9zSjCWb+Nyxmw7WvUZfv98Z jcFvCArKUTKaSDOBVYGux2JutHQjPxt8UrAaeNA3inGgQHUdo2Amyyvjv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAEQ+DVOtJXG9/2dsb2JhbABZgwaBEsEAgRYWdIIlAQEBAwF5EAIBCBgjCzIlAgQBDQWHfQjITReNfwEBHDMHgySBFAEDiRGPJZIogW+BPoFxOQ X-IronPort-AV: E=Sophos;i="4.97,543,1389744000"; d="scan'208";a="306512571" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 26 Feb 2014 01:08:10 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1Q18AGn008805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 01:08:10 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 19:08:09 -0600 From: "Cullen Jennings (fluffy)" To: Karl Stahl , IESG IESG Thread-Topic: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPMbSdf/e29IVb6Eq4DfCgCp5RAprHHxqAgAAAtAA= Date: Wed, 26 Feb 2014 01:08:09 +0000 Message-ID: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.131] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <69D38DADC55F7E41B295F9A389A878BF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6MbS_JriQ2heqmuvYZlcs6lJGDI Cc: "rtcweb@ietf.org" , "tram@ietf.org" , Spencer Dawkins Subject: Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 01:08:27 -0000 resend because the IETF mail lists said I had to many people in the to line= =20 On Feb 26, 2014, at 9:05 AM, Cullen Jennings wrote: >=20 >=20 > On Feb 25, 2014, at 7:02 AM, Karl Stahl wrote: >=20 >> To the TRAM WG and RTCWEB WG and ADs: >>=20 >> It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed a= nd encouraged to route quality demanding WebRTC media into their IP pipes t= hat are capable of transporting real-time traffic without quality issues, u= sing TURN servers. >>=20 >=20 > Reading the charter, the above is *not* at all a clear objective of the W= G (note I am not the chair of this WG or the responsible AD).=20 >=20 > That said, I think you have pointed out this charter is abysmally vague -= it does not say what the WG is not going to do. If I decided to do BGP for= routing updates over TURN it would be within the scope of this charter.=20 >=20 > My advice to the responsible AD is recharter this WG before IETF 90 or cl= ose it. I would be glad to help write a charter that is not an infinite bla= nk cheque.=20 >=20 >=20 >=20 >=20 >=20 >=20 From nobody Tue Feb 25 19: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 3AB981A0268; Tue, 25 Feb 2014 19:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] 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 RFbE-E2-0y0x; Tue, 25 Feb 2014 19:48:58 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF9B1A0258; Tue, 25 Feb 2014 19:48:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 6A1A27C4EA3; Wed, 26 Feb 2014 04:48: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 DJjqyfYCr8UE; Wed, 26 Feb 2014 04:48:51 +0100 (CET) Received: from [172.20.4.61] (unknown [64.129.1.15]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3E85D7C4EA1; Wed, 26 Feb 2014 04:48:49 +0100 (CET) Message-ID: <530D641F.6010504@alvestrand.no> Date: Wed, 26 Feb 2014 04:48:47 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Colin Perkins , Karl Stahl References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------040103040302090507080803" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tSde6sXrDBEHMKzX_bF95apzsio Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [rtcweb] [tram] Payload Types assignments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 03:49:06 -0000 This is a multi-part message in MIME format. --------------040103040302090507080803 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Karl, what on Earth does TRAM milestone 3 have to do with whatever it is you're proposing? TRAM milestone 3 is: Sep 2014 - Send new proposed standard TURN server discovery mechanism for enterprises and ISPs to IESG There's no (zero, nada, none) mention of QoS within that charter. On 02/26/2014 12:49 AM, Colin Perkins wrote: > Karl, > > I sympathise with your goal, but I really do not think RTP header > extensions are appropriate for this purpose. > > Ignoring the semantic mismatch, in order to identify an RTP header > extension, you need access to the signalling data, and if you have > access to the signalling, you can signal the QoS parameters without > using RTP. > > You state that only the payload is encrypted in SRTP. That is not > necessarily true. RTP header extensions can be encrypted when RFC 6904 > is in use, and rtcweb-rtp-usage draft recommends this be done in some > cases. The signalling channel is also likely encrypted end-to-end in > new applications, so making it difficult to extract the information > you need to parse the RTP header extension, even if it is unencrypted. > > Besides these focussed issues, I would also urge you to consider the > much broader comments Magnus made. The QoS problem is broad, and a > point solution based on RTP header extensions - even if it were > workable, which I doubt - would address only a small part of the > problem space. > > Colin > > > > > On 25 Feb 2014, at 01:45, Karl Stahl > wrote: >> >> Colin, >> >> >> >> If the below were the case, it would be “DPI guesswork” that I also >> advice against. RTP doesn’t even have unique protocol header within >> UDP – it can even be confused with other UDP payload. >> >> >> >> However, if the RTP is captured in a TURN-flow, as in TRAM Milestone >> 3, the network point that this flow is directed to and can apply QoS >> methods relevant to the network (which is not diffserve in Mobile OTT >> and Cable Networks) has not a too difficult tasks. Linking each >> RTP-flow by its ID and sequence number, and picking exactly the right >> traffic type and bandwidth parameters is doable (see inline below, we >> at Ingate do it already)! >> >> >> >> Also DiffServ DSCP-bits are seldom maintained crossing network >> boundaries, thus carrying no relevant information at the receiving >> end, while the RTP extension header remains unchanged end-to-end. In >> DSCP-bits, there is no bandwidth requirement information when >> entering networks requiring reservation. That is always (and >> dynamically set) available in the RTP extension header for each packet. >> >> >> >> And, I am sure you are aware of the difficulties of getting DSCP-bits >> through OS sockets, which is even worse with multiple streams over >> the same UDP-port >> >> >> >> Further, defining the QoS RTP extension header as in RFC5285, does >> not in anyway conflict with other RTP extension headers or DSCP >> transfer or settings. >> >> >> >> /Karl >> >> >> >> *Från:*Colin Perkins [mailto:csp@csperkins.org] >> *Skickat:* den 24 februari 2014 23:52 >> *Till:* Karl Stahl >> *Kopia:* rtcweb@ietf.org ; Magnus Westerlund; >> tram@ietf.org ; Harald Alvestrand >> *Ämne:* Re: [rtcweb] [tram] Payload Types assignments >> >> >> >> Karl, >> >> >> >> I strongly disagree with this suggestion. An RTP header extension, >> located at an unknown and variable offset into a packet that does not >> have a well-defined magic number in the header, >> >> This is how to find the traffic info: >> >> The payload of the classifier header extension element can be encoded >> >> using either the one-byte or two-byte header defined in [rfc5285 >> ] and >> >> shown below in Figure 1 and 2 below. >> >> >> >> 0 1 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | ID | len=1 | Namespace | Value | 0 (pad) | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> Figure 1: Classifier Using the One-Byte Header >> >> >> >> 0 1 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | ID | len=2 | Namespace | Value | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> >> >> Figure 2: Classifier Using the Two-Byte Header >> >> >> >> indicated using a dynamically assigned identifier that is conveyed in >> an out-of-band >> >> --- It is the TURN flow!!! Requested by the ICE protocol for the >> specific media to come! >> >> and encrypted signalling channel, >> >> --- Only the payload is encrypted in SRTP – leaving id, seq no and >> header ext to be used as intended! >> >> --- Thus being the appropriate place… >> >> is not an appropriate place to put QoS information that has to be >> processed on a per-packet basis. >> >> If you want DiffServ, you know where to find it. >> >> --- True, but if it cannot be used… >> >> Colin >> >> >> >> >> >> On 24 Feb 2014, at 22:09, Karl Stahl > > wrote: >> >> I suggest to the RTCWEB WG that the below from the September and >> October discussions on the relevant [rtcweb] [avtext] >> [mmusic]lists >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html >> is introduced into draft-ietf-rtcweb-rtp-usage for usage of RFC >> 5285, to allow: >> >> >> >> (1) WebRTC applications to directly convey QoS related real-time >> traffic info to the network at points where RTP flow is directed >> to by TRAM Milstone 3, to be used by **any network element >> implementing any suitable QoS methods for the particular >> network** for >> >> (2) **all** WebRTC browsers **and** clients, under **all** OSs, >> and **all** current and future IP network, to achieve best QoE >> >> *(3) *without* *having to force WebRTC into application specific >> networks (such as IMS) instead of using the Internet (including OTT). >> >> >> >> The only further activity required, is to call for ISPs’ to >> review whether the traffic information transferred by RFC 5285 is >> sufficient for current and future needs in their network as >> suggested in below repeated >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html >> >> >> >> …two parameters (e.g. two bytes each) are encoded into the RTP >> header extension: >> >> >> >> A) The maximum bandwidth requirement: Two bytes could contain >> everything from some bps for real-time text to Gbps for future 3D >> supersize telepresence… on a logarithmic scale. >> >> >> >> B) The quality characteristics for the stream, with the highest >> bit set to 1, we could allocate a bit each for quality type e.g: >> >> Best Effort, Audio, Video, Supplemental Video, Gaming, Data, >> Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable >> Delivery, Prioritize X, Variation Y, that could be combined as >> required to describe the stream. >> >> >> >> And with highest bit set to 0, there could instead be a number >> for special usage that does not fit the general description of >> the individual bits. >> >> >> >> >> >> Then this could be assigned numbers to have an RFC in place. >> >> >> >> With TRAM milestone 3 also place, >> >> market forces will drive ISPs and browser makers to implement >> just this, without even having it MUST-established. >> >> >> >> “Who does not want a “WebRTC-Ready” Internet access?” and >> >> “Who wants to use Chrome, if Firefox, Internet Explorer or Safari >> comes with much better QoE?” and vice versa. >> >> >> >> Please see further emails soon following this one, for details >> and history. >> >> >> >> /Karl >> >> >> >> >> >> *Från:*rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] *För *Karl Stahl >> *Skickat:* den 22 oktober 2013 16:37 >> *Till:* 'Harald Alvestrand'; rtcweb@ietf.org >> ; 'Magnus Westerlund' >> *Kopia:* 'Colin Perkins' >> *Ämne:* [rtcweb] [avtext] Payload Types assignments was Re: SV: >> [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 >> >> >> >> Harald, I mostly agree with the quality requirements of different >> real-time traffic that the WebRTC browser/application may use. >> But rather than asking the application, let's convey the >> bandwidth and priority requirements to the network. Just like >> with the Payload type (that is hard to squeeze that information >> into) it must be visible to the network (and not changed by the >> network, like diffserv bits are). Such marking must also be >> available for incoming traffic, which is especially important in >> RSVP type of networks, that has to reserve bandwidth for it. >> >> >> >> There is actually a good way to show these needs to the network >> (without using the PT, or diffserv bits, which aren’t sufficient >> anyway). >> >> >> >> Let's use the RTP header extension field that also is visible >> outside the encrypted payload. A week ago came >> http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 >> that outlines the usage of the extension field for >> classification of traffic! This document does not yet outline >> what to put in there and how to encode it though. >> >> >> >> Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 >> discusses other webrtc usages of the RTP header extension in 5.2 >> (there can be many header extensions according to RFC 5285) and >> in 9 there is "WebRTC Use of RTP: Future Extensions". >> >> >> >> So, it looks obvious to use the RTP header extension to show the >> characteristics and bandwidth requirements to the network. It >> should not introduce any backward incompatibilities either. >> >> >> >> Such marking is done in every RTP packet so it can be set >> individually for each stream and could even be changed during a >> session (e.g. when limiting the bandwidth based on RTCP >> feedback). RFC 5286 also specifies how RTP extension header usage >> can be negotiated in SDP. I think this could be easily done by >> the WebRTC browser for "all current and future needs" if properly >> specified now. >> >> >> >> I suggest that two parameters (e.g. two bytes each) are encoded >> into the RTP header extension: >> >> >> >> A) The maximum bandwidth requirement: Two bytes could contain >> everything from some bps for real-time text to Gbps for future 3D >> supersize telepresence… on a logarithmic scale. >> >> >> >> B) The quality characteristics for the stream, with the highest >> bit set to 1, we could allocate a bit each quality e.g: >> >> Best Effort, Audio, Video, Supplemental Video, Gaming, Data, >> Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable >> Delivery, Prioritize X, Variation Y, that could be combined as >> required to describe the stream. >> >> >> >> And with highest bit set to 0, there could instead be a number >> for special usage that does not fit the general description of >> the individual bits. >> >> >> >> Please note the totally different requirements a diffserv and an >> RSVP network have to know, so let’s put all into these bytes. >> (E.g. a diffserv network don't need the bandwidth usage, but RSVP >> reservation networks (e.g. cable and 3G/4G OTT) do. There one >> should initially reserve the maximum bandwidth indicated, but can >> later re-reserve.) >> >> >> >> /Karl >> >> >> >> PS Microsoft seems to have done work in this field, defining a >> proprietary attribute “MS Service Quality”; >> >> However that seems to apply to the TURN server allocation request >> and would therefore: >> >> --- Apply to the whole UDP flow, and could not be set for each >> stream individually (with different requirements), and >> >> --- Does not handle the bandwidth requirement for incoming >> real-time traffic (required to reserve in RSVP type of networks) >> >> However the quality attributes conveyed and their encoding may >> be considered. >> >> >> >> This is 2.2.2.19 MS-Service Quality Attribute from >> >> http://msdn.microsoft.com/en-us/library/cc431507(v=office.12).aspx >> >> >> >> /MS-Service Quality Attribute/ >> >> /The MS-Service Quality attribute is used to convey information >> about the data stream that the protocol client is intending to >> transfer over an allocated port. The protocol client SHOULD<21> >> include this attribute as part of an Allocate request message. A >> TURN server SHOULD use the information in this attribute to make >> decisions about resource allocation, bandwidth prioritization, >> and data delivery methods. If the attribute is not present in the >> Allocate request message, the TURN server SHOULD assume that the >> data stream is audio with best effort delivery. The format of >> this attribute is as follows... / >> >> /.../ >> >> /The following stream types are supported in this extension. All >> other stream types are reserved for future use./ >> >> /§ //"0x0001": Audio/ >> >> /§ //"0x0002": Video/ >> >> /§ //"0x0003": Supplemental Video/ >> >> /§ //"0x0004": Data/ >> >> /Service Quality (2 bytes): The service quality level required by >> the protocol client for the stream./ >> >> /The following service quality levels are supported in this >> extension. All other service quality levels are reserved for >> future use./ >> >> /§ //"0x0000": Best effort delivery./ >> >> /§ //"0x0001": Reliable delivery./ >> >> >> >> >> >> -----Ursprungligt meddelande----- >> >> Från: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] För Harald Alvestrand >> >> Skickat: den 8 oktober 2013 13:01 >> >> Till: rtcweb@ietf.org >> >> Ämne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] >> WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 >> >> >> >> On 10/08/2013 09:17 AM, Karl Stahl wrote: >> >> > Hej Magnus, >> >> > >> >> >> Also, are you really interested in knowing that it is VP9 vs H.264, >> >> >> isn't >> >> > the questions this is video of this priority that is important? >> >> >> I think you need to more carefully consider what are the goals you >> >> >> try to >> >> > achieve them. >> >> > >> >> > Actually, my concern is to get an idea of the maximum bandwidth >> that >> >> > could be required for a WebRTC (ICE) setup media flow. Both >> voice and >> >> > video should be prioritized over data (their individual priority >> is of >> >> > less importance as long as there is sufficient bandwidth for both). >> >> >> >> You don't know that without knowing what the application is for. >> >> In, for instance, a shooter game with voice backchannels, the >> movement and event information (data) is MORE time sensitive than >> the voice data. >> >> >> >> > >> >> > With diffserv you don’t need to know the bandwidth requirement, but >> >> > with RSVP reservation (like in cable and mobile networks) you >> need to >> >> > know how much to reserve. Voice is like 100's kbit/s, video VP8 or >> >> > H.264 is like 3,5 mbps. >> >> >> >> Again, without knowing the application, you don't know that. >> >> The application could decide to use QCIF or HD, and the bandwidth >> variation of screencast (semi-static with sudden, large changes) >> is completely different from that of a talking head, which is >> again completely different from a high-movement scene. >> >> >> >> > >> >> > To add to the complication of codec variants, the video codecs in >> >> > question for WebRTC have variable bandwidth, and when there is a >> poor >> >> > connection we see Chrome reducing the video window size to >> reduce the bandwidth used... >> >> > >> >> > I think the payload type field at best can reflect a maximum >> bandwidth >> >> > to initially reserve bandwidth for, and thereafter make new >> >> > reservations if the bandwidth changes during the call. So could we >> >> > change RTP to show maximum bandwidth instead of payload type in >> that >> >> > field outside the encrypted payload :) ... Or maybe that is not >> a joke? >> >> >> >> I think these ruminations only lead to one conclusion: >> >> >> >> You can't tell what the needed bandwidth is up front without >> asking the application. >> >> You can't tell what the right priority ranking is without asking >> the application. >> >> >> >> If you need to know the bandwidth or the priority up front, the >> application has to tell you. Anything else is pure heuristics. >> >> >> >> _______________________________________________ >> >> rtcweb mailing list >> >> rtcweb@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> >> >> -- >> >> Colin Perkins >> >> http://csperkins.org/ >> >> >> >> >> >> >> > > > > -- > Colin Perkins > http://csperkins.org/ > > > -- Surveillance is pervasive. Go Dark. --------------040103040302090507080803 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Karl,

what on Earth does TRAM milestone 3 have to do with whatever it is you're proposing?

TRAM milestone 3 is:

Sep 2014 - Send new proposed standard TURN server discovery mechanism for enterprises and ISPs to IESG

There's no (zero, nada, none) mention of QoS within that charter.


On 02/26/2014 12:49 AM, Colin Perkins wrote:
Karl,

I sympathise with your goal, but I really do not think RTP header extensions are appropriate for this purpose.

Ignoring the semantic mismatch, in order to identify an RTP header extension, you need access to the signalling data, and if you have access to the signalling, you can signal the QoS parameters without using RTP. 

You state that only the payload is encrypted in SRTP. That is not necessarily true. RTP header extensions can be encrypted when RFC 6904 is in use, and rtcweb-rtp-usage draft recommends this be done in some cases. The signalling channel is also likely encrypted end-to-end in new applications, so making it difficult to extract the information you need to parse the RTP header extension, even if it is unencrypted. 

Besides these focussed issues, I would also urge you to consider the much broader comments Magnus made. The QoS problem is broad, and a point solution based on RTP header extensions - even if it were workable, which I doubt - would address only a small part of the problem space.

Colin




On 25 Feb 2014, at 01:45, Karl Stahl <karl.stahl@intertex.se> wrote:

Colin,

 

If the below were the case, it would be “DPI guesswork” that I also advice against. RTP doesn’t even have unique protocol header within UDP – it can even be confused with other UDP payload.

 

However, if the RTP is captured in a TURN-flow, as in TRAM Milestone 3, the network point that this flow is directed to and can apply QoS methods relevant to the network (which is not diffserve in Mobile OTT and Cable Networks) has not a too difficult tasks. Linking each RTP-flow by its ID and sequence number, and picking exactly the right traffic type and bandwidth parameters is doable (see inline below, we at Ingate do it already)!

 

Also DiffServ DSCP-bits are seldom maintained crossing network boundaries, thus carrying no relevant information at the receiving end, while the RTP extension header remains unchanged end-to-end. In DSCP-bits, there is no bandwidth requirement information when entering networks requiring reservation. That is always (and dynamically set) available in the RTP extension header for each packet.

 

And, I am sure you are aware of the difficulties of getting DSCP-bits through OS sockets, which is even worse with multiple streams over the same UDP-port

 

Further, defining the QoS RTP extension header as in RFC5285, does not in anyway conflict with other RTP extension headers or DSCP transfer or settings.

 

/Karl

 

Från: Colin Perkins [mailto:csp@csperkins.org]
Skickat: den 24 februari 2014 23:52
Till: Karl Stahl
Kopia: rtcweb@ietf.org; Magnus Westerlund; tram@ietf.org; Harald Alvestrand
Ämne: Re: [rtcweb] [tram] Payload Types assignments

 

Karl,

 

I strongly disagree with this suggestion. An RTP header extension, located at an unknown and variable offset into a packet that does not have a well-defined magic number in the header,

This is how to find the traffic info:

   The payload of the classifier header extension element can be encoded

   using either the one-byte or two-byte header defined in [rfc5285] and

   shown below in Figure 1 and 2 below.

 

      0                   1                   2                   3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |  ID   | len=1 |   Namespace   |    Value      |    0 (pad)    |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

             Figure 1: Classifier Using the One-Byte Header

 

      0                   1                   2                   3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |      ID       |    len=2      |   Namespace   |    Value      |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

             Figure 2: Classifier Using the Two-Byte Header

 

indicated using a dynamically assigned identifier that is conveyed in an out-of-band

--- It is the TURN flow!!! Requested by the ICE protocol for the specific media to come!

and encrypted signalling channel,

--- Only the payload is encrypted in SRTP – leaving id, seq no and header ext to be used as intended!

--- Thus being the appropriate place…

is not an appropriate place to put QoS information that has to be processed on a per-packet basis.

If you want DiffServ, you know where to find it.

--- True, but if it cannot be used…

Colin

 

 

On 24 Feb 2014, at 22:09, Karl Stahl <karl.stahl@intertex.se> wrote:

I suggest to the RTCWEB WG that the below from the September and October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is introduced into draft-ietf-rtcweb-rtp-usage for usage of RFC 5285, to allow:

 

(1) WebRTC applications to directly convey QoS related real-time traffic info to the network at points where RTP flow is directed to by TRAM Milstone 3, to be used by *any network element implementing any suitable QoS methods for the particular network* for

(2) *all* WebRTC browsers *and* clients, under *all* OSs, and *all* current and future IP network, to achieve best QoE

(3) *without* having to force WebRTC into application specific networks (such as IMS) instead of using the Internet (including OTT).

 

The only further activity required, is to call for ISPs’ to review whether the traffic information transferred by RFC 5285 is sufficient for current and future needs in their network as suggested in below repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip>

…two parameters (e.g. two bytes each) are encoded into the RTP header extension:

 

A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence… on a logarithmic scale.

 

B) The quality characteristics for the stream, with the highest bit set to 1, we could allocate a bit each for quality type e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to describe the stream.

 

And with highest bit set to 0, there could instead be a number for special usage that does not fit the general description of the individual bits.

</snip>

 

Then this could be assigned numbers to have an RFC in place.

 

With TRAM milestone 3 also place,

market forces will drive ISPs and browser makers to implement just this, without even having it MUST-established.

 

“Who does not want a “WebRTC-Ready” Internet access?” and

“Who wants to use Chrome, if Firefox, Internet Explorer or Safari comes with much better QoE?” and vice versa.

 

Please see further emails soon following this one, for details and history.

 

/Karl

 

 

Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Karl Stahl
Skickat: den 22 oktober 2013 16:37
Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus Westerlund'
Kopia: 'Colin Perkins'
Ämne: [rtcweb] [avtext] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

 

Harald, I mostly agree with the quality requirements of different real-time traffic that the WebRTC browser/application may use. But rather than asking the application, let's convey the bandwidth and priority requirements to the network. Just like with the Payload type (that is hard to squeeze that information into) it must be visible to the network (and not changed by the network, like diffserv bits are). Such marking must also be available for incoming traffic, which is especially important in RSVP type of networks, that has to reserve bandwidth for it.  

 

There is actually a good way to show these needs to the network (without using the PT, or diffserv bits, which aren’t sufficient anyway).

 

Let's use the RTP header extension field that also is visible outside the encrypted payload. A week ago came http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00  that outlines the usage of the extension field for classification of traffic! This document does not yet outline what to put in there and how to encode it though.

 

Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 discusses other webrtc usages of the RTP header extension in 5.2 (there can be many header extensions according to RFC 5285) and in 9 there is "WebRTC Use of RTP: Future Extensions".

 

So, it looks obvious to use the RTP header extension to show the characteristics and bandwidth requirements to the network. It should not introduce any backward incompatibilities either.

 

Such marking is done in every RTP packet so it can be set individually for each stream and could even be changed during a session (e.g. when limiting the bandwidth based on RTCP feedback). RFC 5286 also specifies how RTP extension header usage can be negotiated in SDP. I think this could be easily done by the WebRTC browser for "all current and future needs" if properly specified now.

 

I suggest that two parameters (e.g. two bytes each) are encoded into the RTP header extension:

 

A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence… on a logarithmic scale.

 

B) The quality characteristics for the stream, with the highest bit set to 1, we could allocate a bit each quality e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to describe the stream.

 

And with highest bit set to 0, there could instead be a number for special usage that does not fit the general description of the individual bits.

 

Please note the totally different requirements a diffserv and an RSVP network have to know, so let’s put all into these bytes. (E.g. a diffserv network don't need the bandwidth usage, but RSVP reservation networks (e.g. cable and 3G/4G OTT) do. There one should initially reserve the maximum bandwidth indicated, but can later re-reserve.)

 

/Karl

 

PS Microsoft seems to have done work in this field, defining a proprietary attribute “MS Service Quality”;

However that seems to apply to the TURN server allocation request and would therefore:

--- Apply to the whole UDP flow, and could not be set for each stream individually (with different requirements), and

--- Does not handle the bandwidth requirement for incoming real-time traffic (required to reserve in RSVP type of networks)

However the quality attributes conveyed and their encoding may  be considered.

 

This is 2.2.2.19 MS-Service Quality Attribute from

http://msdn.microsoft.com/en-us/library/cc431507(v=office.12).aspx 

 

MS-Service Quality Attribute

The MS-Service Quality attribute is used to convey information about the data stream that the protocol client is intending to transfer over an allocated port. The protocol client SHOULD<21> include this attribute as part of an Allocate request message. A TURN server SHOULD use the information in this attribute to make decisions about resource allocation, bandwidth prioritization, and data delivery methods. If the attribute is not present in the Allocate request message, the TURN server SHOULD assume that the data stream is audio with best effort delivery. The format of this attribute is as follows...

...

The following stream types are supported in this extension. All other stream types are reserved for future use.

§ "0x0001": Audio

§ "0x0002": Video

§ "0x0003": Supplemental Video

§ "0x0004": Data

Service Quality (2 bytes): The service quality level required by the protocol client for the stream.

The following service quality levels are supported in this extension. All other service quality levels are reserved for future use.

§ "0x0000": Best effort delivery.

§ "0x0001": Reliable delivery.

 

 

-----Ursprungligt meddelande-----

Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Harald Alvestrand

Skickat: den 8 oktober 2013 13:01

Till: rtcweb@ietf.org

Ämne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

 

On 10/08/2013 09:17 AM, Karl Stahl wrote:

> Hej Magnus,

> 

>> Also, are you really interested in knowing that it is VP9 vs H.264,

>> isn't

> the questions this is video of this priority that is important?

>> I think you need to more carefully consider what are the goals you

>> try to

> achieve them.

> 

> Actually, my concern is to get an idea of the maximum bandwidth that

> could be required for a WebRTC (ICE) setup media flow. Both voice and

> video should be prioritized over data (their individual priority is of

> less importance as long as there is sufficient bandwidth for both).

 

You don't know that without knowing what the application is for.

In, for instance, a shooter game with voice backchannels, the movement and event information (data) is MORE time sensitive than the voice data.

 

> 

> With diffserv you don’t need to know the bandwidth requirement, but

> with RSVP reservation (like in cable and mobile networks) you need to

> know how much to reserve. Voice is like 100's kbit/s, video VP8 or

> H.264 is like 3,5 mbps.

 

Again, without knowing the application, you don't know that.

The application could decide to use QCIF or HD, and the bandwidth variation of screencast (semi-static with sudden, large changes) is completely different from that of a talking head, which is again completely different from a high-movement scene.

 

> 

> To add to the complication of codec variants, the video codecs in

> question for WebRTC have variable bandwidth, and when there is a poor

> connection we see Chrome reducing the video window size to reduce the bandwidth used...

> 

> I think the payload type field at best can reflect a maximum bandwidth

> to initially reserve bandwidth for, and thereafter make new

> reservations if the bandwidth changes during the call. So could we

> change RTP to show maximum bandwidth instead of payload type in that

> field outside the encrypted payload :) ... Or maybe that is not a joke?

 

I think these ruminations only lead to one conclusion:

 

You can't tell what the needed bandwidth is up front without asking the application.

You can't tell what the right priority ranking is without asking the application.

 

If you need to know the bandwidth or the priority up front, the application has to tell you. Anything else is pure heuristics.

 

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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

 

 

-- 

Colin Perkins

 

 

 




-- 
Colin Perkins





-- 
Surveillance is pervasive. Go Dark.
--------------040103040302090507080803-- From nobody Tue Feb 25 23:50: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 1DA4C1A0045 for ; Tue, 25 Feb 2014 23:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 dmpYorbHVkco for ; Tue, 25 Feb 2014 23:50:32 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4948C1A0041 for ; Tue, 25 Feb 2014 23:50:31 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-6a-530d9cc5b2a3 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A9.73.10875.5CC9D035; Wed, 26 Feb 2014 08:50:29 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.2.347.0; Wed, 26 Feb 2014 08:50:29 +0100 Message-ID: <530D9CC5.5080508@ericsson.com> Date: Wed, 26 Feb 2014 08:50:29 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Tuexen , "rtcweb@ietf.org" References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> In-Reply-To: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3RvfoHN5gg/4HNhYXm5YwWqz9187u wOSxZMlPJo8NLTuYApiiuGxSUnMyy1KL9O0SuDJm/FjAWLBVqGJ+7we2BsYTfF2MnBwSAiYS L17MZIOwxSQu3FsPZHNxCAkcYpTY//AVI4SznFHi4MVbjCBVvALaEvdOHgbrYBFQlfj+YAYr iM0mYCFx80cjWFxUIFhi54HfUPWCEidnPmEBsUUEYiQOXHoOVi8soCfxsWU7O4gtJOAi0Xew F8zmFHCVWDl/DlANB9BF4hI9jUEgYWag8ilXWxghbHmJ5q2zmSFatSUamjpYJzAKzkKybRaS lllIWhYwMq9iZM9NzMxJLzfcxAgMyYNbfuvuYDx1TuQQozQHi5I474e3zkFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGGdukNtoX9rTqyZx+MhUldAldbuOPCu59efXV6OlKiq3bh/csO0D r5eI/heDiTPfr2jYyqHPqOL4xuDWTZ76i3cmvXjR+Ijl+p7G/BWz/k3u0e44kxLQ9O3F5aaQ i8e4PhXo3zhm1P7oyUljjvBre3LvL1nicbth6s9G5uS9ssprfwcFfThzTeuJEktxRqKhFnNR cSIAqvjFmxcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/V5fxBZ7OUhsJTPk-1xHsRbUtS-s Subject: Re: [rtcweb] Open data channel issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 07:50:37 -0000 Thanks Michael, WG, please consider these open issues and try to form your own position on them. They are intended to be discussed at the meeting. If you have proposals on how to resolve them or other input you are very welcome to provide that on the list. Thanks Magnus On 2014-02-26 00:44, Michael Tuexen wrote: > Dear all, > > Magnus asked me to send a list of open issues regarding data channels > to the list. Here is my current list: > > > * Priority > The W3C hasn't defined it yet. Neither for the (S)RTP media nor for the > data channels. We agreed on using a non strict policy for the data channels > (some sort of wighted fair queueing). That is all. > > * Protocol > It seems not to be clear what needs to be provided when registering a > (sub)-protocol at IANA. And the name of the registry is unclear... > > * SCTP parameters. > There was discussed the issue how to set SCTP parameters, especially path.max.retrans > and association.max.retrans. Also HB.Interval might be of interest. > RFC 4060 recommends path.max.retrans=5, association.max.retrans=10, but has multihoming > in mind. To avoid the dormant state, path.max.retrans = association.max.retrans should be used. > I would suggest 10 for this value. Should HEARTBEATs be disabled? > > * U-C 7: Proxy browsing > > * Alternate CC for SCTP > Currently there is only the standard CC. However, in some places negotiation of CC is > mentioned. > > I'm currently going through the backlog of comments regarding the data channels > ID and I'll try to address the issues. If I find other issues, I send an update > to the above list. > > Best regards > Michael > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Feb 26 00:36: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 EB4251A0347; Tue, 25 Feb 2014 16:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 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.547, SPF_PASS=-0.001, 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 69nlIGbNGkxe; Tue, 25 Feb 2014 16:49:21 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC4F1A0344; Tue, 25 Feb 2014 16:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7561; q=dns/txt; s=iport; t=1393375760; x=1394585360; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Gjr1/S77deWA/P5Y9rYPPKXF5CccXvn4E/jwoNHIrAE=; b=Hw1jv74wPj3BuhRnQIdYG6p9ZtgXL8ouUIsa2oA79jAUTaUHYpqMmm0L 5R1i9wqsd4mVPuFM7nqxu1Vyta1G9nTy5MDCiS2Xfc+UyXzEaRvqmINWM ck9C+3DCwD6lwtLfed+ZRzA9zfNufc2F0+CmYQTHLiR4T0YpNlAdVvegw s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAJc5DVOtJV2d/2dsb2JhbABWA4MGO1fAMU+BFRZ0giUBAQEDAQEBAWQHCwULAgEIEQQBAQEnByEGCxQJCAIEDgUJh2gDCQgNwHcNh0AXjDyBMhACARwjEAIFEYMTgRQElkmBbYEyiy+FR4Mtgio X-IronPort-AV: E=Sophos;i="4.97,543,1389744000"; d="scan'208";a="306473291" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 26 Feb 2014 00:49:19 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1Q0nJqh007524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 00:49:19 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 18:49:19 -0600 From: "Cullen Jennings (fluffy)" To: Karl Stahl Thread-Topic: [rtcweb] [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Thread-Index: AQHPMoyUg60iiUWRskCpUFa2PiKTiQ== Date: Wed, 26 Feb 2014 00:49:18 +0000 Message-ID: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <050401cf31bf$64ae8ff0$2e0bafd0$@stahl@intertex.se> In-Reply-To: <050401cf31bf$64ae8ff0$2e0bafd0$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.131] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/I0S7ORVAnxahMhctrzgimk_AYUE X-Mailman-Approved-At: Wed, 26 Feb 2014 00:36:34 -0800 Cc: Marc Robins , "tram@ietf.org" , Bernard Aboba , "rtcweb@ietf.org" , Eric Burger , Mary Barnes , Henning Schulzrinne Subject: Re: [rtcweb] [tram] I-D Action: draft-thomson-tram-turn-bandwidth-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, 26 Feb 2014 00:49:28 -0000 Karl,=20 I am totally lost on this thread. Could you start a new tmead that summariz= e what the issues is, what seems to be the point of debate, and what your v= iew is on what we should do. I think that would help make progress.=20 Thank you,=20 Cullen=20 On Feb 25, 2014, at 8:20 AM, Karl Stahl wrote: > Hi Alan, > =20 > I have in previous email http://www.ietf.org/mail-archive/web/tram/curren= t/msg00304.html suggested that both DISCUSS and draft-thomson-tram-turn-ban= dwidth-00.txt is taken off the TRAM WG, but I think is shall be reintroduce= d after you clarify as you do in > http://www.ietf.org/mail-archive/web/tram/current/msg00300.html : > Hi Karl, Thanks for your comments and feedback on the draft. > You are correct in saying that the BANDWIDTH extension is not about QoS. = It is about fairness between users of a TURN server, and a TURN server bei= ng able to indicate rate limiting policy to users. in the draft. > =20 > The =93confusion=94 (to say least, see below) surrounding QoS within IETF= has lead me to protest and address the TRAM WG and RTCWEB WG and ADs with = the advise in http://www.ietf.org/mail-archive/web/tram/current/msg00304.ht= ml : > =93The TRAM WG and RTCWEB WG chairs and ADs are advised to review whether= IETF standard work in these WGs by contributors having an interest in more= than one of current or emerging: ISPs, carrier equipment vendors or web br= owser makers, may discriminate any with an interest only in one of these. T= he same should apply to non-activity by WG contributors to remedy such disc= rimination opened by allowed proprietary usage of RFCs such as RFC 5285.=94 > =20 > This is because the introduction of the QoS related usage of RFC 5285 int= o draft-ietf-rtcweb-rtp-usage in combinations with the Milestone 3 objectiv= es of TRAM, immediately would allow for: > (1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in addi= tion to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP variants) to qu= ickly allow us to finally enjoy the high quality and connectivity (NAT/fire= wall traversal) of real-time communication services now possible, for =20 > (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), und= er *all* OSs, and *all* current and future IP networks > (3) *without* having to be forced into application specific networks (PST= N, IMS) instead of the Internet (including OTT). > =20 > While the =93confusion=94 surrounding the QoS discussion in TRAM and RTCW= EB combined with thegeneral QoS attitude within IETF =93it is all about ban= dwidth=94 and =93it will go away with time=94 otherwise: > (i) will *not allow* ISP=92s to use already available and currently deplo= yable quality IP pipes for real-time traffic to also be used for WebRTC gen= erated real-time traffic. > (ii) will *not allow* some network types (e.g. Cable Networks and Mobile = OTT) to borrow bandwidth from data traffic and QoS insensitive streaming vi= deo and file sharing. That all networks *will be inhibited* from the very c= ommon and used method of simply providing an extra IP pipe (often provided = over the same wire but level-2 separated) dedicated for real-time usage > (*by resisting TRAM implementation of step B*) > *while* newer, fiber only type of networks, still can borrow bandwidth at= no extra cost, *by proprietary usage* of RFC 5285 by browsers. > (iii) will leave most ISPs to *only use* raw bandwidth capacity increase = that may have to be 10-folded to reach sufficient QoE when WebRTC usage bec= omes popular (if at all possible, since unmanaged IP pipes intermittently a= re filled, whatever bandwidth is available). > =20 > As Good doers, we should not allow this to happen. > =20 > /Karl > =20 > =20 > Fr=E5n: Alan Johnston [mailto:alan.b.johnston@gmail.com]=20 > Skickat: den 21 februari 2014 18:59 > Till: Pal Martinsen (palmarti) > Kopia: tram@ietf.org; Oleg Moskalenko; Karl Stahl; Yoakum, John H (John) > =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt > =20 > I guess the way I would expect this to progress is for QoS discussions to= happen in another working group. Once that other working group came to co= nsensus on an approach, and if that approach required STUN or TURN extensio= ns, then we would discuss mechanisms and possible milestones in TRAM. > =20 > - Alan - > =20 >=20 > On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen (palmarti) wrote: > Hi, > =20 > I agree the full QoS discussion should _not_ happen in TRAM. If you are i= nterested in helping out in that area I suggest you looking into the AEON m= ailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are curre= ntly working on a problem-statement draft and a use-case draft, any input t= o those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon= -use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statemen= t-00). > =20 > That said, STUN have a few nice characteristics that makes it a perfect c= andidate for transporting some of the QoS information. IMHO that would be = extending the STUN spec and should be within the TRAM charter. The main go= al of draft-martinsen-tram-discuss was to show how already existing QoS mec= hanisms could be transported with STUN to provide more value, and to start = the discussion if TRAM is the appropriate place to have those on the wire f= ormat discussions. > =20 > .-. > P=E5l-Erik > =20 > =20 > On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) wro= te: >=20 >=20 > +1 > I fully agree with the comments that QOS should be a low priority for the= initial focus of the TRAM efforts. There are other groups doing QOS work = and frankly I engage in WebRTC multimedia interactions daily over the Inter= net, enterprise VPNs, and various combinations and seldom suffer egregious = quality issues. I am more concerned about carriers doing things to regulat= e or degrade WebRTC flows than a failure of existing Internet mechanisms to= enable them. > =20 > Significant focus on QOS before we better enable TURN to be easily used i= n a browser environment taking advantage or normal web characteristics (as = opposed to historic telephony constructs) would seem to be highly distracti= ng at this point. > =20 > =20 > Cheers, > John > =20 > AVAYA > 1.919.425.8446 > =20 > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko > Sent: Thursday, February 20, 2014 12:43 PM > To: Alan Johnston > Cc: Karl Stahl; tram@ietf.org > Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00= .txt > =20 > =20 > =20 >=20 > On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston wrote: > =20 > =20 > =20 > Personally, I am not sure how much QoS is actually in scope for TRAM. Hav= e you been following RMCAT where congestion avoidance for RTP is being deve= loped? I see some overlap in your goals and the goals of that work. > - > =20 > =20 > I'd concentrate on the TURN application-level functionality, for now, and= I'd leave QoS for the future discussions. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > =20 > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Feb 26 00:36: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 30C551A0822; Tue, 25 Feb 2014 17:12:23 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 W3SlUKD4UVDH; Tue, 25 Feb 2014 17:12:22 -0800 (PST) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id DFD351A0283; Tue, 25 Feb 2014 17:12:21 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id o15so1414883qap.35 for ; Tue, 25 Feb 2014 17:12:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=m52AtfZmXJfdLbH8hMpd0VTqlEjehN8vxgrzWGiG0m4=; b=hERUOWuLALRwJXWoEt4PZlXuRm/s7eb+geJOWP3HtDiva7NHuxlEpri8ZJe0AtfChM jA+eL9OkToUavWWMhshErE0N9NjjSBfsfkevFJWbHZbHzeCN9MKMplOBIhj3eLqiZMdr lbwBCk813OOGnSl80GYs504urxA8ZfrN2OpFOHl8MzF/ilLKI8NHtJdfZVMHGZ4XAe6t 3TODPaYwc3VHYdA+xQRCVWp43ZRJ4ZE0Zx2QZBC1nZnYG9ld27bmRoPmat4nq5chJtiq F78DqRjvxARTO6jICefZ7c1P5gOpoRcsGfZTNf4o48fXUwjYKq/323MkWBWkJkMFBW3T PM2g== MIME-Version: 1.0 X-Received: by 10.140.93.111 with SMTP id c102mr3894557qge.53.1393377140691; Tue, 25 Feb 2014 17:12:20 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.224.26.11 with HTTP; Tue, 25 Feb 2014 17:12:20 -0800 (PST) In-Reply-To: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> Date: Tue, 25 Feb 2014 17:12:20 -0800 X-Google-Sender-Auth: 51AuCbqYBAnnfdQ7jMCJq3rhkKs Message-ID: From: Barry Leiba To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1i2TLt4Rsn7bXM2C6Y1ma2UvOgM X-Mailman-Approved-At: Wed, 26 Feb 2014 00:36:35 -0800 Cc: "tram@ietf.org" , Spencer Dawkins , "rtcweb@ietf.org" , IESG IESG Subject: Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 01:12:23 -0000 > That said, I think you have pointed out this charter is abysmally > vague - it does not say what the WG is not going to do. If I > decided to do BGP for routing updates over TURN it would be > within the scope of this charter. Cullen, is it your opinion that a working group is always free to do anything that's not explicitly forbidden in its charter? I think that a working group is limited to doing what *is* in its charter, and we sometimes explicitly forbid things for emphasis. The TRAM charter says this: The work will include the addition of DTLS as an additional transport, authentication mechanisms, and extensions to TURN and STUN. I don't think that would support, for example, BGP over TURN. Barry From nobody Wed Feb 26 00:36: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 2AB301A0364; Tue, 25 Feb 2014 18:52:45 -0800 (PST) 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 1Zt8hiCEdGYN; Tue, 25 Feb 2014 18:52:44 -0800 (PST) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id C78081A02F2; Tue, 25 Feb 2014 18:52:43 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id i11so225226oag.9 for ; Tue, 25 Feb 2014 18:52:42 -0800 (PST) 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:content-transfer-encoding; bh=zLwzm6rB6pZoVQvxqPfiQ4QoV+UwTXzcE1OyKtpPtHE=; b=PT+9tUJ9iCO/McJ1cuqhKntwiIO9+76/Ua71QkvQk6Ln9uy6Y/lsH4f1C3okr+oQ/3 k6yKjV1IDlRx7NzqZuxfety2E0/affwEk+CYyZPBEC76RemSTvHF99DKOPtr0y/TvCEw T3eWo/xZ0vOjGedF1aimVSbXGJ6xJ5pS+QUHh0wXNIKNNxbTLqZfuSeqKtKlV2NS9hoq voVVUkEqLV+FJjADzA8aO1tVtvWYTCcovK3Ln8Je0uVlhezg89A2rUyIF775tIcZKE9A Vd99BWiJmukZksq2Iyhetss9fD6lcwjsqoQxPUrY2dEu9xzLa6D7Ca0Oznq+cDz25rMC nmCQ== X-Received: by 10.182.233.228 with SMTP id tz4mr592395obc.56.1393383162646; Tue, 25 Feb 2014 18:52:42 -0800 (PST) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id u4sm50324342oev.1.2014.02.25.18.52.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 18:52:42 -0800 (PST) Message-ID: <530D56F7.5070900@gmail.com> Date: Tue, 25 Feb 2014 20:52:39 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Barry Leiba , "Cullen Jennings (fluffy)" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.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/kOZVS0SboF3l3P6RmNtucQy9mcs X-Mailman-Approved-At: Wed, 26 Feb 2014 00:36:35 -0800 Cc: "tram@ietf.org" , Spencer Dawkins , "rtcweb@ietf.org" , IESG IESG Subject: [rtcweb] BCP over TURN will not be in scope ... and MPLS over UDP over TURN will not be in scope ... and ... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 02:52:45 -0000 So ... TRAM was chartered last Thursday ... I'm gonna let Gonzalo (Yet Another Soon-to-be Former AD Serving as WG Chair) and Simon actually chair their working group for at least a full week before intruding further, but for now, let's assume that the working group wants to work on the milestones they signed up for last week, and see how badly that assumption blows up, rather than talk about rechartering every time someone proposes a topic that's out of scope. I look forward to attending the first working group session next week, and to balloting on six TRAM drafts before IETF 92. Thanks, Spencer, as the responsible AD From nobody Wed Feb 26 00:36: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 61FCE1A008E; Wed, 26 Feb 2014 00:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.048 X-Spam-Level: X-Spam-Status: No, score=-110.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 gxcBHsSR8hik; Wed, 26 Feb 2014 00:05:42 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 92CFA1A0092; Wed, 26 Feb 2014 00:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1290; q=dns/txt; s=iport; t=1393401939; x=1394611539; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Lfr0m5MtyKVpXpY0pLAOIHsWRsnUcdjSKX/sL6ChiiI=; b=TOnDc5CkQwfuyNnA0FgeKXbaI9BghPxzHjPM2sGhTwWPeA70TT5CX1Zn tKlbFChRN+8CUqjjE5eQrsgvWTLrDQNg99+JPmug7dLgGRkuZzL2J8Uri Y3RPBwa9gEcV5Y41NL25ICqQIobhoVGuVR4EWqAv1Ba0ETw/tJD7mY9Ve s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAC2gDVOtJV2a/2dsb2JhbABYgwaBEsEFgRoWdIIlAQEBAwF5EAIBCDsLMiUCBA4Fh30IyGwXjXglMweDJIEUAQOYNpIogW+BPoFoQg X-IronPort-AV: E=Sophos;i="4.97,546,1389744000"; d="scan'208";a="23261635" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 26 Feb 2014 08:05:31 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1Q85VV8017950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 08:05:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 02:05:30 -0600 From: "Cullen Jennings (fluffy)" To: Barry Leiba Thread-Topic: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPMbSdf/e29IVb6Eq4DfCgCp5RAprHHxqAgAABqQCAAHOcgA== Date: Wed, 26 Feb 2014 08:05:30 +0000 Message-ID: <055BC233-8C90-4A07-9AFC-FB178586AA0B@cisco.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.234] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5C592798698FF940BAABC2723F2E1FA5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YAu4kuBolBmBPSJPEWaXMsu7B4E X-Mailman-Approved-At: Wed, 26 Feb 2014 00:36:34 -0800 Cc: "tram@ietf.org" , Spencer Dawkins , "rtcweb@ietf.org" , IESG IESG Subject: Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 08:05:48 -0000 On Feb 26, 2014, at 9:12 AM, Barry Leiba wrote: >> That said, I think you have pointed out this charter is abysmally >> vague - it does not say what the WG is not going to do. If I >> decided to do BGP for routing updates over TURN it would be >> within the scope of this charter. >=20 > Cullen, is it your opinion that a working group is always free to do > anything that's not explicitly forbidden in its charter? >=20 > I think that a working group is limited to doing what *is* in its > charter, and we sometimes explicitly forbid things for emphasis. >=20 > The TRAM charter says this: >=20 > The work will include the addition of DTLS > as an additional transport, authentication mechanisms, and > extensions to TURN and STUN. >=20 > I don't think that would support, for example, BGP over TURN. >=20 > Barry BGP over TURN sounds like a turn extension to me. Now you might think that = is a silly one and I would agree but I assure you Karl does not think the Q= oS extensions are silly extensions to TURN.=20 So in your opinion are they in scope or out, I think that is the heart of t= he issue right now. I=92m of the opinion they are in scope so I look forwar= d to agenda time be allocated for them.=20 Cullen From nobody Wed Feb 26 00:37: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 0383E1A00A7; Wed, 26 Feb 2014 00:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.048 X-Spam-Level: X-Spam-Status: No, score=-110.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 XApoWPBuFByj; Wed, 26 Feb 2014 00:26:19 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 3590E1A00BF; Wed, 26 Feb 2014 00:26:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1122; q=dns/txt; s=iport; t=1393403175; x=1394612775; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xZRM/jW19U+oUVmhHSS+Qhf4EjaTjljk44Pg/k4dSRM=; b=BP5/ZrUrk8D2Mh73bYg0+GyGfMIfIC2WKZjHpT1idcQF6ipsJkI1BkoY HwRasBGfSAexCY2tnb+Y1dYZWFvKtspJgFTrBb35iT+jACAfohmTrZBJ6 E34x9rcMpRnauGANyxbwcVj6IZgJnnuamFopxLLOVz/HgrR+IM1U/lj7l w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAM+kDVOtJV2d/2dsb2JhbABYgwaBEsBzgRoWdIIlAQEBAwF5BQsCAQg7CyERJQIEDgWHcQMJCMEiDYdAF4w8gWEzB4MkgRQBA4kRjTiBbYxhhUeBb4E+gio X-IronPort-AV: E=Sophos;i="4.97,546,1389744000"; d="scan'208";a="23275197" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 26 Feb 2014 08:26:14 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1Q8QEC3013649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 08:26:14 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 02:26:14 -0600 From: "Cullen Jennings (fluffy)" To: Spencer Dawkins Thread-Topic: BCP over TURN will not be in scope ... and MPLS over UDP over TURN will not be in scope ... and ... Thread-Index: AQHPMp3TlavW55iFXk6oBDPcpW1UwZrHmFiA Date: Wed, 26 Feb 2014 08:26:13 +0000 Message-ID: <55FF8505-78C7-483B-B923-368ED01CE37A@cisco.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <530D56F7.5070900@gmail.com> In-Reply-To: <530D56F7.5070900@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.246.205] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VWdn8q3zHu726VXG9s02GDpW-Uo X-Mailman-Approved-At: Wed, 26 Feb 2014 00:36:35 -0800 Cc: "tram@ietf.org" , Spencer Dawkins , "rtcweb@ietf.org" , IESG IESG , Barry Leiba Subject: Re: [rtcweb] BCP over TURN will not be in scope ... and MPLS over UDP over TURN will not be in scope ... and ... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 08:26:22 -0000 On Feb 26, 2014, at 10:52 AM, Spencer Dawkins wrote: > So ... TRAM was chartered last Thursday ... >=20 > I'm gonna let Gonzalo (Yet Another Soon-to-be Former AD Serving as WG Cha= ir) and Simon actually chair their working group for at least a full week b= efore intruding further, but for now, let's assume that the working group w= ants to work on the milestones they signed up for last week, and see how ba= dly that assumption blows up, rather than talk about rechartering every tim= e someone proposes a topic that's out of scope. >=20 > I look forward to attending the first working group session next week, an= d to balloting on six TRAM drafts before IETF 92. >=20 > Thanks, >=20 > Spencer, as the responsible AD Makes sense - I get the desire to let some work get done.=20 I worry that every time someone says something is is not in scope of this W= G, it is not going to feel like an open consensus decisions but is instead = going to feel like a arbitrary fiat decisions by a chair or IESG made in a = dark and smoky room - I hope I am wrong.=20 From nobody Wed Feb 26 05:34: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 F05681A032E; Wed, 26 Feb 2014 05:34:36 -0800 (PST) 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 t7ReDfjSGkhG; Wed, 26 Feb 2014 05:34:27 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 39C9D1A02F5; Wed, 26 Feb 2014 05:34:27 -0800 (PST) Received: by mail-yk0-f174.google.com with SMTP id 20so2483889yks.5 for ; Wed, 26 Feb 2014 05:34:25 -0800 (PST) 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=ylsHWTJ9P44z5H1YfXuRCSvUk6qcBhAYAVvyFwsWzqg=; b=iJqh7Fg0ASNGJWRkFz1YTWitex+5mk2pntF38ez+ppF6KCJdwM2e4RcoQQPF9DEzsI xJ98ZMGAGfojfkwaVVmkc9gIxm9iiF/vK5dVtQs4njNF4gEov/ngp+ZOSGXWuHz2z+ig brbVq6AAMu96WIrh30rnmjthkaSF14Waq3IqTSW3PfPpJh1TThnXMevtxOwHaZ95peZC x+Y2njIXroZpVKhhBHuNVnGOPK/ZS9xnunjFpX4/YhNLFh2NG++Ru2EgysIljfm+TZ1s +UMm/nxNpBEgJbN1SrXYff+UHxet5leBLcETC7lSisQ0GgHEt/DXCrxGHvW3Bvqe4Mvs CVLQ== MIME-Version: 1.0 X-Received: by 10.236.175.161 with SMTP id z21mr7596580yhl.80.1393421665857; Wed, 26 Feb 2014 05:34:25 -0800 (PST) Received: by 10.170.96.215 with HTTP; Wed, 26 Feb 2014 05:34:25 -0800 (PST) Date: Wed, 26 Feb 2014 07:34:25 -0600 Message-ID: From: Spencer Dawkins at IETF To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=20cf303f672e6a778604f34f4302 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JvUQf3xdKwAifAh6Ts_T40j5aHI Cc: "rtcweb@ietf.org" , "tram@ietf.org" , "tsv-ads@ietf.org" Subject: [rtcweb] Last note about QoS from the responsible AD before the rant ... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 13:34:37 -0000 --20cf303f672e6a778604f34f4302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Using smaller words (since we're all very busy): QoS is out of scope for TRAM. It is in scope for TSVWG. It will not be necessary helpful to continue to talk about QoS in TRAM. Thanks for taking the conversation to a mailing list where it's in scope. Spencer, as responsible AD On Tuesday, February 25, 2014, Cullen Jennings (fluffy) wrote: > > Karl, > > I am totally lost on this thread. Could you start a new tmead that > summarize what the issues is, what seems to be the point of debate, and > what your view is on what we should do. I think that would help make > progress. > > Thank you, > > Cullen > > > On Feb 25, 2014, at 8:20 AM, Karl Stahl > > wrote: > > > Hi Alan, > > > > I have in previous email > http://www.ietf.org/mail-archive/web/tram/current/msg00304.html suggested > that both DISCUSS and draft-thomson-tram-turn-bandwidth-00.txt is taken o= ff > the TRAM WG, but I think is shall be reintroduced after you clarify as yo= u > do in > > http://www.ietf.org/mail-archive/web/tram/current/msg00300.html : > > Hi Karl, Thanks for your comments and feedback on the draft. > > You are correct in saying that the BANDWIDTH extension is not about QoS= . > It is about fairness between users of a TURN server, and a TURN server > being able to indicate rate limiting policy to users. in the draft. > > > > The "confusion" (to say least, see below) surrounding QoS within IETF > has lead me to protest and address the TRAM WG and RTCWEB WG and ADs with > the advise in > http://www.ietf.org/mail-archive/web/tram/current/msg00304.html : > > "The TRAM WG and RTCWEB WG chairs and ADs are advised to review whether > IETF standard work in these WGs by contributors having an interest in mor= e > than one of current or emerging: ISPs, carrier equipment vendors or web > browser makers, may discriminate any with an interest only in one of thes= e. > The same should apply to non-activity by WG contributors to remedy such > discrimination opened by allowed proprietary usage of RFCs such as RFC > 5285." > > > > This is because the introduction of the QoS related usage of RFC 5285 > into draft-ietf-rtcweb-rtp-usage in combinations with the Milestone 3 > objectives of TRAM, immediately would allow for: > > (1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in > addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP variants) > to quickly allow us to finally enjoy the high quality and connectivity > (NAT/firewall traversal) of real-time communication services now possible= , > for > > (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), > under *all* OSs, and *all* current and future IP networks > > (3) *without* having to be forced into application specific networks > (PSTN, IMS) instead of the Internet (including OTT). > > > > While the "confusion" surrounding the QoS discussion in TRAM and RTCWEB > combined with thegeneral QoS attitude within IETF "it is all about > bandwidth" and "it will go away with time" otherwise: > > (i) will *not allow* ISP's to use already available and currently > deployable quality IP pipes for real-time traffic to also be used for > WebRTC generated real-time traffic. > > (ii) will *not allow* some network types (e.g. Cable Networks and Mobil= e > OTT) to borrow bandwidth from data traffic and QoS insensitive streaming > video and file sharing. That all networks *will be inhibited* from the ve= ry > common and used method of simply providing an extra IP pipe (often provid= ed > over the same wire but level-2 separated) dedicated for real-time usage > > (*by resisting TRAM implementation of step B*) > > *while* newer, fiber only type of networks, still can borrow bandwidth > at no extra cost, *by proprietary usage* of RFC 5285 by browsers. > > (iii) will leave most ISPs to *only use* raw bandwidth capacity increas= e > that may have to be 10-folded to reach sufficient QoE when WebRTC usage > becomes popular (if at all possible, since unmanaged IP pipes > intermittently are filled, whatever bandwidth is available). > > > > As Good doers, we should not allow this to happen. > > > > /Karl > > > > > > Fr=E5n: Alan Johnston [mailto:alan.b.johnston@gmail.com ] > > Skickat: den 21 februari 2014 18:59 > > Till: Pal Martinsen (palmarti) > > Kopia: tram@ietf.org ; Oleg Moskalenko; Karl Stahl; > Yoakum, John H (John) > > =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt > > > > I guess the way I would expect this to progress is for QoS discussions > to happen in another working group. Once that other working group came t= o > consensus on an approach, and if that approach required STUN or TURN > extensions, then we would discuss mechanisms and possible milestones in > TRAM. > > > > - Alan - > > > > > > On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen (palmarti) < > palmarti@cisco.com > wrote: > > Hi, > > > > I agree the full QoS discussion should _not_ happen in TRAM. If you are > interested in helping out in that area I suggest you looking into the AEO= N > mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are > currently working on a problem-statement draft and a use-case draft, any > input to those would be very helpful. ( > http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01, > http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). > > > > That said, STUN have a few nice characteristics that makes it a perfect > candidate for transporting some of the QoS information. IMHO that would = be > extending the STUN spec and should be within the TRAM charter. The main > goal of draft-martinsen-tram-discuss was to show how already existing QoS > mechanisms could be transported with STUN to provide more value, and to > start the discussion if TRAM is the appropriate place to have those on th= e > wire format discussions. > > > > .-. > > P=E5l-Erik > > > > > > On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) > > wrote: > > > > > > +1 > > I fully agree with the comments that QOS should be a low priority for > the initial focus of the TRAM efforts. There are other groups doing QOS > work and frankly I engage in WebRTC multimedia interactions daily over th= e > Internet, enterprise VPNs, and various combinations and seldom suffer > egregious quality issues. I am more concerned about carriers doing thing= s > to regulate or degrade WebRTC flows than a failure of existing Internet > mechanisms to enable them. > > > > Significant focus on QOS before we better enable TURN to be easily used > in a browser environment taking advantage or normal web characteristics (= as > opposed to historic telephony constructs) would seem to be highly > distracting at this point. > > > > > > Cheers, > > John > > > > AVAYA > > 1.919.425.8446 > > > > From: tram [mailto:tram-bounces@ietf.org ] On Behalf Of > Oleg Moskalenko > > Sent: Thursday, February 20, 2014 12:43 PM > > To: Alan Johnston > > Cc: Karl Stahl; tram@ietf.org > > Subject: Re: [tram] Fwd: I-D Action: > draft-thomson-tram-turn-bandwidth-00.txt > > > > > > > > > > On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston < > alan.b.johnston@gmail.com > wrote: > > > > > > > > Personally, I am not sure how much QoS is actually in scope for TRAM. > Have you been following RMCAT where congestion avoidance for RTP is being > developed? I see some overlap in your goals and the goals of that work. > > - > > > > > > I'd concentrate on the TURN application-level functionality, for now, > and I'd leave QoS for the future discussions. > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf303f672e6a778604f34f4302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Using smaller words (since we're all very busy): 

QoS is out of scope for TRAM.

It is in scope fo= r TSVWG.

It will not be necessary helpful to = continue to talk about QoS in TRAM.

Thanks for taking the conversation to a mailing list wh= ere it's in scope.

Spencer, as responsible AD<= /div>

On Tuesday, February 25, 2014, Cullen Jennings (fluffy) <<= a href=3D"mailto:fluffy@cisco.com">fluffy@cisco.com> wrote:

Karl,

I am totally lost on this thread. Could you start a new tmead that summariz= e what the issues is, what seems to be the point of debate, and what your v= iew is on what we should do. I think that would help make progress.

Thank you,

Cullen


On Feb 25, 2014, at 8:20 AM, Karl Stahl <karl.stah= l@intertex.se> wrote:

> Hi Alan,
>
> I have in previous email http://www.ietf.org/mail-a= rchive/web/tram/current/msg00304.html suggested that both DISCUSS and d= raft-thomson-tram-turn-bandwidth-00.txt is taken off the TRAM WG, but I thi= nk is shall be reintroduced after you clarify as you do in
> http://www.ietf.org/mail-archive/web/tram/current/m= sg00300.html :
> Hi Karl, Thanks for your comments and feedback on the draft.
> You are correct in saying that the BANDWIDTH extension is not about Qo= S.  It is about fairness between users of a TURN server, and a TURN se= rver being able to indicate rate limiting policy to users. in the draft. >
> The “confusion” (to say least, see below) surrounding QoS = within IETF has lead me to protest and address the TRAM WG and RTCWEB WG an= d ADs with the advise in http://www.ietf.org/mail-archiv= e/web/tram/current/msg00304.html :
> “The TRAM WG and RTCWEB WG chairs and ADs are advised to review = whether IETF standard work in these WGs by contributors having an interest = in more than one of current or emerging: ISPs, carrier equipment vendors or= web browser makers, may discriminate any with an interest only in one of t= hese. The same should apply to non-activity by WG contributors to remedy su= ch discrimination opened by allowed proprietary usage of RFCs such as RFC 5= 285.”
>
> This is because the introduction of the QoS related usage of RFC 5285 = into draft-ietf-rtcweb-rtp-usage in combinations with the Milestone 3 objec= tives of TRAM, immediately would allow for:
> (1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in a= ddition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP variants) to= quickly allow us to finally enjoy the high quality and connectivity (NAT/f= irewall traversal) of real-time communication services now possible, for > (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), = under *all* OSs, and *all* current and future IP networks
> (3) *without* having to be forced into application specific networks (= PSTN, IMS) instead of the Internet (including OTT).
>
> While the “confusion” surrounding the QoS discussion in TR= AM and RTCWEB combined with thegeneral QoS attitude within IETF “it i= s all about bandwidth” and “it will go away with time” ot= herwise:
> (i) will *not allow* ISP’s to use already available and currentl= y deployable quality IP pipes for real-time traffic to also be used for Web= RTC generated real-time traffic.
> (ii) will *not allow* some network types (e.g. Cable Networks and Mobi= le OTT) to borrow bandwidth from data traffic and QoS insensitive streaming= video and file sharing. That all networks *will be inhibited* from the ver= y common and used method of simply providing an extra IP pipe (often provid= ed over the same wire but level-2 separated) dedicated for real-time usage<= br> > (*by resisting TRAM implementation of step B*)
> *while* newer, fiber only type of networks, still can borrow bandwidth= at no extra cost, *by proprietary usage* of RFC 5285 by browsers.
> (iii) will leave most ISPs to *only use* raw bandwidth capacity increa= se that may have to be 10-folded to reach sufficient QoE when WebRTC usage = becomes popular (if at all possible, since unmanaged IP pipes intermittentl= y are filled, whatever bandwidth is available).
>
> As Good doers, we should not allow this to happen.
>
> /Karl
>
>
> Fr=E5n: Alan Johnston [mailto:alan.b.johnston= @gmail.com]
> Skickat: den 21 februari 2014 18:59
> Till: Pal Martinsen (palmarti)
> Kopia: tram@ietf.org; Oleg Moskalenko; Karl Stahl; Yo= akum, John H (John)
> =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.tx= t
>
> I guess the way I would expect this to progress is for QoS discussions= to happen in another working group.  Once that other working group ca= me to consensus on an approach, and if that approach required STUN or TURN = extensions, then we would discuss mechanisms and possible milestones in TRA= M.
>
> - Alan -
>
>
> On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen (palmarti) <palmarti@cisco.com> wrote:
> Hi,
>
> I agree the full QoS discussion should _not_ happen in TRAM. If you ar= e interested in helping out in that area I suggest you looking into the AEO= N mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are = currently working on a problem-statement draft and a use-case draft, any in= put to those would be very helpful. (http://tools.ietf.org/html= /draft-eckel-aeon-use-cases-01, http://tools.ietf.o= rg/html/draft-eckel-aeon-problem-statement-00).
>
> That said, STUN have a few nice characteristics that makes it a perfec= t candidate for transporting some of the QoS information.  IMHO that w= ould be extending the STUN spec and should be within the TRAM charter. &nbs= p;The main goal of draft-martinsen-tram-discuss was to show how already exi= sting QoS mechanisms could be transported with STUN to provide more value, = and to start the discussion if TRAM is the appropriate place to have those = on the wire format discussions.
>
> .-.
> P=E5l-Erik
>
>
> On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) <yoakum@avaya.com> wrote:
>
>
> +1
> I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts.  There are other groups doing Q= OS work and frankly I engage in WebRTC multimedia interactions daily over t= he Internet, enterprise VPNs, and various combinations and seldom suffer eg= regious quality issues.  I am more concerned about carriers doing thin= gs to regulate or degrade WebRTC flows than a failure of existing Internet = mechanisms to enable them.
>
> Significant focus on QOS before we better enable TURN to be easily use= d in a browser environment taking advantage or normal web characteristics (= as opposed to historic telephony constructs) would seem to be highly distra= cting at this point.
>
>
> Cheers,
> John
>
> AVAYA
> 1.919.425.8446
>
> From: tram [mailto:tram-bounces@ietf.org] On = Behalf Of Oleg Moskalenko
> Sent: Thursday, February 20, 2014 12:43 PM
> To: Alan Johnston
> Cc: Karl Stahl; tram@ietf.org
> Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth= -00.txt
>
>
>
>
> On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <alan.b.johnston@gmail.com> wrote:
>
>
>
> Personally, I am not sure how much QoS is actually in scope for TRAM. = Have you been following RMCAT where congestion avoidance for RTP is being d= eveloped?  I see some overlap in your goals and the goals of that work= .
> -
>
>
> I'd concentrate on the TURN application-level functionality, for n= ow, and I'd leave QoS for the future discussions.
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--20cf303f672e6a778604f34f4302-- From nobody Wed Feb 26 07:15: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 4C88B1A0424 for ; Wed, 26 Feb 2014 07:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 5ct-f35ksaFP for ; Wed, 26 Feb 2014 07:15:12 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C6CCE1A066F for ; Wed, 26 Feb 2014 07:14:45 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-1c-530e04e3cd39 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 24.59.10875.3E40E035; Wed, 26 Feb 2014 16:14:44 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.2.347.0; Wed, 26 Feb 2014 16:14:42 +0100 Message-ID: <530E04E2.904@ericsson.com> Date: Wed, 26 Feb 2014 16:14:42 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <530DFE74.5000505@erg.abdn.ac.uk> In-Reply-To: <530DFE74.5000505@erg.abdn.ac.uk> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <530DFE74.5000505@erg.abdn.ac.uk> Content-Type: multipart/mixed; boundary="------------030007060605010004090002" X-Brightmail-Tracker: H4sIAAAAAAAAA1VSbUhTYRTu3e7uPkh9XTNP+qNQMqmmG/ShGVHUDykqUYqMsAZddLRE5ip/ GE3TFFcgfqU3U1Exs0SXunl/WDYlv0vNDzQcLk2LMuxH6hyztntH2L/nnPM85zzvOa+IL50R BIjUyTpKm6zSBJESouySM10+T3jHKUwjZETjRo7wOIqurbXzYtBlydHrlEZ9m9KGH7smSbJl 2AQpdQfTOo1feHpUGZ6HxCLAB8DkXOZzeDsMW5vIPCQRSbEFgeHFdz4XPEPAFHMsL7wHPkz3 8NyYwLthzNxHujGJI2BqLYPFfjgOmE4H4vi+0Fc2T7ixzKX9aBsWuvE2rIJfc0NsHymWQ6+5 htWKcRisPq0V5CGRy5E/PMyI5cxFwkvzHEvn4xjY6HbyOek+0GfmCvKRL71pGr2JxuEwKBrP QhzeCealck8+HX7qGfL/vMSFSxAMVtfwaHa2D+QMDLIFKTYisPeOCWnP9j79mUBcgUEwXLlG cEEhggU6X+gOCFxKwJMf3wQ0+6RgMDRSNLu9IKg3VpD/2i5WGhDXNhRKnw8jju8DjZZgLi2D 3rpSD8ULBop6WC24z/PucabH3wiC4hmTkAs6EUyW21mzUqwDq2PZM64PQVfDpJDbmRx6ZhcE tOeiS/kF7LNJvB+qzeMsxwcnQGlbB7snP0yBdTSbdNuTuTwZ2sNpzxHHcxxkFTrcgIQ3VWpN 4h3lK+T6om9bHfJ21P9eZkGBIiLI32t56WSsFCeqdNQNikqhtFe1tzRUqgXxROIAPQrMqDh1 JLR81Vp1Pt3SfOaN5e7reaVDkfy5fZTxyW478WjWSKyvT4QwrcaobMMDrfdpYkrZYWvvv1eY YCqcbjZujUzTtTRJKGuY4WtLQclCYELrlguLa1fUF4cqxYoopou5P6WvWcnOUtSfjY/dscsZ ci7+UIV9Qbu48rs7NzqISE1SKffytamqv3EsDFBwAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/i3qqfaIkxqco1wExRmYIWsr2Od8 Subject: [rtcweb] Fwd: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-dtls-encaps: To End 28th February 2014 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 15:15:16 -0000 --------------030007060605010004090002 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit RTCWEB WG, This is one of the documents that this WG's Data Channel is normatively dependent on. If we don't help review the work of other WGs we will not finish ourselves. So please review and send comments that you done and provide any comments you have. Cheers Magnus Westerlund --------------030007060605010004090002 Content-Type: message/rfc822; name="Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-dtls-encaps: To End 28th February 2014.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-dtls-encaps: To E"; filename*1="nd 28th February 2014.eml" X-Mozilla-Keys: Received: from sessmg11.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.67) with Microsoft SMTP Server id 14.2.347.0; Wed, 26 Feb 2014 15:47:26 +0100 X-AuditID: c1b4fb3d-b7ef88e000000f83-d6-530dfe7e5504 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by sessmg11.ericsson.net (Symantec Mail Security) with SMTP id 3E.E9.03971.E7EFD035; Wed, 26 Feb 2014 15:47:27 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8141A037D; Wed, 26 Feb 2014 06:47:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1393426046; bh=KT5szTWec5w0mEgQR/UTg9vRCgcJmHhndxw4yYJ7Fmw=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Sender; b=F7fOPKBvupJ1a2lgr5pMjEoFu+FkoG2q6u6/6l8nTdyFVH5yTqMQW+P5vhgsMizey XdwfyBrFDtWuW+jsgF+SKLcIpwVw6yBeuvMWkUw4G3qn4gex7aW9SgYAIRBKEgbf3Y 5g7x3LORFKvqxcd4DxkxgNNOKozaWTEIJPEtTN2E= X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95161A02F5 for ; Wed, 26 Feb 2014 06:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 oMuLHUHDVftI for ; Wed, 26 Feb 2014 06:47:19 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 643CB1A00CD for ; Wed, 26 Feb 2014 06:47:19 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id C05E62B4555; Wed, 26 Feb 2014 14:47:17 +0000 (GMT) Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id D38B92B43BE for ; Wed, 26 Feb 2014 14:47:16 +0000 (GMT) Message-ID: <530DFE74.5000505@erg.abdn.ac.uk> Date: Wed, 26 Feb 2014 14:47:16 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 To: References: <52F51569.8020501@erg.abdn.ac.uk> In-Reply-To: <52F51569.8020501@erg.abdn.ac.uk> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/18uzQ50AcB7Fkhd7hhkiYkVHsT8 Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-dtls-encaps: To End 28th February 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Sender: tsvwg X-Brightmail-Tracker: H4sIAAAAAAAAA1VSbUhTYRj13b1e79Zuvk7Np62QbkZqagpGgzKEfiREYJl/KrSZVzecU+6d pVKY1sjyR1aISyVM+rDMzMpMTUhLK0nwA42spoZlSi6UtC+ydnen1r/zvOc557wHHppQ1VFq mss2c7xJZ2QpBUn6d4aE5s0zceEnqpXat996KG3Nh+3avjqbTPvu9wNCa6344aEttURpv7fc ctc+7bIT0XTMz9kBKhbtU2xN5oyGwxy/cdtBhX6m4xyZWeKRfbKyCB1HI+5nkJwGHAlv/gwi Ca+AHlsddQYpaBVuRDA5a0fSUILA3jAtEwcSW0ko/zzhkNMOyVooquVENYlZqK6/5FLXIzh9 usVlGwjWGz1I2veE2va10rMPPL9mda0sh95P353+gK8j6CwtICSjfgS2zq8u18cIrOPjTokK m6HePiOTiBcILo+WORsxOBSejXx0l/60DqaKz8tETOEQqGoc8BCxJ04Aa0MrJWJfzIGtz0JJ Wi94cXGMFLEPVsHg/CglhYXCwKlfTizHYdA9UUyIdQi8BeZaePGZwP7QOFVBiBjhOBhqfu9c 98YHoPX8JCHV1MBEcaWr8kp42d+NilFw2T/JZUuuZf+4ViLiJvIVOEFIT42ICON4wyFByDCF mTjzXeS4krb7v6Ieoue3N7ejlbSM9WXY30ycanlSRnKOXifoE/ksIye0Iw1Nsn6Mihzdo8Kp OjOXxnGZHL/ArqJpFpjdotKL51K57BSD0bxEy2h5OwJayfow+8UdRsjUpQuGVInvQmvUfoyf SGCR0GeZFrULd9yHVqu9GeTm5qZSOnLTDeb/+UnkRyPWm8kRXZQGk3nRfdIRLHMEd2iUYrBZ t0Spj6NdyvxE902GuZhCY37iLbn9aPip5DGFf/M5+2ub19a84YimszuDgwJmMpLmeXl8zSs2 +UnksCWHyrX754/xQ8KRub2Zuwro0qaR2gsaTQBzJT7tkmdUzYaZL4XZJROB6t5jhfeC7W09 FubqMsOJO0EJm6vWh+SWR07XRT9Kid1hYUlBr4sIJnhB9xd319vAwgMAAA== Return-Path: tsvwg-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: ESESSHC016.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 A gentle reminder, I've seen no notes of support, or comments on this document during the WGLC so far. Could people please send comments to the list if they think this is ready to publish? Gorry On 07/02/2014 17:18, Gorry Fairhurst wrote: > This email announces the start of a working group last call > of draft-ietf-tsvwg-sctp-dtls-encaps-03, > "DTLS Encapsulation of SCTP Packets". This document was > discussed at the WG meeting in Vancouver and was thought at that > meeting to be ready for WG review, this email starts this process by > requesting review comments. > > Please send any comments, notes of support, or concerns to the TSVWG list. > > The draft is available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps > > The last call will run for TWO weeks, ending 28th February 2014. > > James, David, and Gorry > (TSVWG Chairs) > tsvwg-chairs@ietf.org > --------------030007060605010004090002-- From nobody Wed Feb 26 07:48: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 076EC1A066E; Wed, 26 Feb 2014 07:48:08 -0800 (PST) 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_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 FIILXOMzJZY8; Wed, 26 Feb 2014 07:48:01 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id A03741A01EF; Wed, 26 Feb 2014 07:47:59 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402261647536755; Wed, 26 Feb 2014 16:47:53 +0100 From: "Karl Stahl" To: "'Yoakum, John H \(John\)'" , "'Oleg Moskalenko'" , "'Alan Johnston'" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> In-Reply-To: <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> Date: Wed, 26 Feb 2014 16:47:50 +0100 Message-ID: <06f801cf330a$1aca7880$505f6980$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06F9_01CF3312.7C8EE080" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPLmMlcJtLqkuUgEmVgUSRCLyaepq+efWAgARzPGA= Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4B23Q9xTcCoRRO6sqJI0877CPik Cc: rtcweb@ietf.org, tram@ietf.org Subject: [rtcweb] [tram] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to inface to lower level's QoS-stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 15:48:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_06F9_01CF3312.7C8EE080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (After having typed this up; I see today=92s charter discussion etc. = that I haven=92t read yet, but it will hopefully will be clearer by pointing at = this entry.) =20 Hi John, and=20 Collin, P=E5l, Magnus, Charles, Simon, =20 In my step A) B) and D) efforts in http://www.ietf.org/mail-archive/web/tram/current/msg00275.html for the =93mission to bring quality to real-time traffic over our best effort = Internet is a huge mission, I am convinced it not a huge task =96 We just have to = be a bit clever here :). I only see these few standard steps required, before = it can happen!=94 =20 To accomplish these (1), (2), (3)-things for: (1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP = variants) to quickly allow us to finally enjoy the high quality and connectivity (NAT/firewall traversal) of real-time communication services now = possible, for =20 (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), = under *all* OSs, and *all* current and future IP networks=20 (3) *without* having to be forced into application specific networks = (PSTN, IMS) instead of the Internet (including OTT). =20 There are a lot of Mission Impossible, Pointers, Good arguments and = other things to consider in the mails from you guys that I have not (yet) answered. =20 Allow me to come back to those under THIS THREAD/Subject after having figured out how to do it in a structured way, with the aim of collecting = the summary in a new "Interfacing to QoS" thread, that only will relate to = how IP/IETF/WebRTC level 3-5 =96 *can interface* to the QoS-stuff (whether = within IETF, in the telephony world or elsewhere e.g. IEEE Ethernet, mainly relating to lower level). =20 I think this is doable *without* ending up in any of the (i), (ii), (iii)-things=20 (i) will *not allow* ISP=92s to use already available and currently = deployable quality IP pipes for real-time traffic to also be used for WebRTC = generated real-time traffic. (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. That all networks *will be inhibited* from the = very common and used method of simply providing an extra IP pipe (often = provided over the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) *while* newer, fiber only type of networks, still can borrow bandwidth = at no extra cost, *by proprietary usage* of RFC 5285 by browsers.=20 (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may have to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes = intermittently are filled, whatever bandwidth is available). (?) and possible other Evil -things. =20 I refer to = http://www.ietf.org/mail-archive/web/rtcweb/current/msg11548.html for these =93-things=94 and further. =20 =20 John, Alan, Henry (Sinnreich), Henning, Richard, Cullen, J=F6rgen = (Bj=F6rkner), Lars (Berggren) and other good friends since the early SIP age (before = SIP was =93hijacked=94 into application specific network and proprietary = usage and nowadays rarely is used the IETF-way):=20 =20 I want to point out how =93confusing=94 the QoS-issue has been and as = hard as I will the fight Mission Impossible attitude, I will also fight the =93it = is all about bandwidth=94 and =93it will go away with time=94 attitude=85 = (also in the above http reference) =20 I agree with parts of what John says below but the remedy to achieve the Good (1), (2), (3)-things instead of the Evil (i), (ii), (iii)-things, = is NOT to ignore QoS-things =96 It is the opposite!=20 =20 For you having more and relevant input =96 That has not been said, and = that you think I will not address anyway =96 in this "Interfacing to QoS" = path, please provide, but I will not be able to process much more than already have been said =96 and I will use http back-pointers for what has = already been discussed in more detail. =20 If you want to point out QoS-stuff Requiring More Input-from/Feedback-to = the level 3 and above stuff IN ADDITION to what already has been discussed = here http://www.ietf.org/mail-archive/web/tram/current/msg00302.html =20 Please also point out WHAT and WHY that can/or cannot be handled by the methods proposed here and whether other existing methods can be used to achieve the mission of "Interfacing to QoS" from IP =3D level 3 to lower levels. =20 I will do some thinking about what LISTs different things shall be = brought to and then split the [TRAM] [WEBRTC] and advice regarding involving = other list will be considered. Such will probably show up and happen during = this mission. =20 =20 Another thing from http://www.ietf.org/mail-archive/web/tram/current/msg00275.html: What = name=20 Footnote **[Karl]* For similar reasons I have started to say things like =93the box containing the TURN server=94. We should not change the TURN = server spec into including specific QoS methods to apply (like reservation, changing DSCP bits or applying traffic shaping mechanism). What is = happening here is that we share the traffic information that the TURN server gets = hold of, with a QoS applying function (that will be different for different networks) in =93the same box=94. With =93the same box=94 I mean that we = for now don=92t care about the interface/commands for sharing information = between the TURN server and the QoS applying function. There may be a future need to specify/standardize this, but if we start doing that now and in TRAM, we risk ending up in a 10-year process before having something in place = (which without a spec automatically will happen in vendor=92s product = development, by putting the TURN server into already available =93QoS applying = function=94 boxes (like firewalls or the mobile DPI/PCRF combination). =20 *What we need to consider and specify, is only what traffic info is = required (to be provided by the application/browser) for =93QoS applying = functions=94 in different networks (including the very common reservation types) to do = job (i.e. giving us good QoE for real-time applications).* =20 And Henry, I will have to continue to use the S(BC)-word and the = I(MS)-word, since you did not succeed to =93eradicate=94 them ;-) Let=92s hope we = find a word for the above box (quite undefined on the QoS-side =96 It is only the = TURN side and traffic info we are up to designing here) that does not need to = be =93eradicated=94. So no WebRTC-SBC I guess (hopefully it will not even = be WebRTC-specific), and ICE-SBC sounds crazy (since ICE was developed to remove the need of SIP SBCs), the same applies to TURN-SBC (which = implies that this box hopefully is not even ICE-specific). TURN-QoS-Interface = box is relevant but long=85=20 =20 /Karl =20 PS: To avoid being stopped by the =93to many recipients=94 spam filter, = the Guys (including Mary) from=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg11548.html=20 and the ones mentioned in the email are copied separately. =20 =20 Fr=E5n: Yoakum, John H (John) [mailto:yoakum@avaya.com]=20 Skickat: den 20 februari 2014 19:56 Till: Oleg Moskalenko; Alan Johnston Kopia: Karl Stahl; tram@ietf.org =C4mne: RE: [tram] Fwd: I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt +1 I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts. There are other groups doing QOS = work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterprise VPNs, and various combinations and seldom suffer egregious quality issues. I am more concerned about carriers doing = things to regulate or degrade WebRTC flows than a failure of existing Internet mechanisms to enable them. =20 Significant focus on QOS before we better enable TURN to be easily used = in a browser environment taking advantage or normal web characteristics (as opposed to historic telephony constructs) would seem to be highly distracting at this point. =20 Cheers, John =20 AVAYA 1.919.425.8446=20 =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 12:43 PM To: Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 =20 On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston = wrote: =20 Personally, I am not sure how much QoS is actually in scope for TRAM. = Have you been following RMCAT where congestion avoidance for RTP is being developed? I see some overlap in your goals and the goals of that work. =20 I'd concentrate on the TURN application-level functionality, for now, = and I'd leave QoS for the future discussions. ------=_NextPart_000_06F9_01CF3312.7C8EE080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

(A= fter having typed this up; I see today’s charter discussion etc. = that I haven’t read yet, but it will hopefully will be clearer by = pointing at this entry.)

 

Hi= John, and

Co= llin, P=E5l, Magnus, Charles,=A0 Simon,

 

In= my step A) B) and D) efforts in = http://www.ietf.org/mail-archive/web/tram/current/msg00275.html = fo= r the &#= 8220;mission to bring quality to real-time = traffic over our best effort Internet is a huge mission, I am convinced = it not a huge task – We just have to be a bit clever here :). I = only see these few standard steps required, before it can = happen!&#= 8221;

 

To= accomplish these (1), (2), (3)-things for:

(1= ) = *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in = addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP = variants) to quickly allow us to finally enjoy the high quality and = connectivity (NAT/firewall traversal) of real-time communication = services now possible, for  

(2= ) = *all* WebRTC browsers *and* dedicated clients (not using = WebRTC), under *all* OSs, and *all* current and future IP = networks

(3= ) *without* ha= ving to be forced into application specific networks (PSTN, IMS) instead = of the Internet (including OTT).

 

Th= ere are a lot of Mission Impossible, Pointers, Good arguments and other = things to consider in the mails from you guys that I have not (yet) = answered.

 

Al= low me to come back to those under THIS THREAD/Subject after having = figured out how to do it in a structured way, with the aim of collecting = the summary in a new "Interfacing to QoS" thread, that only = will relate to how IP/IETF/WebRTC level 3-5 – *can = interface* to the QoS-stuff (whether within IETF, in the telephony = world or elsewhere e.g. IEEE Ethernet, mainly relating to lower = level).

 

I = think this is doable *without* ending up in any of the = (i= ), = (i= i), = (iii)-t= hings

(i= ) = will *not allow* ISP’s to use already available and = currently deployable quality IP pipes for real-time traffic to also be = used for WebRTC generated real-time traffic.

(i= i) = will *not allow* some network types (e.g. Cable Networks and = Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive = streaming video and file sharing. That all networks *will be = inhibited* from the very common and used method of simply providing = an extra IP pipe (often provided over the same wire but level-2 = separated) dedicated for real-time usage

(<= b>*by resisting TRAM implementation of step = B*)

*<= b>while* newer, fiber only type of networks, still can borrow = bandwidth at no extra cost, *by proprietary usage* of RFC 5285 by = browsers.

(i= ii) = will leave most ISPs to *only use* raw bandwidth capacity = increase that may have to be 10-folded to reach sufficient QoE when = WebRTC usage becomes popular (if at all possible, since unmanaged IP = pipes intermittently are filled, whatever bandwidth is = available).

(?= ) and possible other Evil -things.

 

I = refer to http://www.ietf.org/mail-archive/web/rtcweb/current/msg11548.html = for these “-things” and further.

 

 

Jo= hn, Alan, Henry (Sinnreich), Henning, Richard, Cullen, J=F6rgen = (Bj=F6rkner), Lars (Berggren) and other good friends since the early SIP = age (before SIP was “hijacked” into application specific = network and proprietary usage and nowadays rarely is used the IETF-way): =

 

I = want to point out how “confusing” the QoS-issue has been and = as hard as I will the fight Mission Impossible attitude, I will also = fight the = “it is all about bandwidth” and “it will go away with = time” = attitude… =A0(also in the above http = reference)

 

I = agree with parts of what John says below but the remedy to achieve the = Good (1), (2), (3)-things instead of the Evil (i= ), = (i= i), = (iii)-t= hings, is NOT to ignore QoS-things – It is the opposite! =

 

Fo= r you having more and relevant input – That has not been said, and = that you think I will not address anyway – in this = "Interfacing to QoS" path, please provide, but I will not be = able to process much more than already have been said – and I will = use http back-pointers for what has already been discussed in more = detail.

 

If= you want to point out QoS-stuff Requiring More Input-from/Feedback-to = the level 3 and above stuff IN ADDITION to what already has been = discussed here = http://www.ietf.org/mail-archive/web/tram/current/msg00302.html = =A0

Pl= ease also point out WHAT and WHY that can/or cannot be handled by the = methods proposed here and whether other existing methods can be used to = achieve the mission of "Interfacing to QoS" from IP =3D level = 3 to lower levels.

 

I = will do some thinking about what LISTs different things shall be brought = to and then split the [TRAM] [WEBRTC] and advice regarding involving = other list will be considered. Such will probably show up and happen = during this mission.

 

 

An= other thing from = http://www.ietf.org/mail-archive/web/tram/current/msg00275.html: = What name 

Footnote =
**[Karl]* For similar reasons I have started to say things like =
“the box containing the TURN server”. We should not change =
the TURN server spec into including specific QoS methods to apply (like =
reservation, changing DSCP bits or applying traffic shaping mechanism). =
What is happening here is that we share the traffic information that the =
TURN server gets hold of, with a QoS applying function (that will be =
different for different networks) in “the same box”. With =
“the same box” I mean that we for now don’t care about =
the interface/commands for sharing information between the TURN server =
and the QoS applying function. There may be a future need to =
specify/standardize this, but if we start doing that now and in TRAM, we =
risk ending up in a 10-year process before having something in place =
(which without a spec automatically will happen in vendor’s =
product development, by putting the TURN server into already available =
“QoS applying function” boxes (like firewalls or the mobile =
DPI/PCRF combination).
 
*What =
we need to consider and specify, is only what traffic info is required =
(to be provided by the application/browser) for “QoS applying =
functions” in different networks (including the very common =
reservation types) to do job (i.e. giving us good QoE for real-time =
applications).*

 

An= d Henry, I will have to continue to use the S(BC)-word and the = I(MS)-word, since you did not succeed to “eradicate” them = ;-) =A0Let’s hope we find a word for the above box (quite = undefined on the QoS-side – It is only the TURN side and traffic = info we are up to designing here) that does not need to be = “eradicated”. So no WebRTC-SBC I guess (hopefully it will = not even be WebRTC-specific), and ICE-SBC sounds crazy (since ICE was = developed to remove the need of SIP SBCs), the same applies to TURN-SBC = (which implies that this box hopefully is not even ICE-specific). = TURN-QoS-Interface box is relevant but long… =

 

/K= arl

 

PS= : To avoid being stopped by the “to many recipients” spam = filter, the Guys (including Mary) from

http://www.ietf.org/mail-archive/web/rtcweb/current/msg11548.html =

an= d the ones mentioned in the email are copied = separately.

 

 

Fr=E5n: Yoakum, = John H (John) [mailto:yoakum@avaya.com]
Skickat: den 20 = februari 2014 19:56
Till: Oleg Moskalenko; Alan = Johnston
Kopia: Karl Stahl; tram@ietf.org
=C4mne: = RE: [tram] Fwd: I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

+1

I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts.  There are other groups = doing QOS work and frankly I engage in WebRTC multimedia interactions = daily over the Internet, enterprise VPNs, and various combinations and = seldom suffer egregious quality issues.  I am more concerned about = carriers doing things to regulate or degrade WebRTC flows than a failure = of existing Internet mechanisms to enable them.

 

Significant focus on QOS before we better enable TURN to be easily = used in a browser environment taking advantage or normal web = characteristics (as opposed to historic telephony constructs) would seem = to be highly distracting at this point.

 

Ch= eers,

Jo= hn

 

AVAY= A
1.9= 19.425.8446

 

From:= tram [mailto:tram-bounces@ietf.org] = On Behalf Of Oleg Moskalenko
Sent: Thursday, February = 20, 2014 12:43 PM
To: Alan Johnston
Cc: Karl Stahl; = tram@ietf.org
Subject: = Re: [tram] Fwd: I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

<= div>

 

 

On = Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <alan.b.johnston@gmail.com> = wrote:

 

Personally, I am not sure how much = QoS is actually in scope for TRAM. Have you been following RMCAT where = congestion avoidance for RTP is being developed?  I see some = overlap in your goals and the goals of that = work.

 

I'd concentrate on the = TURN application-level functionality, for now, and I'd leave QoS for the = future discussions.

------=_NextPart_000_06F9_01CF3312.7C8EE080-- From nobody Wed Feb 26 09:36: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 E740F1A0363; Wed, 26 Feb 2014 05:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.851 X-Spam-Level: X-Spam-Status: No, score=-103.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 cny210KQ_aNY; Wed, 26 Feb 2014 05:53:14 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 348EF1A035E; Wed, 26 Feb 2014 05:53:13 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-37-530df1c6ab57 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 71.69.10875.6C1FD035; Wed, 26 Feb 2014 14:53:10 +0100 (CET) Received: from [131.160.126.202] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.2.347.0; Wed, 26 Feb 2014 14:53:09 +0100 Message-ID: <530DF1C5.60007@ericsson.com> Date: Wed, 26 Feb 2014 15:53:09 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" , Spencer Dawkins References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <530D56F7.5070900@gmail.com> <55FF8505-78C7-483B-B923-368ED01CE37A@cisco.com> In-Reply-To: <55FF8505-78C7-483B-B923-368ED01CE37A@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyM+Jvje6xj7zBBne6ZCwOLb7EatExmc1i xp+JzBbvetayWaz9185u0b30P4vFoXkXGC2WTdnDbNE4187iw9oLbA5cHlN+b2T1aFnVy+yx c9Zddo8lS34yeXzaOp/FY90Hc49Pv14xBrBHcdmkpOZklqUW6dslcGV8vNfBWLCEt+LRy2XM DYz7uLoYOTkkBEwkeo5/YYewxSQu3FvP1sXIxSEkcIhRYsuKK0wQzlpGifNNG9hAqngFNCVW zNrG0sXIwcEioCrxryESJMwmYCGx5dZ9FhBbVCBK4ueVBewQ5YISJ2c+AYuLCKRItH2FmMks 8IpJ4v3sw4wgc4QFiiT6XnBD7JrIKrHoXyfYLk4BW4lvt+czgdRICIhL9DQGgYSZBfQkplxt YYSw5SW2v53DDGILCWhLLH/WwjKBUWgWktWzkLTMQtKygJF5FSN7bmJmTnq54SZGYJwc3PJb dwfjqXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDoXPLyismZuItX w0K2TPveLNzKKc7iF3+7hbP2hMJpab6HmrW39IzE9ztfbF7LO6f0Wt8ynsIbIof5/5vUplTx qV6Ru3ahg/GXy1IPq5tXmd8UHZm1cG3j0U0Zq2yLS4X3Fyj8e3yN65dif59aTm7cnUmCF8SW ystKPPEX0Z6oeWvOJfWVG6WVWIozEg21mIuKEwHrU3HeYQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FD6JqXN8FO6XETZrB_X7hk3PlDU X-Mailman-Approved-At: Wed, 26 Feb 2014 09:36:39 -0800 Cc: "tram@ietf.org" , Spencer Dawkins , "rtcweb@ietf.org" , IESG IESG , Barry Leiba Subject: Re: [rtcweb] BCP over TURN will not be in scope ... and MPLS over UDP over TURN will not be in scope ... and ... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 13:53:17 -0000 Hi Cullen, I am keeping the cc: as is in order to close this thread but let's try and avoid cross-posting in future discussions. Thanks for your input. I agree that explicit charters are better than implicit ones, especially around areas that can be controversial. Given that we are not going to recharter the WG in the next few days, we are going to focus the session in London on items that are *explicitly* chartered. After London, if we need to tighten the charter somehow, we will do that. Cheers, Gonzalo On 26/02/2014 10:26 AM, Cullen Jennings (fluffy) wrote: > > On Feb 26, 2014, at 10:52 AM, Spencer Dawkins wrote: > >> So ... TRAM was chartered last Thursday ... >> >> I'm gonna let Gonzalo (Yet Another Soon-to-be Former AD Serving as WG Chair) and Simon actually chair their working group for at least a full week before intruding further, but for now, let's assume that the working group wants to work on the milestones they signed up for last week, and see how badly that assumption blows up, rather than talk about rechartering every time someone proposes a topic that's out of scope. >> >> I look forward to attending the first working group session next week, and to balloting on six TRAM drafts before IETF 92. >> >> Thanks, >> >> Spencer, as the responsible AD > > Makes sense - I get the desire to let some work get done. > > I worry that every time someone says something is is not in scope of this WG, it is not going to feel like an open consensus decisions but is instead going to feel like a arbitrary fiat decisions by a chair or IESG made in a dark and smoky room - I hope I am wrong. > > From nobody Wed Feb 26 11:38: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 4E8511A088D for ; Wed, 26 Feb 2014 11:38:28 -0800 (PST) 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 MYrcybqsfTCz for ; Wed, 26 Feb 2014 11:38:27 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id D0CF51A0886 for ; Wed, 26 Feb 2014 11:38:26 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta04.westchester.pa.mail.comcast.net with comcast id X0Pk1n0041vXlb8547eRXL; Wed, 26 Feb 2014 19:38:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id X7eR1n0093ZTu2S3d7eRW5; Wed, 26 Feb 2014 19:38:25 +0000 Message-ID: <530E42B1.4030500@alum.mit.edu> Date: Wed, 26 Feb 2014 14:38:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <530D1C00.7080701@jesup.org> In-Reply-To: <530D1C00.7080701@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393443505; bh=KHJmE6zJ2/2xte+j3SNqRnTFII800umo6UAJKgHEYHc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JzJpunYrEzyM0j0xbrq2fciPg6o+YEX2HbSNmkMa055HP41VNDAATDi1KLkxvXclY fx5Vp6/YOHHv9NBBwXkA+tDYeadDc/tzhuOvLkwdH3s7sfW4GV5mch2soDzU4IgSPZ 47NdUtHUdqRDMO+kkjwdhOcPCmJxbmI/syvxkOWe6ee/cInTCe3jEbW3CQvp5Hxr57 1MA1slEy61Pc4jizcf8IC/2hF2hsk2jwvFnlKtkmbC5BmrS8BFCeDr0CSuiTQB7xkt 2+qVEP0/Lb9NlG7k7CybiwpTWsrVh1Mbe3ULXpEjVOo9SEsP8A//hEa7x8Deak89vH uTJnZRfJpLVfg== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yWMxu0dIMVGObmY_slITLfAQetA Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 19:38:28 -0000 Randell, I agree that most of this discussion belongs elsewhere. But there are a few bits that probably do belong here. CLUE needs *something* that provides an e2e reliable channel. It could be a lot of things, e.g. TCP or TLS. We decided to go with the SCTP-based data channel that RTCWEB is defining so that we had the potential for a Webrtc endpoint to participate in CLUE without a gateway on the clue channel. That means we will also be using the same stack between non-webrtc clue endpoints that are using SIP for signaling. We are still undecided on whether to use DCEP or SDP O/A to negotiate the channel we use. If we use DCEP it will be straightforward for a webrtc endpoint. But that is a little unnatural for the sip endpoints. For them, the SDP O/A approach would be more natural. It doesn't matter much if the *only* channel being used is the clue channel. It will start to matter if there is a desire to use other channels for features that can coexist with clue. E.g. BFCP. (But now we see a proposal to put BFCP over websocket, so maybe it won't ever be an issue for us.) The important thing is that if clue decides to use SDP O/A for this, (the ejzak draft) then we must be confident that it will be feasible for a webrtc endpoint, via javascript, to participate in this negotiation and use it to set up the clue data channel. That is the part that belongs in rtcweb. Thanks, Paul On 2/25/14 5:41 PM, Randell Jesup wrote: > On 2/24/2014 10:21 AM, Christer Holmberg wrote: >> >> I still don't think the information belong to SDP - they define >> protocol characteristics. The protocol specification should define >> re-transmission timers etc. >> >> Anyway, we can argue about it later. At this moment I think the focus >> should be on whether to move forward with the mechanism to begin with, >> and the main feature of the mechanism - which is about negotiating >> usage of channels :) > > This (whether to move forward) is my concern (in addition to Mary's > about this being the wrong group - MMUSIC is where the SDP should be and > has been). > > The apparent justification for this document is "This document defines > SDP-based out-of-band negotiation procedures to establish WebRTC data > channels for transport of well-defined sub- protocols." This seems a > pretty sparse justification. > > We very purposely avoided using SDP for channel setup (after MUCH > discussion at Boston and elsewhere). That isn't to say that for > non-webrtc usage, one could define an SDP used to externally-negotiate > the settings for DataChannels, which this appears to be. But I think > there should a clearer statement as to "why" we should invest the time > to standardize this now, not just that we "can". For example, if CLUE > really wants to use this instead of in-band opens, then maybe there's a > reason to do so - but don't expect webrtc endpoints to implement this. > And if so, it should be done in CLUE by request to MMUSIC. > > At this point I don't see need to move forward with this, and certainly > not here. And I certainly don't want this to delay finalizing the stuff > needed in MMUSIC for WebRTC use of DataChannels > From nobody Wed Feb 26 11:50: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 D9AD61A01E4 for ; Wed, 26 Feb 2014 11:50:03 -0800 (PST) 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 1MCEIRBdyXwh for ; Wed, 26 Feb 2014 11:50:03 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id CD4171A015C for ; Wed, 26 Feb 2014 11:50:02 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta14.westchester.pa.mail.comcast.net with comcast id X0US1n0031wpRvQ5E7q1Cu; Wed, 26 Feb 2014 19:50:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id X7q01n00u3ZTu2S3e7q1Tw; Wed, 26 Feb 2014 19:50:01 +0000 Message-ID: <530E4568.6090402@alum.mit.edu> Date: Wed, 26 Feb 2014 14:50:00 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> In-Reply-To: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393444201; bh=RX9k9CErxdIVpoiMw4indDlj7GcclVojDFlPh4et96w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=D7sqt9j6zUalkPpVQUAFBp+e8ljANFzqLTqWgRhVXfgxFqXT8YYVvzWYN6JwknJqz pdOwiHf65wcd7URAJpaO904GnjwfgUMa+A9Xg62HkNTlnukrC43VJKZZv1vDeavWDY lqnY8dH1lcL8cSUk7tNDFe4gbR94JX+rfHaulGEyjPYt1ZjVz6y8znllZfB/Q1QVsH hFP+7lXwkVz3b6jdc0/5cYqlpFkGlNCZSIBoUhfB4oKSE1QMdrMmUTKpImDiLzwMa8 wr99EIR4wi/2OAZvtFQy1G1SzAM1kcP5i/6seZ7Ft8DMBbpaytVHXQYotMmUtA6QwB RAWduo5sT4M3Q== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1DbT231Smg3W3E9I5wTDbjLCJ3Q Subject: Re: [rtcweb] Open data channel issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 19:50:04 -0000 Michael, There have been no replies to my comments: http://www.ietf.org/mail-archive/web/rtcweb/current/msg11518.html http://www.ietf.org/mail-archive/web/rtcweb/current/msg11519.html The first of those is about channels, the 2nd about DCEP. One of my issues is that the partitioning between those two drafts is awkward. At the least some things from DCEP should be moved to the channel draft. It might be better to just merge those two drafts, or do a serious refactoring. Thanks, Paul On 2/25/14 6:44 PM, Michael Tuexen wrote: > Dear all, > > Magnus asked me to send a list of open issues regarding data channels > to the list. Here is my current list: > > > * Priority > The W3C hasn't defined it yet. Neither for the (S)RTP media nor for the > data channels. We agreed on using a non strict policy for the data channels > (some sort of wighted fair queueing). That is all. > > * Protocol > It seems not to be clear what needs to be provided when registering a > (sub)-protocol at IANA. And the name of the registry is unclear... > > * SCTP parameters. > There was discussed the issue how to set SCTP parameters, especially path.max.retrans > and association.max.retrans. Also HB.Interval might be of interest. > RFC 4060 recommends path.max.retrans=5, association.max.retrans=10, but has multihoming > in mind. To avoid the dormant state, path.max.retrans = association.max.retrans should be used. > I would suggest 10 for this value. Should HEARTBEATs be disabled? > > * U-C 7: Proxy browsing > > * Alternate CC for SCTP > Currently there is only the standard CC. However, in some places negotiation of CC is > mentioned. > > I'm currently going through the backlog of comments regarding the data channels > ID and I'll try to address the issues. If I find other issues, I send an update > to the above list. > > Best regards > Michael > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Wed Feb 26 12:02: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 BF7AE1A08CE for ; Wed, 26 Feb 2014 12:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 YMWxg7P2hTwt for ; Wed, 26 Feb 2014 12:02:45 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F0D401A08C8 for ; Wed, 26 Feb 2014 12:02:43 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-e3-530e486133f5 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7D.A5.10875.1684E035; Wed, 26 Feb 2014 21:02:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 21:02:41 +0100 From: Christer Holmberg To: Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzwgAIpVwCAAV9MgP//6QVg Date: Wed, 26 Feb 2014 20:02:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1BCD34@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <530D1C00.7080701@jesup.org> <530E42B1.4030500@alum.mit.edu> In-Reply-To: <530E42B1.4030500@alum.mit.edu> 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+NgFjrALMWRmVeSWpSXmKPExsUyM+JvjW6SB1+wwfX5/BYrNhxgtVj7r53d gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4udmmYI5ixdxnP1gbGK9LdTFyckgImEhs //afEcIWk7hwbz1bFyMXh5DAIUaJ+wsWMUE4Sxgl1h3pZu1i5OBgE7CQ6P6nDdIgIuAr0Xv5 HFizsECsRPvjHUwQ8TiJRw+2sUPYURIvP15iBbFZBFQlXiz/zwJi8wL1Hpiwjxli/iJmiaVP VjCDJDgFdCROnHoAVsQIdNH3U2vAhjILiEvcejKfCeJSAYkle84zQ9iiEi8f/2OFsJUkFt3+ DFWvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzsuYmZOenl hpsYgbFwcMtv3R2Mp86JHGKU5mBREuf98NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj 8oNZW4I5j3h/calfxSi9R9dnGdfCJMOIs1wO9uZzawoMV287yv576qH+jw1Gl6IXXdUIl/rA EfI94neSe4A8z1LfR48yfV5W1D2sWe6iy7uiz8i5WWyRis78Scv32Pav6VhomXnm9znxz6uf 7av/yvZ9g5GEofXVIx6Tn+3i2L7pR7N9VEaIEktxRqKhFnNRcSIAPtMNiVMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gb2KHfOqssIjLjFvLvyqOvayVbY Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 20:02:52 -0000 Hi, Let's also keep in mind that there has been suggestions to negotiate the ch= annels using SDP, but in addition also use DCP (I assume that is what your = DCEP abbreviation stands for :) to explicitly open the negotiated channels. But, again, as long as JavaScript can access the information (stream id val= ue etc), in order to add it to the SDP sent on the wire, and as long as the= usage of DCP is optional (it was earlier indicated that it IS optional) I = don't think there should be any impacts on WebRTC. Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 26 February 2014 21:38 To: rtcweb@ietf.org Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-c= hannel-sdpneg-00 Randell, I agree that most of this discussion belongs elsewhere. But there are a few bits that probably do belong here. CLUE needs *something* that provides an e2e reliable channel. It could be a= lot of things, e.g. TCP or TLS. We decided to go with the SCTP-based data = channel that RTCWEB is defining so that we had the potential for a Webrtc e= ndpoint to participate in CLUE without a gateway on the clue channel. That means we will also be using the same stack between non-webrtc clue end= points that are using SIP for signaling. We are still undecided on whether to use DCEP or SDP O/A to negotiate the c= hannel we use. If we use DCEP it will be straightforward for a webrtc endpo= int. But that is a little unnatural for the sip endpoints.=20 For them, the SDP O/A approach would be more natural. It doesn't matter much if the *only* channel being used is the clue channel= . It will start to matter if there is a desire to use other channels for fe= atures that can coexist with clue. E.g. BFCP. (But now we see a proposal to= put BFCP over websocket, so maybe it won't ever be an issue for us.) The important thing is that if clue decides to use SDP O/A for this, (the e= jzak draft) then we must be confident that it will be feasible for a webrtc= endpoint, via javascript, to participate in this negotiation and use it to= set up the clue data channel. That is the part that belongs in rtcweb. Thanks, Paul On 2/25/14 5:41 PM, Randell Jesup wrote: > On 2/24/2014 10:21 AM, Christer Holmberg wrote: >> >> I still don't think the information belong to SDP - they define=20 >> protocol characteristics. The protocol specification should define=20 >> re-transmission timers etc. >> >> Anyway, we can argue about it later. At this moment I think the focus=20 >> should be on whether to move forward with the mechanism to begin=20 >> with, and the main feature of the mechanism - which is about=20 >> negotiating usage of channels :) > > This (whether to move forward) is my concern (in addition to Mary's=20 > about this being the wrong group - MMUSIC is where the SDP should be=20 > and has been). > > The apparent justification for this document is "This document defines=20 > SDP-based out-of-band negotiation procedures to establish WebRTC data=20 > channels for transport of well-defined sub- protocols." This seems a=20 > pretty sparse justification. > > We very purposely avoided using SDP for channel setup (after MUCH=20 > discussion at Boston and elsewhere). That isn't to say that for=20 > non-webrtc usage, one could define an SDP used to externally-negotiate=20 > the settings for DataChannels, which this appears to be. But I think=20 > there should a clearer statement as to "why" we should invest the time=20 > to standardize this now, not just that we "can". For example, if CLUE=20 > really wants to use this instead of in-band opens, then maybe there's=20 > a reason to do so - but don't expect webrtc endpoints to implement this. > And if so, it should be done in CLUE by request to MMUSIC. > > At this point I don't see need to move forward with this, and=20 > certainly not here. And I certainly don't want this to delay=20 > finalizing the stuff needed in MMUSIC for WebRTC use of DataChannels > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Feb 26 13: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 7AD4B1A071D for ; Wed, 26 Feb 2014 13:03:29 -0800 (PST) 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, 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 lxstObzqJTti for ; Wed, 26 Feb 2014 13:03:23 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1561A0718 for ; Wed, 26 Feb 2014 13:03:22 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:2457 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1WIldR-0004WR-6e for rtcweb@ietf.org; Wed, 26 Feb 2014 15:03:21 -0600 Message-ID: <530E564B.9070103@jesup.org> Date: Wed, 26 Feb 2014 16:02:03 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530E4568.6090402@alum.mit.edu> In-Reply-To: <530E4568.6090402@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zeVtdmX7LBy2N2ooCz4GPmJtteA Subject: Re: [rtcweb] Open data channel issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 21:03:29 -0000 On 2/26/2014 2:50 PM, Paul Kyzivat wrote: > Michael, > > There have been no replies to my comments: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg11518.html > http://www.ietf.org/mail-archive/web/rtcweb/current/msg11519.html > > The first of those is about channels, the 2nd about DCEP. One of my > issues is that the partitioning between those two drafts is awkward. > At the least some things from DCEP should be moved to the channel > draft. It might be better to just merge those two drafts, or do a > serious refactoring. There seem to have been a number of responses to your second posting at least. > How about: Each SCTP user message contains a so called Payload Protocol Identifier (PPID) that is passed to SCTP by the data channel layer and sent to its peer. This value is used to multiplex WebRTC Data Channel Establishment Protocol messages (defined in [I-D.ietf-rtcweb- data-protocol]) with messages containing user data on a data channel. The PPID is also used to distinguish UTF-8 encoded user data and binary encoded user data. That seems reasonable and clearer. > * Section 6.5 > > This section contains: Data channels can be opened by using internal or external negotiation. The details are out of scope of this document. A simple protocol for internal negotiation is specified in [I-D.ietf-rtcweb-data-protocol] and MUST be supported. > But internal and external negotiation are not defined in this document. > > I *thought* that internal negotiation was by definition negotiation by use of > rtcweb-data-protocol. (draft-ejzak-mmusic-data-channel-sdpneg-00 thinks so too, > but calls it "in-band negotiation".) There should be a good definition of these > terms, or reference to one. And more discussion if there can be other kinds of > internal negotiation. (If so, how would one be chosen?) Well, the text above says that ietf-rtcweb-data-protocol specifies an internal negotiation protocol, so it's not that far off. The split does allow someone to use an alternative negotiation protocol (internal or external). How about: Data channels can be opened by using negotiation within the SCTP association or external negotiation. External negotiation is defined as any method which results in an agreement as to the parameters of a channel and the creation thereof. The details are out of scope of this document. A simple protocol for negotiation within the SCTP association is specified in [I-D.ietf-rtcweb-data-protocol] and MUST be supported. Perhaps someone can wordsmith "external negotiation" better. > * Section 6.6: > > Say: All data sent on a Channel in both directions MUST be sent over the underlying stream using the reliability defined when the Channel was opened unless the options are changed, or per-message options are specified by a higher level. > Is the recipient to consider it an error if messages are received with options different from those > defined for the channel? Also, is it an error if messages are received with a PPID that isn't specified > in Section 8? (And what about PPID 50?) > How are such channel errors to be treated? I'd propose that if messages are received with options that don't match the initial definition, that fact should be ignored and the message processed. If messages with an unknown PID are received, those messages should be ignored. In both cases, logging of such an event to the application (or onerror calls in WebRTC W3 JS layers) is allowed but not required. Note that the onerror callback is currently under-defined, so this might change. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Wed Feb 26 14:07: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 D53D01A074D for ; Wed, 26 Feb 2014 14:06:59 -0800 (PST) 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 l1SamKy0ciBh for ; Wed, 26 Feb 2014 14:06:58 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE4E1A074A for ; Wed, 26 Feb 2014 14:06:58 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta08.westchester.pa.mail.comcast.net with comcast id X1qG1n0041HzFnQ58A6xSN; Wed, 26 Feb 2014 22:06:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id XA6w1n00h3ZTu2S3aA6w08; Wed, 26 Feb 2014 22:06:57 +0000 Message-ID: <530E6580.4080804@alum.mit.edu> Date: Wed, 26 Feb 2014 17:06:56 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530E4568.6090402@alum.mit.edu> <530E564B.9070103@jesup.org> In-Reply-To: <530E564B.9070103@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393452417; bh=KALa+m/5OUq43r4n2Xhq66HmobpSkLD+7OSFO3QprRQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FdJ9WSsTtW+SSz9ZSwOBtXteTXpMlsYhHgZx1YYnldMYPrJeaCqLCvKKa8C+DkD2w bA/OR7wydhdr9zKUxqZVN1rMFFbwYRp5paGkVjJ6lIMRcXJZajVLSUKCm3X+Qeucdk N0YfqbaC9HtT0vqV76ZB/kQOHVPdnKUwqX+p5M7BZjSHVGMvCeV+V9MWnalk+83pEJ /cGqrHB0xw8Z8pd6xn6yTNKJ+Ti9ZYlNEt6U6dxdWAUQy/yb9S2GlPIQfFRRMJJYYp QBIJcBML5qvNa1Yj9I7yWviNEXjNWlQkqm6fRna1Xbc/L6tadpxyqusuJbQWAhxMpI XpyzZmtIy6wpw== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dv4GV6eapNgLqjAB7ymLECR353Q Subject: Re: [rtcweb] Open data channel issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 22:07:00 -0000 On 2/26/14 4:02 PM, Randell Jesup wrote: > On 2/26/2014 2:50 PM, Paul Kyzivat wrote: >> Michael, >> >> There have been no replies to my comments: >> >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg11518.html >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg11519.html >> >> The first of those is about channels, the 2nd about DCEP. One of my >> issues is that the partitioning between those two drafts is awkward. >> At the least some things from DCEP should be moved to the channel >> draft. It might be better to just merge those two drafts, or do a >> serious refactoring. > > There seem to have been a number of responses to your second posting at > least. Well - *one*, and my reply. My mistake - I lost track, and only checked the first one when I sent this. :-( >> How about: > > Each SCTP user message contains a so called Payload Protocol > Identifier (PPID) that is passed to SCTP by the data channel layer > and sent to its peer. This value is used to multiplex WebRTC Data > Channel Establishment Protocol messages (defined in [I-D.ietf-rtcweb- > data-protocol]) with messages containing user data on a data > channel. The PPID is also used to distinguish UTF-8 encoded user > data and binary encoded user data. > > That seems reasonable and clearer. Thanks. >> * Section 6.5 >> >> This section contains: > > Data channels can be opened by using internal or external > negotiation. The details are out of scope of this document. > > A simple protocol for internal negotiation is specified in > [I-D.ietf-rtcweb-data-protocol] and MUST be supported. > >> But internal and external negotiation are not defined in this document. >> > > > I *thought* that internal negotiation was by definition negotiation > by use of > > rtcweb-data-protocol. (draft-ejzak-mmusic-data-channel-sdpneg-00 > thinks so too, > > but calls it "in-band negotiation".) There should be a good > definition of these > > terms, or reference to one. And more discussion if there can be other > kinds of > > internal negotiation. (If so, how would one be chosen?) > > Well, the text above says that ietf-rtcweb-data-protocol specifies an > internal negotiation protocol, > so it's not that far off. The split does allow someone to use an > alternative negotiation protocol > (internal or external). > > How about: > > Data channels can be opened by using negotiation within the SCTP > association or external > negotiation. External negotiation is defined as any method which > results in an agreement > as to the parameters of a channel and the creation thereof. > The details are out of scope of this document. > > A simple protocol for negotiation within the SCTP association is > specified in > [I-D.ietf-rtcweb-data-protocol] and MUST be supported. > Perhaps someone can wordsmith "external negotiation" better. ISTM the issue is that Internal vs. External isn't the key distinction. What is key is that there is one method that MUST be *supported* but need not be the only one used. Other mechanisms may be used. It doesn't really matter whether they are conducted internally (over the SCTP association) or externally (anything else). E.g., I could use DCEP to establish one channel, and then use my own private protocol over that to negotiate other channels. Would that be internal or external negotiation? Does it matter? >> * Section 6.6: >> >> Say: > > All data sent on a Channel in both directions MUST be sent over the > underlying stream using the reliability defined when the Channel was > opened unless the options are changed, or per-message options are > specified by a higher level. > > > Is the recipient to consider it an error if messages are received > with options different from those > > defined for the channel? Also, is it an error if messages are > received with a PPID that isn't specified > > in Section 8? (And what about PPID 50?) > >> How are such channel errors to be treated? > > > I'd propose that if messages are received with options that don't match > the initial definition, that fact should be ignored and the message > processed. > If messages with an unknown PID are received, those messages should be > ignored. I could live with that. It comes to a philosophical issue of whether you want to fail soft or fail hard. Could just explicitly say that behavior when the per-message SCTP parameters are inconsistent with the channel is nonconformant to this specification and undefined. And that behavior when PPIDS other than 50, 51, and 54 (did I remember right?) are used is also nonconformant and undefined. Note that the current partitionion makes it hard to specify conforming use of PPID 50. From a channel perspective you can use it, but from a DCEP perspective you can only use it a certain way. (This would be easier if the two were merged. Since DCEP is mandatory to implement, there seems little reason to keep them separate. > In both cases, logging of such an event to the application (or onerror > calls in WebRTC W3 JS layers) is allowed but not required. Note that the > onerror callback is currently under-defined, so this might change. If there is a goal to report errors in a defined way then that would change things. Thanks, Paul From nobody Wed Feb 26 14: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 3A5FA1A0763 for ; Wed, 26 Feb 2014 14:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 pVnn9g0J2Usk for ; Wed, 26 Feb 2014 14:21:42 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC031A072D for ; Wed, 26 Feb 2014 14:21:41 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-48-530e68f38ffa Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 6F.F5.04853.3F86E035; Wed, 26 Feb 2014 23:21:39 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 23:21:38 +0100 From: Christer Holmberg To: Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Open data channel issues Thread-Index: AQHPMoOZ4jU/ikTW1ES5S7sUcSYm2ZrH4hIAgAAUIoCAABIhAIAAE9bQ Date: Wed, 26 Feb 2014 22:21:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1BE0E0@ESESSMB209.ericsson.se> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530E4568.6090402@alum.mit.edu> <530E564B.9070103@jesup.org> <530E6580.4080804@alum.mit.edu> In-Reply-To: <530E6580.4080804@alum.mit.edu> 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+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvje7nDL5ggxczzCxWbDjAarH2Xzu7 A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXx7tZltoIDwhXrNnxkbGA8xt/FyMkhIWAi ceXSI0YIW0ziwr31bF2MXBxCAicYJR5sWMMI4SxhlPh54TdzFyMHB5uAhUT3P22QBhEBX4ne y+cYQcLCAnoSU86pQIT1JTZeWMYMYbtJ3L/TyA5iswioSlxZ1cACYvMCtXZ+n8UGYgsJLGWU 6F8nCGJzCuhI/JzxEuweRqB7vp9awwRiMwuIS9x6Mp8J4k4BiSV7zjND2KISLx//Y4WwlSQW 3f4MVa8jsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjJLFqcXF uelGBnq56bkleqlFmcnFxfl5esWpmxiB0XJwy2+jHYwn99gfYpTmYFES573OWhMkJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgZE7+q+O7Iry47Pn5ag+/e6SrzYvs1b715sv52+Gv/glNPeT SK7w3Ix9fROrAjQ+pC4pYZ6z4ajxTlPx6frzrxSFOsgLOtuJXF0ewzEx99w9R/HnG9wUE3Y8 VmdKOZJczNCjtv3fC5n3lZ37LW/2JEbt/R06R6c1iyPq9rKDvl/eFXJdmW9mG6vEUpyRaKjF XFScCACL6eSnZAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LSzhTjg-E6SbAO-tvG_vcsYo_pc Subject: Re: [rtcweb] Open data channel issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 22:21:44 -0000 Hi, >>> * Section 6.5 >>> >>> This section contains: >> >> Data channels can be opened by using internal or external >> negotiation. The details are out of scope of this document. >> >> A simple protocol for internal negotiation is specified in >> [I-D.ietf-rtcweb-data-protocol] and MUST be supported. >> >>> But internal and external negotiation are not defined in this document. >>> >> >> > I *thought* that internal negotiation was by definition negotiation=20 >> by use of > rtcweb-data-protocol.=20 >> (draft-ejzak-mmusic-data-channel-sdpneg-00 >> thinks so too, >> > but calls it "in-band negotiation".) There should be a good=20 >> definition of these > terms, or reference to one. And more discussion=20 >> if there can be other kinds of > internal negotiation. (If so, how=20 >> would one be chosen?) >> >> Well, the text above says that ietf-rtcweb-data-protocol specifies an=20 >> internal negotiation protocol, so it's not that far off. The split=20 >> does allow someone to use an alternative negotiation protocol=20 >> (internal or external). >> >> How about: >> >> Data channels can be opened by using negotiation within the SCTP=20 >> association or external >> negotiation. External negotiation is defined as any method which=20 >> results in an agreement >> as to the parameters of a channel and the creation thereof. >> The details are out of scope of this document. >> >> A simple protocol for negotiation within the SCTP association is=20 >> specified in >> [I-D.ietf-rtcweb-data-protocol] and MUST be supported. >> >> Perhaps someone can wordsmith "external negotiation" better. > >ISTM the issue is that Internal vs. External isn't the key distinction.=20 >What is key is that there is one method that MUST be *supported* but need = not be the only one >used. Other mechanisms may be used. It doesn't really = matter whether they are conducted >internally (over the SCTP association) o= r externally (anything else). I think the MUST-be-supported-method is a separate question. >E.g., I could use DCEP to establish one channel, and then use my own priva= te protocol over that to >negotiate other channels. Would that be internal = or external negotiation? Does it matter? I guess they would both be in-band methods. Maybe using in-band and out-of-= band terminology would be more clear - and more aligned with existing termi= nology. Regards, Christer From nobody Wed Feb 26 17:12: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 85B361A030E for ; Wed, 26 Feb 2014 17:12:18 -0800 (PST) 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 7uStafjX7roE for ; Wed, 26 Feb 2014 17:12:16 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 574321A020A for ; Wed, 26 Feb 2014 17:12:16 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta08.westchester.pa.mail.comcast.net with comcast id XC1F1n00B0QuhwU58DCECE; Thu, 27 Feb 2014 01:12:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id XDCE1n0033ZTu2S3NDCEPy; Thu, 27 Feb 2014 01:12:14 +0000 Message-ID: <530E90ED.7000708@alum.mit.edu> Date: Wed, 26 Feb 2014 20:12:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "rtcweb@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <530D1C00.7080701@jesup.org> <530E42B1.4030500@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1BCD34@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1BCD34@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393463534; bh=ItQry7cgucVT2p1J6PcjTQvlPtJeOvz25QZONMpP28s=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EZBcdqXvawx3SMjVirnSZZI5awATmxmdtz9pWn+d3abf/kZYWtTndLTUDkQaaYQAD LK3rbox3nO2nO5shw8pFwUfnBhf01oPkgEiP97Ou8D/+mF0jp+OthUvY8C4OyI2UbA Q3IBYHS9dIL+I+BJovYq7RuHP74WZtBSxneVeeeL/nHEWWY1otpR8qSpYmVkTPNTDm UoPVrfSfGDmsU3jK8nmJvu09ni0zxyFnOU+4eXe1aSrv6m5w7bQ7FNmmSQPJHNvd11 doebu2MYus3v4CKRFgcJdIDqQy6Whx1pLzdYXn45fTzabQWrYjp6qTOTx1vAUs1WaD Yg1bbkX08Wg8Q== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zmYJC3bPg9oIgLgqZGEtoIb_jw8 Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 27 Feb 2014 01:12:18 -0000 On 2/26/14 3:02 PM, Christer Holmberg wrote: > Hi, > > Let's also keep in mind that there has been suggestions to negotiate the channels using SDP, but in addition also use DCP (I assume that is what your DCEP abbreviation stands for :) to explicitly open the negotiated channels. DCEP is the *new* acronym, from the most recent version. > But, again, as long as JavaScript can access the information (stream id value etc), in order to add it to the SDP sent on the wire, and as long as the usage of DCP is optional (it was earlier indicated that it IS optional) I don't think there should be any impacts on WebRTC. > > Regards, > > Christer > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 26 February 2014 21:38 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 > > Randell, > > I agree that most of this discussion belongs elsewhere. > But there are a few bits that probably do belong here. > > CLUE needs *something* that provides an e2e reliable channel. It could be a lot of things, e.g. TCP or TLS. We decided to go with the SCTP-based data channel that RTCWEB is defining so that we had the potential for a Webrtc endpoint to participate in CLUE without a gateway on the clue channel. > > That means we will also be using the same stack between non-webrtc clue endpoints that are using SIP for signaling. > > We are still undecided on whether to use DCEP or SDP O/A to negotiate the channel we use. If we use DCEP it will be straightforward for a webrtc endpoint. But that is a little unnatural for the sip endpoints. > For them, the SDP O/A approach would be more natural. > > It doesn't matter much if the *only* channel being used is the clue channel. It will start to matter if there is a desire to use other channels for features that can coexist with clue. E.g. BFCP. (But now we see a proposal to put BFCP over websocket, so maybe it won't ever be an issue for us.) > > The important thing is that if clue decides to use SDP O/A for this, (the ejzak draft) then we must be confident that it will be feasible for a webrtc endpoint, via javascript, to participate in this negotiation and use it to set up the clue data channel. That is the part that belongs in rtcweb. > > Thanks, > Paul > > On 2/25/14 5:41 PM, Randell Jesup wrote: >> On 2/24/2014 10:21 AM, Christer Holmberg wrote: >>> >>> I still don't think the information belong to SDP - they define >>> protocol characteristics. The protocol specification should define >>> re-transmission timers etc. >>> >>> Anyway, we can argue about it later. At this moment I think the focus >>> should be on whether to move forward with the mechanism to begin >>> with, and the main feature of the mechanism - which is about >>> negotiating usage of channels :) >> >> This (whether to move forward) is my concern (in addition to Mary's >> about this being the wrong group - MMUSIC is where the SDP should be >> and has been). >> >> The apparent justification for this document is "This document defines >> SDP-based out-of-band negotiation procedures to establish WebRTC data >> channels for transport of well-defined sub- protocols." This seems a >> pretty sparse justification. >> >> We very purposely avoided using SDP for channel setup (after MUCH >> discussion at Boston and elsewhere). That isn't to say that for >> non-webrtc usage, one could define an SDP used to externally-negotiate >> the settings for DataChannels, which this appears to be. But I think >> there should a clearer statement as to "why" we should invest the time >> to standardize this now, not just that we "can". For example, if CLUE >> really wants to use this instead of in-band opens, then maybe there's >> a reason to do so - but don't expect webrtc endpoints to implement this. >> And if so, it should be done in CLUE by request to MMUSIC. >> >> At this point I don't see need to move forward with this, and >> certainly not here. And I certainly don't want this to delay >> finalizing the stuff needed in MMUSIC for WebRTC use of DataChannels >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Wed Feb 26 17:15: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 83EEA1A02AA for ; Wed, 26 Feb 2014 17:15:11 -0800 (PST) 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 R6fNqWcIRmoj for ; Wed, 26 Feb 2014 17:15:10 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id AF8971A033D for ; Wed, 26 Feb 2014 17:15:09 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA11.westchester.pa.mail.comcast.net with comcast id XD0e1n0060QuhwU5BDF8dB; Thu, 27 Feb 2014 01:15:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id XDF71n00W3ZTu2S3NDF7u2; Thu, 27 Feb 2014 01:15:08 +0000 Message-ID: <530E919B.6030208@alum.mit.edu> Date: Wed, 26 Feb 2014 20:15:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "rtcweb@ietf.org" References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530E4568.6090402@alum.mit.edu> <530E564B.9070103@jesup.org> <530E6580.4080804@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1BE0E0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1BE0E0@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393463708; bh=Mnv9FLO3A9ZDquMRHIjQ0VCGAV2XBREAmbg6uyeaM34=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Dnt8NaPKP9IexFClunKfwLS6cJIp+UhSFNDcZpnGV/VpZ3xj8aYbNic9/Ut3hlUe7 pYu1KLpbYu5ODqd+s77jwz5PfaIRSy4AlfALoZL7dqnfw9YJMf7rIgZw+1VeQza2uy NPWaNQvqxW/TNELC8dDE4mmiyWAn6r2gFc372R9ivOXty9JJYn1jLVds7lqJY5Flew CY3qv6dcbP3VUID3GPSUbiBMSy+j1ScbMw3mFnLYfRL8pW3d0EHuCF+kEzxlOuABhR o9J71Vxl6qqVyUGjZoBH2MfiNLEJtpwUvq9KJsHJl+N5WzB8LAzLOpnNR5a98v/C6X MceCAerwjTUMQ== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/j9SRDZLiiRd0OsblnvS_UtMMKss Subject: Re: [rtcweb] Open data channel issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 27 Feb 2014 01:15:11 -0000 On 2/26/14 5:21 PM, Christer Holmberg wrote: > Hi, > >>>> * Section 6.5 >>>> >>>> This section contains: >>> >>> Data channels can be opened by using internal or external >>> negotiation. The details are out of scope of this document. >>> >>> A simple protocol for internal negotiation is specified in >>> [I-D.ietf-rtcweb-data-protocol] and MUST be supported. >>> >>>> But internal and external negotiation are not defined in this document. >>>> >>> >>> > I *thought* that internal negotiation was by definition negotiation >>> by use of > rtcweb-data-protocol. >>> (draft-ejzak-mmusic-data-channel-sdpneg-00 >>> thinks so too, >>> > but calls it "in-band negotiation".) There should be a good >>> definition of these > terms, or reference to one. And more discussion >>> if there can be other kinds of > internal negotiation. (If so, how >>> would one be chosen?) >>> >>> Well, the text above says that ietf-rtcweb-data-protocol specifies an >>> internal negotiation protocol, so it's not that far off. The split >>> does allow someone to use an alternative negotiation protocol >>> (internal or external). >>> >>> How about: >>> >>> Data channels can be opened by using negotiation within the SCTP >>> association or external >>> negotiation. External negotiation is defined as any method which >>> results in an agreement >>> as to the parameters of a channel and the creation thereof. >>> The details are out of scope of this document. >>> >>> A simple protocol for negotiation within the SCTP association is >>> specified in >>> [I-D.ietf-rtcweb-data-protocol] and MUST be supported. >>> >>> Perhaps someone can wordsmith "external negotiation" better. >> >> ISTM the issue is that Internal vs. External isn't the key distinction. >> What is key is that there is one method that MUST be *supported* but need not be the only one >used. Other mechanisms may be used. It doesn't really matter whether they are conducted >internally (over the SCTP association) or externally (anything else). > > I think the MUST-be-supported-method is a separate question. > >> E.g., I could use DCEP to establish one channel, and then use my own private protocol over that to >negotiate other channels. Would that be internal or external negotiation? Does it matter? > > I guess they would both be in-band methods. Maybe using in-band and out-of-band terminology would be more clear - and more aligned with existing terminology. My point is that the real distinction is between the one std mechanism and everything else. For purposes of discussions here it doesn't matter whether the non-std mechanisms are in-band or out of band. (Of course to the people using them the distinction is significant. But it is their problem, not ours.) Thanks, Paul From nobody Wed Feb 26 23:47: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 59A981A0296 for ; Wed, 26 Feb 2014 10:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 HMTd4xqBnFHs for ; Wed, 26 Feb 2014 10:59:44 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id F40AD1A07FC for ; Wed, 26 Feb 2014 10:59:28 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1QIxROZ029056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 26 Feb 2014 12:59:27 -0600 (CST) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s1QIxQkT014134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Feb 2014 13:59:26 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 26 Feb 2014 13:59:26 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EP/+ONLQ//sW+yX/9iL+AP/roUyA/9ZDm9A= Date: Wed, 26 Feb 2014 18:59:26 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> <530CCB54.4000106@alum.mit.edu> <530D189F.8020804@alum.mit.edu> In-Reply-To: <530D189F.8020804@alum.mit.edu> 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/2zDliNA_WXLxzVmCIYVDu9Mwdfk X-Mailman-Approved-At: Wed, 26 Feb 2014 23:47:07 -0800 Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Feb 2014 18:59:47 -0000 + mmusic - rtcweb (in bcc) Hi Paul, I wanted to close this email loop. Please see my inline comments. > > > > [Raju] If I understand correctly, these parameters simply define the > > data channel transport properties. Yes, they may have some correletion > with > > subprotocol, but that's not a one-to-one mapping. > > For example, a given subprotocol could run on a reliable or > > unreliable transport; depending on app needs it may use unreliable > > transport and deal with reliablity at subprotocol stack (or ignore it). >=20 > In some cases. But in general it is easy and common to define a protocol > that needs a reliable transport, and it won't work without one. >=20 > What if every application in the world that uses TCP had the option to > specify if it was reliable or not? How many would screw it up? >=20 [Raju]=20 Application subprotocol users need to know the transport needs for the prot= ocol and select a single transport if multiple options exist. This is simil= ar to how users select TCP or UDP when implementing any Layer5 protocol (e.= g. SIP) on top of Layer 4. If APIs abstract this subprotocol then the transport selection can be hidde= n under the API (if only one choice exists) and API user won't have to spec= ify a transport.=20 We really appreciate your time in providing valuable comments on these draf= ts! Best Regards! Raju From nobody Thu Feb 27 11:55: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 1E86B1A0661; Thu, 27 Feb 2014 11:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.7 X-Spam-Level: X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-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 SRhvqrIDo4ZZ; Thu, 27 Feb 2014 11:55:17 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 55E641A04B7; Thu, 27 Feb 2014 11:55:16 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1RJtDUB011487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Feb 2014 13:55:13 -0600 (CST) 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 s1RJtAdB022388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 14:55:13 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Thu, 27 Feb 2014 14:55:11 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel Thread-Index: AQHPMv00Ot+PDux+H0inH2oRraNWlJrH7JxQgABjlQCAAR/dwA== Date: Thu, 27 Feb 2014 19:55:11 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> <530E4E34.4010707@alum.mit.edu> In-Reply-To: <530E4E34.4010707@alum.mit.edu> 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/MWUJiRK_cf2FEw9kFB7_FsE2Dng Subject: Re: [rtcweb] [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 27 Feb 2014 19:55:20 -0000 + rtcweb as it impacts DCP draft. Please see comments inline. > I would like some clarity about how this interacts with DCEP. >=20 > IMO these are not mutually exclusive. But they must be used with care. [Raju] I debated on this with myself before concluding in my earlier reply that they are mutually exclusive. My mistake, instead of=20 concluding I should have given options. To make this internal or=20 external per data channel granuality we need to add more=20 restrictions/notes to these draft.=20 http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-03#section-4 say= s: "To avoid glare in opening Channels, each side MUST use either even or odd Streams when sending a DATA_CHANNEL_OPEN message. The method used to determine which side uses odd or even is based on the underlying DTLS connection role when used in WebRTC, with the side acting as the DTLS client using even stream identifiers." Where as draft-ejzak-mmusic-data-channel-sdpneg determines this=20 based on SDP offerer (even) and answerer (odd). What if the SDP answerer becomes TLS client? The stream #id assignments conflict with SDP offer/answer. So, to avoid such conflict we need to add the following clarifications: 1. draft-ejzak-mmusic-data-channel-sdpneg If DCP is used along with external negotiation, when creating data channel the client should always specify the stream id=20 to use. Leaving selection to data channel stack (DCSK) will=20 result in conflicts as DCSK (browser) will assign stream ids=20 per DTLS role. 2. draft-ietf-rtcweb-data-protocol-03 Item (1) above conflicts with DCP's odd/even rule, for which the draft says "MUST" ("each side MUST use either even or=20 odd Streams"). This section 4 (and other sections) text has to be updated to "SHOULD" or "MAY". If we all agree to these updates then I am ok to make=20 internal or external negotiation granularity per data channel. Best Regards Raju >=20 > So, when a channel that was in the SDP previously then disappears from > the SDP it is necessary to close the corresponding channel. But channels > that were opened via DCEP should not be closed. >=20 > That also means that one should never mention a DCEP channel in SDP. >=20 > Thanks, > Paul >=20 > On 2/26/14 3:12 PM, Makaraju, Maridi Raju (Raju) wrote: > > Please find my comments inline. > > > > But, there is no text on rejecting a data channel in the SDP answer. > > > > The answer can of course reject the whole m- line, using port zero in > > the Answer m- line. But, how does the answerer reject an individual > > sub-protocol data channel? > > > > Only attributes for "accepted data channels" are included in the SDP > > answer, which indicates back to the offerer which ones are rejected > > (they just aren't there). This should be made clearer in the text. > > > > Section 5.1.1 says, regarding the SDP dcmap attribute, for accepted > > data channels: > > > > "This line MUST be replicated without changes in the SDP answer, if > > > > the answerer accepts the offered data channel." > > > > I guess one way to reject would be to simply not include the dcmap > > attribute in the Answer, and the Offerer then needs to figure out > > what was rejected based on the stream values not present in the > Answer. > > > > Yes. That is what was intended. > > > > /[Raju] In addition to the above mentiooed cases, if we all agree we > > need to add the following cases in the next draft:/ > > > > */1./*SDP offer has no a=3Ddcmap. This has two use cases: > > > > a.Initial SDP offer: no data channel streams (DCS) are open yet. > > > > b.Subsequent SDP offer: Remove all previously opened data > channels/streams. > > > > In either case, the SCTP association is kept open (and ICE procedures > > are performed) even when no data channels are in use. > > > > */2./*Creation of new DCS(s) using SDP offer (initial or subsequent) > > > > a.Offerer has to create the data channels locally first by doing > > createDataChannel or equivalent API into data channel stack before > > sending offer. > > > > */3./*SDP offer was rejected > > > > a.DCSs are kept per previous SDP offer/answer. This means DCSs that are > > to be deleted has to be deleted (i.e. calling createDataChannel or > > equivalent API) only after successful SDP answer. > > > > b.If any new DCSs are attempted to be created per new SDP offer, these > > have to be closed now. > > > > */4./*Per > > http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-peerconnection- > createdatachannel > > createDataChannel() API the 'external' negotiation field is per data > > channel. But this draft only allows external negotiation to be used fo= r > > all or no streams; it can't be selective. This restriction is also > > needed so that the SDP offer/answer odd/even stream id allocation won't > > conflict DCP's TLS role based odd/even mechanism. > > > > Best Regards! > > > > Raju > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Feb 27 13:51: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 4E8BD1A0676; Thu, 27 Feb 2014 13:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 Hzx9tDyqZyMZ; Thu, 27 Feb 2014 13:51:16 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id BFD9C1A0675; Thu, 27 Feb 2014 13:51:15 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-40-530fb35172e6 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 8E.D9.04853.153BF035; Thu, 27 Feb 2014 22:51:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Thu, 27 Feb 2014 22:51:12 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Paul Kyzivat" , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel Thread-Index: Ac8y9YTn0Ql62f4ZSwiP0pv/vZVV7v///hmAgABkRoCAAAQtAIABiUuA///PR8A= Date: Thu, 27 Feb 2014 21:51:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1C023A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> <530E4E34.4010707@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvjW7gZv5gg7MrpSymLn/MYrFiwwFW i4aNV1gt1v5rZ3dg8Wh9tpfV4+/7D0weS5b8ZApgjuKySUnNySxLLdK3S+DKaHzZxlrQZVBx 48hGxgbGuWpdjJwcEgImEscuf2GEsMUkLtxbz9bFyMUhJHCCUWLPmcVMEM4SRonJH54AVXFw sAlYSHT/0waJiwjsZpT4+vwCM0i3sECsxNFlV5lAakQE4iRenlMBCYsI+El8OrqFBcRmEVCV uP7qI1gJr4CvxL3jUhDj7zBJnD9ygh2khhNozIY1M8AOYgQ66PupNUwgNrOAuMSHg9eZIQ4V kFiy5zyULSrx8vE/VghbSWLF9kuMEPV6EjemTmGDsLUlli18DVbPKyAocXLmE5YJjKKzkIyd haRlFpKWWUhaFjCyrGKULE4tLs5NNzLQy03PLdFLLcpMLi7Oz9MrTt3ECIymg1t+G+1gPLnH /hCjNAeLkjjvddaaICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MlYLzvqp/OTCv9I/biuxC Jt1jR/20Z2T3Ja0/qeWxWvpGoITv7HNL70hXbdn4oIwl9J+uA0PCFfm8Hacmvmx6nhSyqkYx 13f6sVrRo9OfzbKIczBbeiG8p8DFettKqyaxVT53ZsseZHRe05iRGMl+eLpjo9H8JxZ5rpVL c2cy9Uxr0bqx71afEktxRqKhFnNRcSIAmYhj6nQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WICeyrOjrmogyrWeqKgHPGKKVWs Subject: Re: [rtcweb] [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 27 Feb 2014 21:51:18 -0000 Hi, Isn't it enough to, in the data channel protocol spec, say that the odd/eve= n rule applies unless the stream id is explicitly negotiated using some oth= er mechanism? Or something like that... Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: mmusic [mailto:mmusic-bounces@ietf.org] Puolesta Makaraju,= Maridi Raju (Raju) L=E4hetetty: 27. helmikuuta 2014 21:55 Vastaanottaja: Paul Kyzivat; mmusic@ietf.org; rtcweb@ietf.org Aihe: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejecti= on of channel + rtcweb as it impacts DCP draft. Please see comments inline. > I would like some clarity about how this interacts with DCEP. >=20 > IMO these are not mutually exclusive. But they must be used with care. [Raju] I debated on this with myself before concluding in my earlier reply = that they are mutually exclusive. My mistake, instead of concluding I shoul= d have given options. To make this internal or external per data channel gr= anuality we need to add more restrictions/notes to these draft.=20 http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-03#section-4 say= s: "To avoid glare in opening Channels, each side MUST use either even or odd Streams when sending a DATA_CHANNEL_OPEN message. The method used to determine which side uses odd or even is based on the underlying DTLS connection role when used in WebRTC, with the side acting as the DTLS client using even stream identifiers." Where as draft-ejzak-mmusic-data-channel-sdpneg determines this based on SD= P offerer (even) and answerer (odd). What if the SDP answerer becomes TLS client? The stream #id assignments con= flict with SDP offer/answer. So, to avoid such conflict we need to add the following clarifications: 1. draft-ejzak-mmusic-data-channel-sdpneg If DCP is used along with external negotiation, when creating data channel the client should always specify the stream id=20 to use. Leaving selection to data channel stack (DCSK) will=20 result in conflicts as DCSK (browser) will assign stream ids=20 per DTLS role. 2. draft-ietf-rtcweb-data-protocol-03 Item (1) above conflicts with DCP's odd/even rule, for which the draft says "MUST" ("each side MUST use either even or=20 odd Streams"). This section 4 (and other sections) text has to be updated to "SHOULD" or "MAY". If we all agree to these updates then I am ok to make internal or external = negotiation granularity per data channel. Best Regards Raju >=20 > So, when a channel that was in the SDP previously then disappears from=20 > the SDP it is necessary to close the corresponding channel. But=20 > channels that were opened via DCEP should not be closed. >=20 > That also means that one should never mention a DCEP channel in SDP. >=20 > Thanks, > Paul >=20 > On 2/26/14 3:12 PM, Makaraju, Maridi Raju (Raju) wrote: > > Please find my comments inline. > > > > But, there is no text on rejecting a data channel in the SDP answer. > > > > The answer can of course reject the whole m- line, using port zero=20 > > in the Answer m- line. But, how does the answerer reject an=20 > > individual sub-protocol data channel? > > > > Only attributes for "accepted data channels" are included in the SDP=20 > > answer, which indicates back to the offerer which ones are rejected=20 > > (they just aren't there). This should be made clearer in the text. > > > > Section 5.1.1 says, regarding the SDP dcmap attribute, for accepted > > data channels: > > > > "This line MUST be replicated without changes in the SDP answer,=20 > > if > > > > the answerer accepts the offered data channel." > > > > I guess one way to reject would be to simply not include the dcmap > > attribute in the Answer, and the Offerer then needs to figure out > > what was rejected based on the stream values not present in the > Answer. > > > > Yes. That is what was intended. > > > > /[Raju] In addition to the above mentiooed cases, if we all agree we=20 > > need to add the following cases in the next draft:/ > > > > */1./*SDP offer has no a=3Ddcmap. This has two use cases: > > > > a.Initial SDP offer: no data channel streams (DCS) are open yet. > > > > b.Subsequent SDP offer: Remove all previously opened data > channels/streams. > > > > In either case, the SCTP association is kept open (and ICE=20 > > procedures are performed) even when no data channels are in use. > > > > */2./*Creation of new DCS(s) using SDP offer (initial or subsequent) > > > > a.Offerer has to create the data channels locally first by doing=20 > > createDataChannel or equivalent API into data channel stack before=20 > > sending offer. > > > > */3./*SDP offer was rejected > > > > a.DCSs are kept per previous SDP offer/answer. This means DCSs that=20 > > are to be deleted has to be deleted (i.e. calling createDataChannel=20 > > or equivalent API) only after successful SDP answer. > > > > b.If any new DCSs are attempted to be created per new SDP offer,=20 > > these have to be closed now. > > > > */4./*Per > > http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-peerconnection- > createdatachannel > > createDataChannel() API the 'external' negotiation field is per data=20 > > channel. But this draft only allows external negotiation to be used=20 > > for all or no streams; it can't be selective. This restriction is=20 > > also needed so that the SDP offer/answer odd/even stream id=20 > > allocation won't conflict DCP's TLS role based odd/even mechanism. > > > > Best Regards! > > > > Raju > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Feb 27 14:59: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 4C73E1A02A6; Thu, 27 Feb 2014 14:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 WCDKXSH_WHe9; Thu, 27 Feb 2014 14:59:09 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CF22B1A015E; Thu, 27 Feb 2014 14:59:08 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1RMx4S9027874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Feb 2014 16:59:04 -0600 (CST) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s1RMx3f5029253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 17:59:03 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 27 Feb 2014 17:59:03 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel Thread-Index: AQHPMv00Ot+PDux+H0inH2oRraNWlJrH7JxQgABjlQCAAR/dwIAAideA//+55EA= Date: Thu, 27 Feb 2014 22:59:02 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> <530E4E34.4010707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1C023A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1C023A@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/M2rWQQXjuaftK4609_hJgfy3xA0 Subject: Re: [rtcweb] [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 27 Feb 2014 22:59:10 -0000 Hi Christer, > Hi, >=20 > Isn't it enough to, in the data channel protocol spec, say that the odd/e= ven > rule applies unless the stream id is explicitly negotiated using some oth= er > mechanism? >=20 [Raju] Yes, that is sufficient from DCP draft. draft-ejzak-mmusic-data-chan= nel-sdpneg should still need to say that "when both external and DCP are us= ed, even for DCP created streams the stream ids have to be specified and ma= naged by the application (else DCP stack will default to odd/even rule per = DTLS role which may conflict with SDP offer/answer rule)". Thanks for agreeing to add this to the draft! Raju From nobody Fri Feb 28 07:57: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 233621A085D for ; Fri, 28 Feb 2014 07:57:13 -0800 (PST) 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 IUHRaU2FSPjd for ; Fri, 28 Feb 2014 07:57:12 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id EEA131A0859 for ; Fri, 28 Feb 2014 07:57:11 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta13.westchester.pa.mail.comcast.net with comcast id XpJw1n0021YDfWL5DrxA4y; Fri, 28 Feb 2014 15:57:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([130.129.152.238]) by omta20.westchester.pa.mail.comcast.net with comcast id Xruu1n00H58sGga3gruwrg; Fri, 28 Feb 2014 15:55:08 +0000 Message-ID: <5310B14E.4000809@alum.mit.edu> Date: Fri, 28 Feb 2014 10:54:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , Christer Holmberg , "mmusic@ietf.org" , "rtcweb@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> <530E4E34.4010707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1C023A@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393603030; bh=f9fp8KuOfJ9zm18eCbvBXn0kpxqdlHNcscQWACXwnYQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Wty/t3CKlGV6bmgUveOI19/eVax5fLR92zlZKhnw5o4eOnYB51pIN1bWF0FksP8mO QkIqLDP7ZIZIWe7RtQ/eYYjX5zxNd+092y6wttmlgTxv7wf9vRKMEcro1Ge7vjM/oN YLvCTO2AGtU3dx7nIB/ajKX6wg0rm5iWyIBEAOT8S0bwD4SZJww1mVHWK0MY6xE5ip Fz/LHBB1EDMryF7IYjo5jngXBbjc3BJZwsDMoAjtWQNYZ7XZsbmtZiXRwRf+IAKqMr myPixABBWTdHHtMbCJMutU1x1erkZbUwfLlLwU6iqiG2r0SeEK2lQuh3SQyqYpzoD7 Fn0u4btruV8iw== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/n13U3mXsFmOm3W1h2rb-McMytDE Subject: Re: [rtcweb] [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 28 Feb 2014 15:57:13 -0000 Raju, On 2/27/14 5:59 PM, Makaraju, Maridi Raju (Raju) wrote: > Hi Christer, > >> Hi, >> >> Isn't it enough to, in the data channel protocol spec, say that the odd/even >> rule applies unless the stream id is explicitly negotiated using some other >> mechanism? >> > [Raju] Yes, that is sufficient from DCP draft. draft-ejzak-mmusic-data-channel-sdpneg should still need to say that "when both external and DCP are used, even for DCP created streams the stream ids have to be specified and managed by the application (else DCP stack will default to odd/even rule per DTLS role which may conflict with SDP offer/answer rule)". Can we assume there must be a mechanism for using DCEP and still controlling which channels are used? It might help if the O/A negotiation also followed the even/odd rule. But there are difficulties in knowing who is even and who is odd for the first O/A. If the offerer always creates the channel before sending the offer, then that will prevent the two mechanisms from stepping on one another's stream ids. Thanks, Paul > Thanks for agreeing to add this to the draft! > > Raju > > From nobody Fri Feb 28 08:46: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 46D771A00D1; Fri, 28 Feb 2014 08:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-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 shksOz-QIkEM; Fri, 28 Feb 2014 08:46:47 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 33F111A00EF; Fri, 28 Feb 2014 08:46:47 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1SGkesF028681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Feb 2014 10:46:40 -0600 (CST) 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 s1SGkY0i016154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 11:46:40 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Fri, 28 Feb 2014 11:46:34 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , Christer Holmberg , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel Thread-Index: AQHPMv00Ot+PDux+H0inH2oRraNWlJrH7JxQgABjlQCAAR/dwIAAideA//+55ECAAXTlAP//tqXA Date: Fri, 28 Feb 2014 16:46:33 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> <530E4E34.4010707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1C023A@ESESSMB209.ericsson.se> <5310B14E.4000809@alum.mit.edu> In-Reply-To: <5310B14E.4000809@alum.mit.edu> 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/VZYQrhsbOuAOyCU_4Fb71AM5IpI Subject: Re: [rtcweb] [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 28 Feb 2014 16:46:50 -0000 Hi Paul, > >> Isn't it enough to, in the data channel protocol spec, say that the > odd/even > >> rule applies unless the stream id is explicitly negotiated using some > other > >> mechanism? > >> > > [Raju] Yes, that is sufficient from DCP draft. draft-ejzak-mmusic-data- > channel-sdpneg should still need to say that "when both external and DCP = are > used, even for DCP created streams the stream ids have to be specified an= d > managed by the application (else DCP stack will default to odd/even rule = per > DTLS role which may conflict with SDP offer/answer rule)". >=20 > Can we assume there must be a mechanism for using DCEP and still > controlling which channels are used? [Raju] Yes, we can assume that and it is already supported by : http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-6.5 and http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCDataChannel-id I believe it is safe to assume non-browser implementations of=20 data channel stack gives an option for application to select=20 stream ids independent of DCEP or external negotiation. >=20 > It might help if the O/A negotiation also followed the even/odd rule. [Raju] May be I am missing something here. Richard's draft already has a specific even/odd rule for O/A. But the issue is TLS based rule may conflict with the O/A rule as TLS roles may change depending on a=3Dsetup. > But there are difficulties in knowing who is even and who is odd for the > first O/A. [Raju] Not related to first or subsequent O/A, but rather a conflict=20 between TLS roles vs. O/A. >=20 > If the offerer always creates the channel before sending the offer, then > that will prevent the two mechanisms from stepping on one another's > stream ids. [Raju]=20 In some cases, initial offer may not have a data channel stream created.=20 I don't know how this can prevent stepping on each other?! May be I am missing something here?! In most cases TLS role is=20 determined after O/A is completed, but offerer creates a data=20 channel before answer, then how does it know even/odd rule?=20 So, trying to use TLS role for external negotiation is problematic. Thanks Raju