From nobody Wed Feb 1 00:09:51 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E555129586; Wed, 1 Feb 2017 00:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 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_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujIYediKM8UT; Wed, 1 Feb 2017 00:09:46 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3CA129422; Wed, 1 Feb 2017 00:09:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E557ABE2D; Wed, 1 Feb 2017 08:09:43 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhFp1zO1UzQl; Wed, 1 Feb 2017 08:09:42 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DB1F7BE2C; Wed, 1 Feb 2017 08:09:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485936582; bh=P6MVgNQR3u2QbxdZq0P7Q1Po0GkdHcRp1R+uXAppQvw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Z/CkN/4Wq80qCO2jDRqcuRobUAOljGU0ldTGYG+xXoPhcLAGQjN8BTk59Aan2uEL5 N0AAHfJy4b7BVQrBh+Rr09mX4+Z+DOnJEh/K2+ymkyqnPNlJsnbatqYQVun91N6qOY zbKAdREVd4HjMjkLEFuMN8EtIynndrveSnZF69lQ= To: Eric Rescorla References: <148587892598.2448.6982128247176255180.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <7d1ccbf6-a81c-1fb7-e753-281770a0b73d@cs.tcd.ie> Date: Wed, 1 Feb 2017 08:09:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040405050203090408070908" Archived-At: Cc: Flemming Andreasen , mmusic-chairs@ietf.org, draft-ietf-mmusic-4572-update@ietf.org, The IESG , mmusic WG Subject: Re: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 08:09:48 -0000 This is a cryptographically signed message in MIME format. --------------ms040405050203090408070908 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/02/17 07:18, Eric Rescorla wrote: > On Tue, Jan 31, 2017 at 5:08 PM, Stephen Farrell > wrote: >=20 >> Stephen Farrell has entered the following ballot position for >> draft-ietf-mmusic-4572-update-12: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut thi= s >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ >> >> >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> >> I've two (or 4 depending how you count:-) things >> I'd like to check here. Should be pretty easy to >> handle. >> >> (1) section 5: I'm wondering if we have the right >> set of hash functions here. Deprecating md2 and md5 >> is great, but I have a bunch of questions about the >> others: >> >> (1.1) why not also say that sha-1 MUST NOT be used >> for new things (or similar)? >> >> (1.2) do you really need sha-224 and 384? I think >> nobody uses those at all. >> >=20 > It's certainly not correct that nobody uses SHA-384. >=20 > In fact, for TLS 1.3, you can't sign anything with P-384 without using > SHA-384. Fair enough. I guess some p384 will be seen in the web just because it'll be seen as longer/stronger with tls1.3. S >=20 > -Ekr >=20 >=20 >> (1.3) I'm a bit surprised you didn't add sha3 (and >> maybe remove sha-512 if that's not needed) Even if >> you don't encourage use of sha3, it might be good >> to include it in the abnf now in case it gets >> popular. >> >> (2) Wouldn't it be a good plan to say that TLS >> as-used MUST conform to BCP195? If not, why not? >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >=20 --------------ms040405050203090408070908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDEw ODA5NDFaMC8GCSqGSIb3DQEJBDEiBCD9lu2PaRg/Ou8C5BocUqFmywAtTDP3n1SOz+1ql77G ITBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAWlHk4N+B77RKFAn4dQQ0TG1FuclS/Tnvb458hKFm3i5bEvbCucrTd itbn/Kwc+3lEv3zq7YMbvxC5YNRVX9n8iW6G259UcODPr2JOFejCGCShokWDjaSBF0po7h+Q RC+5MompIa8aufwgpT1I7N2v3NzvNsY1C4jfVB2SdnZUdARBLmyhcCZL8yGXtwchgu5EJh2q OFeEORWhlBu+Vk8Nh63WiYqp8FEx5fmZUwraV1UtHQYpSwCGmZVEW8CLbv72zgo9Aj83etZS Vg9Lv1P9+ppRTJpFGP7Kt2xdf7csjZmgDLgnK9A6vhGR729zKQFBB1ySy9u2PtgIjKsr0KRl AAAAAAAA --------------ms040405050203090408070908-- From nobody Wed Feb 1 00:44:51 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64C612957C; Wed, 1 Feb 2017 00:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 wORpsC8yTwNU; Wed, 1 Feb 2017 00:44:43 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1C3129407; Wed, 1 Feb 2017 00:44:42 -0800 (PST) X-AuditID: c1b4fb2d-e76b398000007e3d-83-58919ff9bc4e Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 81.56.32317.9FF91985; Wed, 1 Feb 2017 09:44:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0319.002; Wed, 1 Feb 2017 09:43:53 +0100 From: Christer Holmberg To: Stephen Farrell , Eric Rescorla Thread-Topic: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS) Thread-Index: AQHSe9xPXcuaz7bZMUKOtO0DGNu5LqFTrleAgAAOQICAACuUgA== Date: Wed, 1 Feb 2017 08:43:53 +0000 Message-ID: References: <148587892598.2448.6982128247176255180.idtracker@ietfa.amsl.com> <7d1ccbf6-a81c-1fb7-e753-281770a0b73d@cs.tcd.ie> In-Reply-To: <7d1ccbf6-a81c-1fb7-e753-281770a0b73d@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.19] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3568790739_35113561" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNIsWRmVeSWpSXmKPExsUyM2K7qO7P+RMjDDZdlLQ4eHEZq8WK1+fY Ld5f0LWY8Wcis8X5neuZLKYuf8xiMX3vNXYHdo8pvzeyeqztvsrmsWTJTyaPyY/bmANYorhs UlJzMstSi/TtErgyXjw+yVjwxqdi4Y3TbA2M69y7GDk5JARMJE42fGTvYuTiEBJYxyhxcc5Z JghnEaPE0q8PWbsYOTjYBCwkuv9pgzSICPhK/Pi7nw2khlngHaNEY0sXC0hCWCBVYve1TkaI ojSJI3uOskDYThK92zaDxVkEVCSeNd5lBJnJK2AtMWFuFMSuY4wSv1ZvYAKp4RSwlWj8PY8V xGYUEJP4fmoNWJxZQFzi1pP5TBBXi0g8vHiaDcIWlXj5+B9YvaiAnsTy52uYIeKKEu1PGxgh eisl5i2eDdbLKyAocXLmE5YJjKKzkIydhaRsFpIyiLiexN79X9ghbHmJzWveMkPY1hIzfh1k g7AVJaZ0P4SqMZV4ffQj4wJGjlWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgdF8cMtv3R2M q187HmIU4GBU4uHdcG9ChBBrYllxZe4hRhWgOY82rL7AKMWSl5+XqiTCu3/uxAgh3pTEyqrU ovz4otKc1OJDjNIcLErivGYr74cLCaQnlqRmp6YWpBbBZJk4OKUaGIWeChUe/X6M9dRBuUei HNnZ/Sf7uT9VpD85+z1SfdnCn0s3LmlS5b3Gs9/cY/HPS+IhJddf1Vx/0LsmxDeo68F5uVVe 9h6bdB96b1r70tKjV9Wvzm5rJc+jP5Mm+Gc0rPOOLHbL2/LS+PD9vgm5mpc/HpsdneXfskRD dt0CjwPpWrOTvJk3eCixFGckGmoxFxUnAgAf3uZU7gIAAA== Archived-At: Cc: Flemming Andreasen , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-4572-update@ietf.org" , The IESG , mmusic WG Subject: Re: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 08:44:46 -0000 --B_3568790739_35113561 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Stephen, Are you happy with the responses you have received? Regards, Christer On 01/02/17 10:09, "Stephen Farrell" wrote: > > >On 01/02/17 07:18, Eric Rescorla wrote: >> On Tue, Jan 31, 2017 at 5:08 PM, Stephen Farrell >> >> wrote: >> >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-mmusic-4572-update-12: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>>https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> I've two (or 4 depending how you count:-) things >>> I'd like to check here. Should be pretty easy to >>> handle. >>> >>> (1) section 5: I'm wondering if we have the right >>> set of hash functions here. Deprecating md2 and md5 >>> is great, but I have a bunch of questions about the >>> others: >>> >>> (1.1) why not also say that sha-1 MUST NOT be used >>> for new things (or similar)? >>> >>> (1.2) do you really need sha-224 and 384? I think >>> nobody uses those at all. >>> >> >> It's certainly not correct that nobody uses SHA-384. >> >> In fact, for TLS 1.3, you can't sign anything with P-384 without using >> SHA-384. > >Fair enough. I guess some p384 will be seen in the web just >because it'll be seen as longer/stronger with tls1.3. > >S > >> >> -Ekr >> >> >>> (1.3) I'm a bit surprised you didn't add sha3 (and >>> maybe remove sha-512 if that's not needed) Even if >>> you don't encourage use of sha3, it might be good >>> to include it in the abnf now in case it gets >>> popular. >>> >>> (2) Wouldn't it be a good plan to say that TLS >>> as-used MUST conform to BCP195? If not, why not? >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> > --B_3568790739_35113561 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUEwYJKoZIhvcNAQcCoIIUBDCCFAACAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghHzMIIF+TCCA+GgAwIBAgIQMQ1yPcGTNYDzhYWhrkFQyDANBgkqhkiG9w0BAQUFADA6 MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MjAeFw0xNDExMDQxMjI4MTlaFw0xNzExMDQxMjI4MThaMG8xETAPBgNVBAoMCEVyaWNz c29uMRowGAYDVQQDDBFDaHJpc3RlciBIb2xtYmVyZzEtMCsGCSqGSIb3DQEJARYeY2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tMQ8wDQYDVQQFEwZMTUZDSEgwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCMb7fHWIV9CIFYYov86NR/6ibdVV0I+ZqVLE21zQB7otFv 6DTKlVXE7iiC4HCvMhlGkg3/qFmAhAti5Z1Z7+5eEMEIP5JJEZ7fMm6BME33Bkdgg4EfJrq4 FUG28Hw2//0qx3jZWvK2W751AmEuUJ5nkZ6F00GnzJmOhbveadC8E5keqwow9ria0/WazHiK 3wxzjbanoQaZIA+oCKj5YyCv8cCTaSk4pEAbXwxthJ97BaZPahsnb4EZEP08gxR5IE9NRi47 Eqh6LtBjiWpaB42EmCEBxc2uIQ87tlJ0e2SvCo74rqxndXtUeaWauMjjt4DnhJdiXZY244D5 J1gWssRFAgMBAAGjggHEMIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEFBQcBAQR2 MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUH MAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1 YWxjYXYyLmNlcjApBgNVHREEIjAggR5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20w VQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBv c2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQG CCsGAQUFBwMCMB0GA1UdDgQWBBRUo03/DrRAW2xpMmhN2uGkvDgx6jAfBgNVHSMEGDAWgBSx DcrURrevhgLDL28Gyg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIB ALbwqG5inhl/xPxsuQWcH7GOUZIPAw0JlKltVQ/TlsF7ig0J1iyzao6GsXItJ9H3WZPrCy5E QchJm7qcn2kKX8OGb+Yr53FisLR2gx+qkrQMDOdix9Was0cvIjDWjAQnEZbxz/a+dzdAP0Tr wNvD8282bIy0fCt/3uoBfzMnvQG+4wG018bDunc+NCj1FkSKkSRb9fP2Z2li65pfJcxtGIfb 5zsXJZG4Gtbe0/hxlj3NccjB/zVPO7PQ+lnWmxtOiJQ2loA+62vQreUQr328XK4IHFnoU+zX iVfUN2urvvirQH7Ha70TBMa20J8Nn2aEvY6QYMEQJhAiVmNTiv4EGGv5heX5vb8yaj7pr4YI vb6D0r+pwpvfEE8YhAEWJgCZP7k5zQwhrpuSF/s+wEruXo59sq9bOCefghktc5fwDu8ved98 cifRPUnuT/c5slJJ8LjFn8d+LnGklUdFA9kLjIJVVx+TM4D/OTaRG+mPFbY2pTyR0V84PG7H LekupNsFzcme7IBkQ+1zkb9hjz6pyiodf6rh7ph+8XHWNgzbC5PdGCANg8fVWrxqqOoEzvcU cPMy6XXJs0JWhWas8mJdHq2kGDDEpA7BbBatmtEqziXRnYGJeQK3eMDXXtmOeBSA4y7YZ47y +CxvbknSQ5dyghwkEq+a7ORPGVjsjtWJYJ6dMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw 9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMM FlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9 ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF 6EGtodlpusaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcN BEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpI Wt3QPtMYm2R2V1Um0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQ MaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7i rYUYFpq4TyocQ7qpHdYASC+NV8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3Y Nd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nO bPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJ qTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzAB hiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6 Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYx LmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDow OAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5j b20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyv rHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ 37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbP d+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2 d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss 5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1 vLCER9ePEsgLdCG27mUk9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH 3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6S QSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn 96Y63AIZdDq1kIHIw0vF4PBTVMZtMIIFODCCAyCgAwIBAgIRAJW+FqD3LkbxezmCcvqLzZYw DQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwHhcNMDcxMDE4MTIwMDUwWhcNMzIxMDE4MTIwMDUwWjA3MRQw EgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCC AiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9T gHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65ItqwA3GV17CpNX8GH9SBlK4GoRz6J I5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75Ljo1kB1c4VWk0Nj0TSO9P4tNm HqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJjmhnXb88lxhTuylixcpe csHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c3TxHoLs1iuKYaIu+ 5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+JWov3F0fUTPHS iXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0hADnJoWji UIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4pgd7 gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpo eDVNAgMBAAGjPzA9MA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBTw j1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0BAQUFAAOCAgEAvuRcYk4k9AwI//DTDGjk k0kiP0Qnb7tt3oNmzqjMDfz1mgbldxSR651Be5kqhOX//CHBXfDkH1e3damhXwIm/9fH907e T/j3HEbAek9ALCI18Bmx0GtnLLCo4MBANzX2hFxc469CeP6nyQ1Q6g2EdvZR74NTxnr/DlZJ Lo961gzmJ1TjTQpgcmLNkQfWpb/ImWvtxBnmq0wROMVvMeJuScg/doAmAyYp4Db29iBT4xdw NBedY2gea+zDTYa4EzAvXUYNR0PVG6pZDrlcjQZIrXSHX8f8MVRBE+LHIQ6e4B4N4cB7Q4WQ xYpYxmUKeFfyxiMPAdkgS94P+5KFdSpcc41teyWRyu5FrgZLAMzTsVlQ2jqIOylDRl6XK1TO U2+NSueW+r9xDkKLfP0ooNBIytrEgUy7onOTJsjrDNYmiLbAJM+7vVvrdX3pCI6GMyx5dwlp pYn8s3CQh3aP0yK7Qs69cwsgJirQmz1wHiRszYd2qReWt88NkvuOGKmYSdGe/mBEciG5Ge3C 9THxOUiIkCR1VBatzvT4aRRkOfujuLpwQMcnHL/EVlP6Y2XQ8xwOFvVrhlhNGNTkDY6lnVuR 3HYkUD/GKvvZt5y11ubQ2egZixVxSK236thZiNSQvxaz2emsWWFUyBy6ysHK4bkgTI86k4ml oMy/0/Z1pHWWbVYxggHkMIIB4AIBATBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhAxDXI9wZM1gPOFhaGuQVDIMA0GCWCG SAFlAwQCAQUAoGkwLwYJKoZIhvcNAQkEMSIEIKi15X9OPuUDRNc1IdTCPBraeuT9FgsH0WtE bjE6KgZlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDIw MTA4NDUzOVowDQYJKoZIhvcNAQEBBQAEggEAPHLNhlNU8wIJsM+sWzbkiVP+taF9Y0pOnDN5 AFt9SbFqDqaVwZJy9aEQtWC4YYIPBo0qn7zUJskurRmti7SA+byXFtfmx10cm9mdoNoHem4x AswPOPpllnKE7YRP+CjMOk8KRxzSFxMXtLPV3VcJ4yh73eH0hHODfWxoGdJlM4+CgCBhZQZd we9aX2LbfAr9zgjFe9IZuwLmJBz60RvhcyiX+XVFwbPcRJbFRKqon/guy16rVZ0GNBEURji7 MXHPCUXnIKjEf4I7kgL+MWTIAhs1wIDRr7gO3oSYyLOJ2+KTo9KGcTLO2QKjhEbtt9EbOSsg bV8MfD059M8f+wscuA== --B_3568790739_35113561-- From nobody Wed Feb 1 01:23:41 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47EF129407; Wed, 1 Feb 2017 01:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 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_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODYqp1StsL1s; Wed, 1 Feb 2017 01:23:38 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 390E412941C; Wed, 1 Feb 2017 01:23:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 83F27BE2C; Wed, 1 Feb 2017 09:23:35 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xJkiGTQgKcu; Wed, 1 Feb 2017 09:23:35 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EFBFCBDF9; Wed, 1 Feb 2017 09:23:34 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485941015; bh=YSnxThdoi7lwpvXJvWeOYLyCoZ2TqxOWFkO71QRcCgc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=dfz/C9dsndTw2Yhx9kQf4p6liqKEWtvnngivQPJqyszwSakqDvdm8pGWPQXDh+g8a 8rQBPLsahR33wzUO0PJv3AK9X+ijzulVDrp+/+CVwngm/YxOptYDf8JmCP6UzpXqsY 6cNKxsG790sUTrhJAAv4thYHE+7EetS0qF2B/0JE= To: Christer Holmberg , Eric Rescorla References: <148587892598.2448.6982128247176255180.idtracker@ietfa.amsl.com> <7d1ccbf6-a81c-1fb7-e753-281770a0b73d@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 1 Feb 2017 09:23:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050705040303040406090506" Archived-At: Cc: Flemming Andreasen , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-4572-update@ietf.org" , The IESG , mmusic WG Subject: Re: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 09:23:40 -0000 This is a cryptographically signed message in MIME format. --------------ms050705040303040406090506 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/02/17 08:43, Christer Holmberg wrote: > Hi Stephen, >=20 > Are you happy with the responses you have received? I'm always happy:-) Will send a substantive (positive) response later, will be afk for a bit this morning S >=20 > Regards, >=20 > Christer >=20 >=20 > On 01/02/17 10:09, "Stephen Farrell" wrote:= >=20 >> >> >> On 01/02/17 07:18, Eric Rescorla wrote: >>> On Tue, Jan 31, 2017 at 5:08 PM, Stephen Farrell >>> >>> wrote: >>> >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-mmusic-4572-update-12: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to al= l >>>> email addresses included in the To and CC lines. (Feel free to cut t= his >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ >>>> >>>> >>>> >>>> --------------------------------------------------------------------= -- >>>> DISCUSS: >>>> --------------------------------------------------------------------= -- >>>> >>>> >>>> I've two (or 4 depending how you count:-) things >>>> I'd like to check here. Should be pretty easy to >>>> handle. >>>> >>>> (1) section 5: I'm wondering if we have the right >>>> set of hash functions here. Deprecating md2 and md5 >>>> is great, but I have a bunch of questions about the >>>> others: >>>> >>>> (1.1) why not also say that sha-1 MUST NOT be used >>>> for new things (or similar)? >>>> >>>> (1.2) do you really need sha-224 and 384? I think >>>> nobody uses those at all. >>>> >>> >>> It's certainly not correct that nobody uses SHA-384. >>> >>> In fact, for TLS 1.3, you can't sign anything with P-384 without usin= g >>> SHA-384. >> >> Fair enough. I guess some p384 will be seen in the web just >> because it'll be seen as longer/stronger with tls1.3. >> >> S >> >>> >>> -Ekr >>> >>> >>>> (1.3) I'm a bit surprised you didn't add sha3 (and >>>> maybe remove sha-512 if that's not needed) Even if >>>> you don't encourage use of sha3, it might be good >>>> to include it in the abnf now in case it gets >>>> popular. >>>> >>>> (2) Wouldn't it be a good plan to say that TLS >>>> as-used MUST conform to BCP195? If not, why not? >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> >> --------------ms050705040303040406090506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDEw OTIzMzVaMC8GCSqGSIb3DQEJBDEiBCBHaTdX5nqa+YCyNj+zk7Dh1KuGJd7mxhU9y7WWYYwC vTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBYvC0z0220qX2CqG16ctHlQp31IYKkfbZxtSl54Ke55Qwwuju+uXno 5XjweoJtbvM3eojxrjnoNdaUKfikAfqpBpWrb0rRZllUQxJe/uLzFRugyvSrj6L2BrOjDY7l 0o5qZ0GXw6ygnJ9PrY4urDbm0wbUHH5+zOga1Pb5uGz4DbTbk1niGF2ov2U+JGKAjr54Mbw9 F7vYZN/HwcVROTLovRcqax3ePyz0WBP96nsTHUrIN0+zDP3tD1iJL4BT1O5jnm8mq63N4hEV GMll3p93p1/G8YHt08YLoms0oFwIMOZWav06bfkmg6qJrsSAFwgCqj3tw0vo94dp7mYUFWVU AAAAAAAA --------------ms050705040303040406090506-- From nobody Wed Feb 1 01:25:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453A612941C; Wed, 1 Feb 2017 01:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 g0VtcVEEV9gU; Wed, 1 Feb 2017 01:25:39 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CADD129407; Wed, 1 Feb 2017 01:25:38 -0800 (PST) X-AuditID: c1b4fb3a-12eaf98000004068-b6-5891a9902af9 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id DB.45.16488.099A1985; Wed, 1 Feb 2017 10:25:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0319.002; Wed, 1 Feb 2017 10:25:04 +0100 From: Christer Holmberg To: Stephen Farrell , Eric Rescorla Thread-Topic: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS) Thread-Index: AQHSe9xPXcuaz7bZMUKOtO0DGNu5LqFTrleAgAAOQICAACuUgP//6RKAgAAicYA= Date: Wed, 1 Feb 2017 09:25:04 +0000 Message-ID: References: <148587892598.2448.6982128247176255180.idtracker@ietfa.amsl.com> <7d1ccbf6-a81c-1fb7-e753-281770a0b73d@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.19] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3568793211_35225323" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNIsWRmVeSWpSXmKPExsUyM2K7se6ElRMjDBbOULM4eHEZq8WK1+fY Ld5f0LWY8Wcis8X5neuZLKYuf8xiMX3vNXYHdo8pvzeyeqztvsrmsWTJTyaPyY/bmANYorhs UlJzMstSi/TtErgyljyZwlJwNqBix9Q+1gbG415djJwcEgImEhPX/WLrYuTiEBJYxyhx+vFF FghnEaPEgov9QA4HB5uAhUT3P22QBhEBX4kff/eDNTALvGOUaGzpYgFJCAukSuy+1skIUZQm cWTPURYI20/idN8RZpA5LAIqEqvX64OEeQWsJf4uvgu1azWTxNspy9hBEpwCthJXbq9kArEZ BcQkvp9aA2YzC4hL3HoynwniahGJhxdPs0HYohIvH/9jBbFFBfQklj9fwwwRV5Rof9rACNFb KbGk8wIjxGJBiZMzn7BMYBSdhWTsLCRls5CUQcT1JPbu/8IOYctLbF7zlhnCtpaY8esgG4St KDGl+yFUjanE66MfGRcwcqxiFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIzmg1t+W+1gPPjc 8RCjAAejEg/vhnsTIoRYE8uKK3MPMaoAzXm0YfUFRimWvPy8VCUR3rJFEyOEeFMSK6tSi/Lj i0pzUosPMUpzsCiJ85qtvB8uJJCeWJKanZpakFoEk2Xi4JRqYJQ7e1vo4R6mwgXsb8IWbPdy ljsbf1V+a+HHird1LocusFxa9lqy9OPHx/FX909xc8vgDr/EHvAqSunNf+3DHzz3NJUHBPqK TT70Wpzx88tTSx6wVFZ+4OYSm/WHzXavYdi+h43rqr4/3892/hPLTv3HFc1HeD6vmaOWb86y zOQwnzhvn1v0JA4lluKMREMt5qLiRACKyMaY7gIAAA== Archived-At: Cc: Flemming Andreasen , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-4572-update@ietf.org" , The IESG , mmusic WG Subject: Re: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 09:25:41 -0000 --B_3568793211_35225323 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Ok. Thanks! :) On 01/02/17 11:23, "Stephen Farrell" wrote: > > >On 01/02/17 08:43, Christer Holmberg wrote: >> Hi Stephen, >> >> Are you happy with the responses you have received? > >I'm always happy:-) Will send a substantive (positive) >response later, will be afk for a bit this morning > >S > >> >> Regards, >> >> Christer >> >> >> On 01/02/17 10:09, "Stephen Farrell" wrote: >> >>> >>> >>> On 01/02/17 07:18, Eric Rescorla wrote: >>>> On Tue, Jan 31, 2017 at 5:08 PM, Stephen Farrell >>>> >>>> wrote: >>>> >>>>> Stephen Farrell has entered the following ballot position for >>>>> draft-ietf-mmusic-4572-update-12: Discuss >>>>> >>>>> When responding, please keep the subject line intact and reply to all >>>>> email addresses included in the To and CC lines. (Feel free to cut >>>>>this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ >>>>> >>>>> >>>>> >>>>> >>>>>---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> >>>>>---------------------------------------------------------------------- >>>>> >>>>> >>>>> I've two (or 4 depending how you count:-) things >>>>> I'd like to check here. Should be pretty easy to >>>>> handle. >>>>> >>>>> (1) section 5: I'm wondering if we have the right >>>>> set of hash functions here. Deprecating md2 and md5 >>>>> is great, but I have a bunch of questions about the >>>>> others: >>>>> >>>>> (1.1) why not also say that sha-1 MUST NOT be used >>>>> for new things (or similar)? >>>>> >>>>> (1.2) do you really need sha-224 and 384? I think >>>>> nobody uses those at all. >>>>> >>>> >>>> It's certainly not correct that nobody uses SHA-384. >>>> >>>> In fact, for TLS 1.3, you can't sign anything with P-384 without using >>>> SHA-384. >>> >>> Fair enough. I guess some p384 will be seen in the web just >>> because it'll be seen as longer/stronger with tls1.3. >>> >>> S >>> >>>> >>>> -Ekr >>>> >>>> >>>>> (1.3) I'm a bit surprised you didn't add sha3 (and >>>>> maybe remove sha-512 if that's not needed) Even if >>>>> you don't encourage use of sha3, it might be good >>>>> to include it in the abnf now in case it gets >>>>> popular. >>>>> >>>>> (2) Wouldn't it be a good plan to say that TLS >>>>> as-used MUST conform to BCP195? If not, why not? >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>> >>> > --B_3568793211_35225323 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUEwYJKoZIhvcNAQcCoIIUBDCCFAACAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghHzMIIF+TCCA+GgAwIBAgIQMQ1yPcGTNYDzhYWhrkFQyDANBgkqhkiG9w0BAQUFADA6 MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MjAeFw0xNDExMDQxMjI4MTlaFw0xNzExMDQxMjI4MThaMG8xETAPBgNVBAoMCEVyaWNz c29uMRowGAYDVQQDDBFDaHJpc3RlciBIb2xtYmVyZzEtMCsGCSqGSIb3DQEJARYeY2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tMQ8wDQYDVQQFEwZMTUZDSEgwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCMb7fHWIV9CIFYYov86NR/6ibdVV0I+ZqVLE21zQB7otFv 6DTKlVXE7iiC4HCvMhlGkg3/qFmAhAti5Z1Z7+5eEMEIP5JJEZ7fMm6BME33Bkdgg4EfJrq4 FUG28Hw2//0qx3jZWvK2W751AmEuUJ5nkZ6F00GnzJmOhbveadC8E5keqwow9ria0/WazHiK 3wxzjbanoQaZIA+oCKj5YyCv8cCTaSk4pEAbXwxthJ97BaZPahsnb4EZEP08gxR5IE9NRi47 Eqh6LtBjiWpaB42EmCEBxc2uIQ87tlJ0e2SvCo74rqxndXtUeaWauMjjt4DnhJdiXZY244D5 J1gWssRFAgMBAAGjggHEMIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEFBQcBAQR2 MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUH MAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1 YWxjYXYyLmNlcjApBgNVHREEIjAggR5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20w VQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBv c2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQG CCsGAQUFBwMCMB0GA1UdDgQWBBRUo03/DrRAW2xpMmhN2uGkvDgx6jAfBgNVHSMEGDAWgBSx DcrURrevhgLDL28Gyg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIB ALbwqG5inhl/xPxsuQWcH7GOUZIPAw0JlKltVQ/TlsF7ig0J1iyzao6GsXItJ9H3WZPrCy5E QchJm7qcn2kKX8OGb+Yr53FisLR2gx+qkrQMDOdix9Was0cvIjDWjAQnEZbxz/a+dzdAP0Tr wNvD8282bIy0fCt/3uoBfzMnvQG+4wG018bDunc+NCj1FkSKkSRb9fP2Z2li65pfJcxtGIfb 5zsXJZG4Gtbe0/hxlj3NccjB/zVPO7PQ+lnWmxtOiJQ2loA+62vQreUQr328XK4IHFnoU+zX iVfUN2urvvirQH7Ha70TBMa20J8Nn2aEvY6QYMEQJhAiVmNTiv4EGGv5heX5vb8yaj7pr4YI vb6D0r+pwpvfEE8YhAEWJgCZP7k5zQwhrpuSF/s+wEruXo59sq9bOCefghktc5fwDu8ved98 cifRPUnuT/c5slJJ8LjFn8d+LnGklUdFA9kLjIJVVx+TM4D/OTaRG+mPFbY2pTyR0V84PG7H LekupNsFzcme7IBkQ+1zkb9hjz6pyiodf6rh7ph+8XHWNgzbC5PdGCANg8fVWrxqqOoEzvcU cPMy6XXJs0JWhWas8mJdHq2kGDDEpA7BbBatmtEqziXRnYGJeQK3eMDXXtmOeBSA4y7YZ47y +CxvbknSQ5dyghwkEq+a7ORPGVjsjtWJYJ6dMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw 9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMM FlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9 ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF 6EGtodlpusaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcN BEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpI Wt3QPtMYm2R2V1Um0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQ MaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7i rYUYFpq4TyocQ7qpHdYASC+NV8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3Y Nd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nO bPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJ qTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzAB hiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6 Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYx LmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDow OAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5j b20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyv rHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ 37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbP d+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2 d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss 5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1 vLCER9ePEsgLdCG27mUk9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH 3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6S QSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn 96Y63AIZdDq1kIHIw0vF4PBTVMZtMIIFODCCAyCgAwIBAgIRAJW+FqD3LkbxezmCcvqLzZYw DQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwHhcNMDcxMDE4MTIwMDUwWhcNMzIxMDE4MTIwMDUwWjA3MRQw EgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCC AiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9T gHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65ItqwA3GV17CpNX8GH9SBlK4GoRz6J I5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75Ljo1kB1c4VWk0Nj0TSO9P4tNm HqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJjmhnXb88lxhTuylixcpe csHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c3TxHoLs1iuKYaIu+ 5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+JWov3F0fUTPHS iXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0hADnJoWji UIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4pgd7 gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpo eDVNAgMBAAGjPzA9MA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBTw j1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0BAQUFAAOCAgEAvuRcYk4k9AwI//DTDGjk k0kiP0Qnb7tt3oNmzqjMDfz1mgbldxSR651Be5kqhOX//CHBXfDkH1e3damhXwIm/9fH907e T/j3HEbAek9ALCI18Bmx0GtnLLCo4MBANzX2hFxc469CeP6nyQ1Q6g2EdvZR74NTxnr/DlZJ Lo961gzmJ1TjTQpgcmLNkQfWpb/ImWvtxBnmq0wROMVvMeJuScg/doAmAyYp4Db29iBT4xdw NBedY2gea+zDTYa4EzAvXUYNR0PVG6pZDrlcjQZIrXSHX8f8MVRBE+LHIQ6e4B4N4cB7Q4WQ xYpYxmUKeFfyxiMPAdkgS94P+5KFdSpcc41teyWRyu5FrgZLAMzTsVlQ2jqIOylDRl6XK1TO U2+NSueW+r9xDkKLfP0ooNBIytrEgUy7onOTJsjrDNYmiLbAJM+7vVvrdX3pCI6GMyx5dwlp pYn8s3CQh3aP0yK7Qs69cwsgJirQmz1wHiRszYd2qReWt88NkvuOGKmYSdGe/mBEciG5Ge3C 9THxOUiIkCR1VBatzvT4aRRkOfujuLpwQMcnHL/EVlP6Y2XQ8xwOFvVrhlhNGNTkDY6lnVuR 3HYkUD/GKvvZt5y11ubQ2egZixVxSK236thZiNSQvxaz2emsWWFUyBy6ysHK4bkgTI86k4ml oMy/0/Z1pHWWbVYxggHkMIIB4AIBATBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhAxDXI9wZM1gPOFhaGuQVDIMA0GCWCG SAFlAwQCAQUAoGkwLwYJKoZIhvcNAQkEMSIEIEJpoGSGOrrO/3de4DCwQD6wqRNoRYax5wqm fM96PJ45MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDIw MTA5MjY1MVowDQYJKoZIhvcNAQEBBQAEggEAiNNfBKsVJ6HKv5XE2/Ogwpxn5A0thxOafZ1O SuN6wkTIkNu8KGu5muzGaDozEeucqGQpBbQ2iEkhRuRA187fUMdvL+r42HI3cE7FKmHsMEoc 9+Gv3WyoesHEp1acyHvw34pRaMQGXngD03xQWMLjfxEAkBSohVIvTklA/hvR3M9imxFnAotU NV9b8/RBWRP9wrahX+6XVX8cuRhZflJDn4zmFjh1XkqFtTDeBwttIZ0tHipyoaIkR5LgGHY/ /Kge01U5kOh++8C7fcXU6y2/t/HQHpbiebg46pc3I7VexoygZRN43w7HiXr7M/u2IyEcj0EX FajG5ZkGDkRkFEVo3Q== --B_3568793211_35225323-- From nobody Wed Feb 1 06:32:24 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405BC129D37; Wed, 1 Feb 2017 06:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 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_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuuCZWu7CWsq; Wed, 1 Feb 2017 06:32:16 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0E9A129468; Wed, 1 Feb 2017 06:32:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1CEC7BE39; Wed, 1 Feb 2017 14:32:14 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDi1ViLthjTE; Wed, 1 Feb 2017 14:32:13 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 80063BDF9; Wed, 1 Feb 2017 14:32:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485959533; bh=QXtIaKyUhp4VXWwEAEEKPFV4mrH08+IH/56M63ddYU8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=YHeOFeMwn63uyrpC6UMeqsg8t4BkCH3F4ytcgziEzkLiSfr8QG2xzhqXOdpHNsM83 HX5edwS8C2vezr+UNBmL9vXvvg9jwrYPNuc+htrdXuY1jOhNwbiwEhmWHRCJjOzQcP YcX42yznNNQMRtbHH2TBqsHI9lUoKOBb05t9IaPA= To: Jonathan Lennox References: <148587892598.2448.6982128247176255180.idtracker@ietfa.amsl.com> <3DCBB043-EF35-425A-A005-93488A726369@vidyo.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <36000381-1043-e5a8-b03d-000eef833cef@cs.tcd.ie> Date: Wed, 1 Feb 2017 14:32:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <3DCBB043-EF35-425A-A005-93488A726369@vidyo.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010002060608070705030000" Archived-At: Cc: Flemming Andreasen , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-4572-update@ietf.org" , The The IESG , mmusic Subject: Re: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 14:32:19 -0000 This is a cryptographically signed message in MIME format. --------------ms010002060608070705030000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Bottom line I guess is I'm still not sure that the right set of hashes are included but we've discussed it so I'll clear. I'm happy to continue to discuss it if you want, or you can continue to discuss amongst yourselves if that's better, or you can just forge on and be glad I'm out of your hair if that's right:-) Cheers, S. Collating various responses into one... On 31/01/17 17:23, Jonathan Lennox wrote: >=20 >> On Jan 31, 2017, at 11:08 AM, Stephen Farrell >> wrote: >>=20 >> ----------------------------------------------------------------------= >> >>=20 DISCUSS: >> ----------------------------------------------------------------------= >> >> >> >>=20 I've two (or 4 depending how you count:-) things >> I'd like to check here. Should be pretty easy to handle. >>=20 >> (1) section 5: I'm wondering if we have the right set of hash >> functions here. Deprecating md2 and md5 is great, but I have a >> bunch of questions about the others: >>=20 >> (1.1) why not also say that sha-1 MUST NOT be used for new things >> (or similar)? >=20 > We say (section 5.1) that SHA-256 MUST be used for one of the > fingerprints; implementations MAY send additional fingerprints as > well. >=20 > There=E2=80=99s concern that there may be existing implementations need= ing > SHA-1 (since 4572 made that the MTI algorithm). The need for interop > makes defining =E2=80=9Cnew things=E2=80=9D rather complicated. >=20 > Is that sufficient? I guess. But is there really that much use of fingerprints today that you need to preserve sha-1? (Honest question, I'm just ignorant:-) >=20 >=20 >> (1.2) do you really need sha-224 and 384? I think nobody uses those >> at all. On 01/02/17 07:18, Eric Rescorla wrote: > > It's certainly not correct that nobody uses SHA-384. > > In fact, for TLS 1.3, you can't sign anything with P-384 without using > SHA-384. Well, tls1.3 isn't used yet but even so, I'd say the set of folks using p384 will be tiny. Enough that this spec could say "these are just here in case they're needed, but we don't think you ought use 'em and you might not get great interop if you do" >>=20 >> (1.3) I'm a bit surprised you didn't add sha3 (and maybe remove >> sha-512 if that's not needed) Even if you don't encourage use of >> sha3, it might be good to include it in the abnf now in case it >> gets popular. >=20 > The policy is that the set of hash functions supported corresponds to > the hash functions defined for X.509 certificates. Unless I=E2=80=99m m= issing > something, there=E2=80=99s no definition of SHA-3 for X.509 yet, is the= re? > (If I=E2=80=99ve overlooked something, please let me know.) I'm not sure what'd be needed to use it? There are, I'm sure, OIDs, and once you have that you're all set. That is, I don't think one'd need an RFC to use sha-3 with x.509. >=20 > The list is an IANA registry, so once SHA-3 is defined for X.509, it > can also be added to the registry without needing an update to this > document. >=20 > For the same reason, this is why we included SHA-224 and SHA-384. If > no one=E2=80=99s using them, I=E2=80=99d think an update to RFC 4055 wo= uld be in > order? Maybe in theory. I'm not sure who'd be motivated to do that though. >=20 >=20 >> (2) Wouldn't it be a good plan to say that TLS as-used MUST conform >> to BCP195? If not, why not? >=20 > My inclination would be to say yes, but I=E2=80=99ll let people with mo= re of > the existing implementations comment further in case there=E2=80=99s so= me > issue. On 31/01/17 22:59, Martin Thomson wrote: > If we said MUST, I suspect that we'd end up making a whole lot of > implementations non-compliant. There's a lot of DTLS 1.0 out there. > That said, the same applies to SHA-1. > > I guess it depends on your stance regarding what is as opposed to what > should be. > > FWIW, we didn't ask this sort of question because the intent was to > clarify hash usage only, avoiding touching the rest of the document. > I'd be fine if you said "SHOULD" for BCP195 compliance. Would that work? >=20 >=20 >=20 --------------ms010002060608070705030000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDEx NDMyMTNaMC8GCSqGSIb3DQEJBDEiBCAP9Uow1i1gutSvDm+EibLtg57c8MOm+4AwBay/idbn KjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAL0xJyBu3sjdPoFhGr5Ysbl9A3Z5IC6+WsJDeJua+Y2Po9+vcZ5Ih/ 4jtSMzMYku7kY7jUe7RHrte3ooKDCNtw26HfIJDavgTiO0O1z9VBKaU+t8tUoBwj94coz2OP Q9tfd9brdKqdw8tFpzpqC1lub3DLmu6qfhe+uLz59eLCyHvUZtgh8d2PPrUR9jYGhFcm+Me/ vt5Cgr8D5AUbqwzRqZMAN/csbRLtXYCGjMO3KNLTevilcrcW6a5H/K3WNxuNzMUr5YxAr9yv JTom7AykI+7BfHwm2eHSGlecP2SJ6MCycdLo5mseZlrADgqecBxXQjjnp7Q7lx2GSQQ/85eg AAAAAAAA --------------ms010002060608070705030000-- From nobody Wed Feb 1 06:33:15 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F510129468; Wed, 1 Feb 2017 06:33:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148595959412.19146.5607036387011046763.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2017 06:33:14 -0800 Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-4572-update@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Stephen Farrell's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 14:33:14 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-mmusic-4572-update-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I had two (or 4 depending how you count:-) things I'd like to check here. They were pretty easy to handle. (We more or less resolved this by mail.) (1) section 5: I'm wondering if we have the right set of hash functions here. Deprecating md2 and md5 is great, but I have a bunch of questions about the others: (1.1) why not also say that sha-1 MUST NOT be used for new things (or similar)? (1.2) do you really need sha-224 and 384? I think nobody uses those at all. (1.3) I'm a bit surprised you didn't add sha3 (and maybe remove sha-512 if that's not needed) Even if you don't encourage use of sha3, it might be good to include it in the abnf now in case it gets popular. (2) Wouldn't it be a good plan to say that TLS as-used MUST conform to BCP195? If not, why not? From nobody Wed Feb 1 07:22:31 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45797129E56; Wed, 1 Feb 2017 07:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 xwccZIVqtHBP; Wed, 1 Feb 2017 07:22:23 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD47129E5A; Wed, 1 Feb 2017 07:22:21 -0800 (PST) X-AuditID: c1b4fb30-13a0498000007085-d7-5891fd2b9ee6 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id A7.36.28805.B2DF1985; Wed, 1 Feb 2017 16:22:19 +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.3.319.2; Wed, 1 Feb 2017 16:21:22 +0100 To: Jonathan Lennox References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> From: Magnus Westerlund Message-ID: Date: Wed, 1 Feb 2017 16:21:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM2K7k67234kRBpOfC1pMn/WOzWJ+xzo2 i/2LzzNbTF3+mMVi7b92dgdWjyVLfjJ5fLn8mc2j7dkd9gDmKC6blNSczLLUIn27BK6Myxsn sBT8nc1Y8ebyHMYGxodVXYycHBICJhJvfvazdzFycQgJrGOUODdxLhOEs4xRYtvnDawgVcIC RRIHXrYxg9giAhoSF599YAOxhYDiDdvbGUEamAWamSTu7J7CDpJgE7CQuPmjEayIV8Be4t2C H2A2i4CKxLWmZrAaUYEYiZd7VrFA1AhKnJz5BMzmFLCVOLLoF1ANB9BQe4kHW8tAwswC8hLN W2czQ+zVlmho6mCdwCgwC0n3LISOWUg6FjAyr2IULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQI DOCDW34b7GB8+dzxEKMAB6MSD++GexMihFgTy4orcw8xSnAwK4nwHvo9MUKINyWxsiq1KD++ qDQntfgQozQHi5I4r9nK++FCAumJJanZqakFqUUwWSYOTqkGxjVhj2+ueFzqHvNAMlM2c+5y +89Hev/cadgSFJQ0x5vr8wbb8Du+0i+DjPQv2EyKCrmx7Exk3+v5WzJlHDnyrVlDBN/dLlZq 1agodkiZxXaj5pl06IzaUC9GtQ+B7xVnlGzXutC3QXjH1lV127ILZcQUHrTHP9tYflnDzCKq 3vrVRr9pj2tslFiKMxINtZiLihMBlKWEdFwCAAA= Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 15:22:26 -0000 Hi Jonathan, Thanks for the feedback. See inline for my attempt to answer them. Den 2017-01-31 kl. 18:43, skrev Jonathan Lennox: > In general, this looks good. > > I have one question, however. What should happen if an RTP packet > (without a MID) is received for a stream that has an existing mapping > to an m= line, but whose PT is not valid for that m= line? > So, the text in JSEP-18 didn't specify this either. However, I do have an opinion on this. > Should it 1. Cause the stream’s mapping to be moved to another m= > line, if the received PT is in the payload type table for some other > m= line? or I would recommend against this due to that we will have to go into under which circumstances that one can accept this, and when not. Bo Burman and I had some discussion on this. We arrived at some relevant aspects of this. The first is that one have one to consider precedence rules between PTs, as well as a=ssrc and MID. In general we think mismatch between the information is to be considered an error. However, using PT and MID could cause strange error cases, where packets without MID ends up in on m= line with the PT and the ones with MID are dropped as inconsistent. I would claim that this stream is always in error. I would also note that Bundle specification currently forbids PT based switching, but for a different reasons. Section 10.1 says: o A given SSRC MUST NOT transmit RTP packets using payload types that originate from different bundled "m=" lines. NOTE: The last bullet above is to avoid sending multiple media types from the same SSRC. If transmission of multiple media types are done with time overlap, RTP and RTCP fail to function. Even if done in proper sequence this causes RTP Timestamp rate switching issues [RFC7160]. However, once an SSRC has left the RTP session (by sending an RTCP BYE packet), that SSRC can be reused by another source (possibly associated with a different bundled "m=" line) after a delay of 5 RTCP reporting intervals (the delay is to ensure the SSRC has timed out, in case the RTCP BYE packet was lost [RFC3550]). But, we do note that the limitation is not strictly necessary in regards to the motivation. The minimal limitation based on the motivation would be to require that a SSRC only uses PTs of the same media type and clock rate within a single bundle group. Using shared PTs, which the current limitation requires automatically meets that goal, and is easier to check for. We also noted that BUNDLE should clarify how MID relates to a=ssrc (RFC5576). My interpretation is that a=ssrc locks a RTP stream to a particular m= line, and can't be moved. So any MID value other than that matches the m= line that has the a=ssrc value would be an error case. For usages that intend to have a RTP stream to bounce between m= lines should not use a=ssrc, only MID. I think it would be good to clarify this in the BUNDLE specification. > 2. Be an error? This would be my preferred choice. > > In other words, should it be possible for PT-mapping to cause streams > to change their mappings? To conclude: No, as it would cause several additional complexities and possible branches in the algorithm. The use case for moving SSRCs between m= lines are supported when using MID, and the m= lines are correctly configured with shared PTs. Cheers Magnus > > (Should this decision depend on what caused the stream to be mapped > to its current m= line?) > >> On Jan 27, 2017, at 11:43 AM, Magnus Westerlund >> wrote: >> >> MMUSIC and RTCWEB, >> >> Here is now a more complete text proposal that also considers the >> RTCP. It also goes further than what Appendix B defines in one >> aspect, namely explicitly considering third party RTCP reporting >> and what to do with it. >> >> Feedback is much appreciated. I plan to put this into a PR towards >> JSEP APPENDIX B on monday. If only to get the JSEP authors >> attention ;-). However, the text is really intended for the next >> version of BUNDLE. >> >> >> X. Associating RTP/RTCP With Correct SDP Media Description >> >> As described in [RFC3550], RTP packets are associated with RTP >> streams [RFC7656]. Each RTP stream is identified by an SSRC >> value, and each RTP packet carries an SSRC value that is used to >> associate the packet with the correct RTP stream. RTCP packets >> also uses SSRCs to identify on which RTP streams any report or >> feedback relate to. Thus, an RTCP packet will commonly carry >> multiple SSRC values, and might therefore be providing feedback or >> report on multiple RTP streams. >> >> In order to be able to process received RTP/RTCP packets correctly >> it must be possible to associate an RTP stream with the correct >> "m=" line, as the "m=" line and SDP attributes associated with the >> "m=" line contain information needed to process the packets. >> >> As all RTP streams associated with a BUNDLE group are part of the >> same RTP session and using the same address:port combination for >> sending and receiving RTP/RTCP packets, the local address:port >> combination cannot be used to associate an RTP stream with the >> correct "m=" line. In addition, multiple RTP streams might be >> associated with the same "m=" line. >> >> Also, as described in Section 10.1.1, the same payload type value >> might be used by multiple RTP streams, in which case the payload >> type value cannot be used to associate an RTP stream with the >> correct "m=" line. However, there are cases where each "m=" line >> has unique payload type values, and then the payload type could >> serve as indicator to the relevant "m=" line the RTP stream is >> associated with. >> >> An offerer and answerer can inform each other which SSRC values >> they will use for an RTP stream by using the SDP 'ssrc' attribute >> [RFC5576]. However, an offerer will not know which SSRC values >> the answerer will use until the offerer has received the answer >> providing >> >> >> >> Name Expires July 31, 2017 >> [Page 2] >> >> Internet-Draft Abbreviated-Title January >> 2017 >> >> >> that information. Due to this, before the offerer has received >> the answer, the offerer will not be able to associate an RTP stream >> with the correct "m=" line using the SSRC value associated with the >> RTP stream. In addition, the offerer and answerer may start using >> new SSRC values mid-session, without informing each other using the >> SDP 'ssrc' attribute. >> >> In order for an offerer and answerer to always be able to >> associate an RTP stream with the correct "m=" line, the offerer and >> answerer using the BUNDLE extension MUST support the mechanism >> defined in Section 14, where the offerer and answerer includes the >> identification-tag (provided by the remote peer) associated with >> an "m=" line in the RTP Streams and in RTCP SDES packets part of a >> BUNDLE group. >> >> The mapping from an SSRC to an identification-tag is carried in >> RTCP SDES packets or in RTP header extensions (Section 14). Since >> a compound RTCP packet can contain multiple RTCP SDES packets, and >> each RTCP SDES packet can contain multiple chunks, an RTCP packet >> can contain several SSRC to identification-tag mappings. The >> offerer and answerer maintain tables mapping RTP streams identified >> by SSRC to "m=" lines identified by the identification-tag. These >> tables are updated each time new information that affects how >> packets should be processed and routed are received. >> >> To prepare for demultiplexing RTP streams to the correct "m=" >> line, the following steps MUST be followed for each BUNDLE group >> based on the SDP signalling information. >> >> Construct a table mapping MID to "m=" line for each "m=" line in >> this BUNDLE group. Note that an "m=" line may only have one MID. >> >> Construct a table mapping incoming RTP streams (SSRCs) to their >> "m=" line for each "m=" line in this BUNDLE group and for each RTP >> stream explicitly signalled for receiving in that "m=" line. >> >> Construct a table mapping payload types to "m=" line for each "m=" >> line in the BUNDLE group and for each payload type configured for >> receiving in that "m=" line. If any payload type is configured for >> receiving in more than one "m=" line in the BUNDLE group, do not it >> include it in the table. >> >> Note that for each of these tables, there can only be one mapping >> for any given key (MID, SSRC, or PT). In other words, the tables >> are not multimaps. >> >> As "m=" lines are added or removed from the BUNDLE groups, or >> their configurations are changed, the tables above MUST also be >> updated. >> >> >> >> Name Expires July 31, 2017 >> [Page 3] >> >> Internet-Draft Abbreviated-Title January >> 2017 >> >> >> Received RTP packets that are syntactically correct are processed >> by the RTP/RTCP protocol implementation for statistics etc. After >> this processing they need to be routed to the higher layer context >> associated with the "m=" line within the BUNDLE group. Somewhere >> in the process where an received RTP packet is processed to be >> delivered to the higher layer by RTP the matching step below MUST >> be performed: >> >> 1. Reception of an RTP packet for an RTP stream that has an >> existing mapping in the RTP stream to m= line table. Before >> proceeding in delivering the packet to the higher layer context >> according to the RTP stream to "m=" line mapping table the >> following checks MUST be performed: >> >> A. If the packet carries an RTP header extension with a SDES MID >> value that is not in the table mapping MID to "m=" line, then do >> not deliver the RTP packet to higher layers. >> >> B. If the packet carries an RTP header extension with a SDES MID >> value that is in the table mapping MID to "m=" line, and the value >> indicates a different "m=" line than the current RTP stream to "m=" >> line mapping table, then update the RTP stream to "m=" line >> mapping. >> >> 2. Reception of an RTP packet for an RTP stream that has no >> existing mapping to an m= line. In this case the following actions >> MUST be performed: >> >> A. If the packet carries an RTP header extension with a SDES MID >> value that is in the table mapping MID to "m=" line, then create an >> entry in the RTP stream to "m=" line mapping table for this RTP >> stream (SSRC). Then deliver the RTP packet to the "m=" line >> context of the created mapping and stop. >> >> B. If the packet carries a Payload Type that is in the payload >> type table, then create an entry in the RTP stream to "m=" line >> mapping table for this RTP stream (SSRC). Then deliver the RTP >> packet to the "m=" line context of the created mapping and stop. >> >> C. Otherwise do not deliver the RTP packet to higher layers. Note, >> this includes unknown MID values. >> >> For each RTCP packet received (including each RTCP packet that is >> part of a compound RTCP packet), the RTCP packet needs to be >> processed by the RTP/RTCP implementation and relevant information >> and data from the RTCP packets needs to be routed to the >> appropriate handler for the related RTP streams. The appropriate >> handler is determined by using the RTP stream to "m=" line mapping >> table. >> >> >> >> Name Expires July 31, 2017 >> [Page 4] >> >> Internet-Draft Abbreviated-Title January >> 2017 >> >> >> On reception of any compound RTCP packet prior to dispatching the >> received information and data, if there is an RTCP SDES packet >> included that SHOULD be processed first. If that SDES packet >> contains SDES MID entries, this can results in updates and >> additions to the RTP stream to "m=" line mapping table. Thus each >> of the SDES MID items are processed and the current table entries >> are checked if the corresponding MID value matches the current RTP >> stream to "m=" line mapping, else the entry is updated. If there >> is no RTP stream to "m=" line table mapping entry for the received >> SDES item's SSRC, such an entry is created. Note, that in the >> process of updating the table entries, update flap suppression as >> discussed in Section 4.2.6 of [RFC7941] should be considered. >> >> The various different RTCP packets as well as their various sub >> parts, such as the various RTCP Feedback message types, relates to >> the RTP streams in a couple of different ways. The currently >> known patterns are the following: >> >> Reports on outgoing RTP streams: For all RTP streams that this >> endpoint is the source of, it can expect to receive report blocks >> of several types identified as relating to an outgoing stream. The >> basic pattern for these blocks are that the RTCP packet header >> identifies the source of the reports, as identified by an SSRC, and >> containing one or more report blocks, where each report block >> identifies the RTP stream, using the SSRC, the report relates to. >> For this pattern the relevant report information is provided to the >> higher layer associated with the "m=" line the RTP Stream to "m=" >> line table identifies. The source SSRC as identifier of the >> endpoint that the report originates are relevant for interpreting >> the information, but not necessarily for routing. Example of this >> is pattern are: >> >> Sender Report (SR) and Receiver Report (RR) The basic receiver >> report blocks from RFC3550 start with the SSRC of the RTP stream >> they report on. >> >> Extended Reports (XR): RFC3611 is a framework that enables a large >> number of different reports. However, a large number of these >> report formats are reporting on specific RTP streams and thus each >> individual report of these types contains a SSRC field to identify >> the RTP stream. >> >> RTCP Feedback Messages for outgoing RTP streams: The RFC 4585 >> RTCP feedback messages allow for a number of different type of >> feedback messages. However, the RTCP feedback message header >> contains the SSRC identifying the source of the feedback messages >> as well as the actual type of the feedback. Some of the feedback >> messages also uses the target SSRC field in the header to identify >> which >> >> >> >> Name Expires July 31, 2017 >> [Page 5] >> >> Internet-Draft Abbreviated-Title January >> 2017 >> >> >> RTP stream the feedback is related to. For these types all the FCI >> entries, if multiple ones are forwarded to the identified handler. >> Examples of this pattern are: >> >> Picture Loss Indication (PLI): RFC 4585 (PT=PSFB, FMT=1). >> >> Slice Loss Indication (SLI): RFC 4585 (PT=PSFB, FMT=2). >> >> Reference Picture Selection Indication (RPSI): RFC 4585 (PT=PSFB, >> FMT=3). >> >> Generic NACK: [RFC4585] (PT=RTPFB and FMT=1). >> >> Other feedback messages includes the target SSRC in the Feedback >> Control Information (FCI). Here each FCI needs to be processed and >> the SSRC field identified. And the individual FCI combined with >> the RTCP packet header context needs to be forwarded to the >> identified handler. Example of this pattern are: >> >> Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). >> >> Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, >> FMT=5). >> >> Temporal-Spatial Trade-off Notification (TSTN): This [RFC5104] >> defined message (PT=PSFB, FMT=5) is actually a notifciation in >> response to a TSTR this endpoint sent using the SSRC the FCI >> identifies as source. >> >> H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, >> FMT=7). >> >> Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, >> FMT=TBD). >> >> Descriptive or Notifications for an incoming RTP stream: There >> exist some RTCP packet types that provides additional information >> or notifies about events related to the RTP stream identified. In >> these cases the RTP stream is identified using the SSRC field >> value, and the information is provided to the higher layer >> associated with the "m=" line for the incoming RTP stream as >> identified by the current RTP stream to "m=" line table. For this >> type of pattern it is common that the RTCP packets and information >> is repeated, either periodically (e.g. SDES items), or for a >> duration (e.g. BYE), thus suppression of repetitions can be >> considered. Examples of these are: >> >> >> >> >> >> Name Expires July 31, 2017 >> [Page 6] >> >> Internet-Draft Abbreviated-Title January >> 2017 >> >> >> Source Description (SDES) RTCP Packet: The base RTP/RTCP protocol >> [RFC3550] defines SDES RTCP packets as a way of providing per >> source (SSRC) specific information about the source. An SDES >> packet contains zero or more chunks, where a chunk contains the >> SSRC for the source being described by the one or more items >> included in the chunk. Forward the SDES items in each chunk to the >> RTP stream's handler. >> >> Goodbye (BYE) RTCP Packet: This RTP/RTCP protocol [RFC3550] >> mechanism indicates that a particular RTP stream is leaving the RTP >> session. Thus, a most relevant event to inform the handler for >> this RTP steam of. >> >> Third Party Targeted Reports or Feedback: There exist some >> multiparty RTP Topologies that results in that an endpoint receives >> third party reports (SR [RFC3550], RR [RFC3550] or XR [RFC3611]) as >> well as Feedback Messages [RFC4585] that relates to or targets an >> SSRC that originates from another endpoint, and where the source of >> the RTCP packet is also another endpoint. This type of packets >> should be forwarded to the higher layer function dealing with the >> third party reporting. And if none exist then they can be >> suppressed. As the third party handler can be focused on >> determining the conditions for the source of the reports and >> feedback, or focused on how the RTP stream source progresses, or >> both recommendations can't be made. >> >> APP Packets: The RTCP APP Packets [RFC3550] are a mechanism that >> enables experimentation. The APP packet only specifies the source >> of the packet. Thus this information can be related to any of the >> "m=" lines, thus deliver a copy of the packet to each "m=" line or >> an APP specific handler. >> >> -- 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 >> ---------------------------------------------------------------------- >> >> >> _______________________________________________ >> mmusic mailing list mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > -- 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 1 10:23:55 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61043128AC9; Wed, 1 Feb 2017 10:23:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2017 10:23:54 -0800 Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-4572-update@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 18:23:54 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-mmusic-4572-update-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 5.1 says: "An endpoint MAY, in addition to its more preferred hash function, also verify that each certificate used matches fingerprints calculated using other hash functions. Unless there is a matching fingerprint for each tested hash function, the endpoint MUST NOT establish the TLS connection." This seems a little weird to me. It's up to the endpoint to decide whether to check for errors, and then if it does find an error it can't setup the connection, whereas if it just hadn't checked it would be able to setup the connection. I think it would help to explain why an endpoint would be motivated to check multiple fingerprints. From nobody Wed Feb 1 11:43:58 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0560129E92; Wed, 1 Feb 2017 11:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 II9_teIoQtVJ; Wed, 1 Feb 2017 11:43:53 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E58129E8C; Wed, 1 Feb 2017 11:43:52 -0800 (PST) X-AuditID: c1b4fb3a-12eaf98000004068-9c-58923a766afd Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by (Symantec Mail Security) with SMTP id 63.C9.16488.67A32985; Wed, 1 Feb 2017 20:43:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0319.002; Wed, 1 Feb 2017 20:43:33 +0100 From: Christer Holmberg To: Magnus Westerlund , Jonathan Lennox Thread-Topic: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSeLyCjrr91gBvrE2+PKFOpdD0GaFS0M+AgAFqpACAAFjGoA== Date: Wed, 1 Feb 2017 19:43:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFD8C88@ESESSMB209.ericsson.se> References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM+JvjW651aQIg39/+Cymz3rHZjG/Yx2b xf7F55ktpi5/zGKx9l87uwOrx5IlP5k8vlz+zObR9uwOewBzFJdNSmpOZllqkb5dAlfGp84/ bAXPmSs+r7jL1MD4namLkZNDQsBE4uq5pYxdjFwcQgLrGSW2z38AlhASWMQo8W9NUBcjBweb gIVE9z9tkLCIQJxE07Y97CD1zALNTBJ3dk9hB0kICxRJTN23nwmiqFhi3cuZLBC2k0Tr9BNg NSwCKhK/Px1nBLF5BXwlvjxYwgqxeAWjxNp1H8EaOAUcJD48/cQKYjMKiEl8P7UGbCizgLjE rSfzoa4WkFiy5zwzhC0q8fLxP1YIW0micckTVoh6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJ jKKzkIydhaRlFpKWWUhaFjCyrGIULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjKiDW35b7WA8 +NzxEKMAB6MSD6+BwaQIIdbEsuLK3EOMEhzMSiK8DJZAId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4rxmK++HCwmkJ5akZqemFqQWwWSZODilGhiDNVbcDzvSW8GV/V9d2HvRWs37pR1VYif8bjFt uKX01VYlbdEReV2Nl0HFW2Ue/0xJWHi8yVrkP8sPnlsHO2ZtNCyvcDu0QXi5bN/D9tMi0nKb pudvM/rz7pnsYauci0GZvDcnXp8vuvqF55qECAM96Rt3hC+xT4k5zLTaRaBO2jr+ZFDYzl9K LMUZiYZazEXFiQBxE7G3pAIAAA== Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 19:43:55 -0000 Hi, >> I have one question, however. What should happen if an RTP packet=20 >> (without a MID) is received for a stream that has an existing mapping=20 >> to an m=3D line, but whose PT is not valid for that m=3D line? I don't think that case is specific to BUNDLE, is it? It could happen even = without multiplexing. I agree with Magnus that it should be treated as an error. (There could even be cases where the PT isn't valid for ANY m- line). Regards, Christer From nobody Wed Feb 1 12:02:33 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC7012956E; Wed, 1 Feb 2017 12:02:32 -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_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 QHdDVnqPlxiy; Wed, 1 Feb 2017 12:02:30 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1105D129573; Wed, 1 Feb 2017 12:02:30 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v11JxbJh009199; Wed, 1 Feb 2017 15:02:27 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 288n9qanf3-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 01 Feb 2017 15:02:27 -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.0195.001; Wed, 1 Feb 2017 14:02:26 -0600 From: Jonathan Lennox To: Magnus Westerlund Thread-Topic: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSe+hqNyVXjtU64EysMGTN3ByD2aFTP9MAgAFqoQCAAE6GgA== Date: Wed, 1 Feb 2017 20:02:25 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.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: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-01_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702010197 Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:02:32 -0000 > On Feb 1, 2017, at 10:21 AM, Magnus Westerlund wrote: >=20 > Hi Jonathan, >=20 > Thanks for the feedback. See inline for my attempt to answer them. >=20 > Den 2017-01-31 kl. 18:43, skrev Jonathan Lennox: >> In general, this looks good. >>=20 >> I have one question, however. What should happen if an RTP packet >> (without a MID) is received for a stream that has an existing mapping >> to an m=3D line, but whose PT is not valid for that m=3D line? >>=20 >=20 > So, the text in JSEP-18 didn't specify this either. However, I do have an= opinion on this. >=20 >> Should it 1. Cause the stream=92s mapping to be moved to another m=3D >> line, if the received PT is in the payload type table for some other >> m=3D line? or >=20 > I would recommend against this due to that we will have to go into under = which circumstances that one can accept this, and when not. Bo Burman and I= had some discussion on this. We arrived at some relevant aspects of this. = The first is that one have one to consider precedence rules between PTs, as= well as a=3Dssrc and MID. In general we think mismatch between the informa= tion is to be considered an error. However, using PT and MID could cause st= range error cases, where packets without MID ends up in on m=3D line with t= he PT and the ones with MID are dropped as inconsistent. I would claim that= this stream is always in error. >=20 > I would also note that Bundle specification currently forbids PT based sw= itching, but for a different reasons. Section 10.1 says: >=20 > o A given SSRC MUST NOT transmit RTP packets using payload types > that originate from different bundled "m=3D" lines. >=20 > NOTE: The last bullet above is to avoid sending multiple media types > from the same SSRC. If transmission of multiple media types are done > with time overlap, RTP and RTCP fail to function. Even if done in > proper sequence this causes RTP Timestamp rate switching issues > [RFC7160]. However, once an SSRC has left the RTP session (by > sending an RTCP BYE packet), that SSRC can be reused by another > source (possibly associated with a different bundled "m=3D" line) after > a delay of 5 RTCP reporting intervals (the delay is to ensure the > SSRC has timed out, in case the RTCP BYE packet was lost [RFC3550]). >=20 > But, we do note that the limitation is not strictly necessary in regards = to the motivation. The minimal limitation based on the motivation would be = to require that a SSRC only uses PTs of the same media type and clock rate = within a single bundle group. Using shared PTs, which the current limitatio= n requires automatically meets that goal, and is easier to check for. Okay, that=92s reasonable, I think. > We also noted that BUNDLE should clarify how MID relates to a=3Dssrc (RFC= 5576). My interpretation is that a=3Dssrc locks a RTP stream to a particula= r m=3D line, and can't be moved. So any MID value other than that matches t= he m=3D line that has the a=3Dssrc value would be an error case. For usages= that intend to have a RTP stream to bounce between m=3D lines should not u= se a=3Dssrc, only MID. I think it would be good to clarify this in the BUND= LE specification. That seems reasonable, but it=92s not what your proposed algorithm does, as= far as I can tell. Receiving a MID for a different m=3D line moves the so= urce, regardless of how the source initially ended up associated.=20 > > 2. Be an error? >=20 > This would be my preferred choice. >=20 >>=20 >> In other words, should it be possible for PT-mapping to cause streams >> to change their mappings? >=20 > To conclude: No, as it would cause several additional complexities and po= ssible branches in the algorithm. The use case for moving SSRCs between m= =3D lines are supported when using MID, and the m=3D lines are correctly co= nfigured with shared PTs. >=20 > Cheers >=20 > Magnus >=20 >>=20 >> (Should this decision depend on what caused the stream to be mapped >> to its current m=3D line?) >>=20 >>> On Jan 27, 2017, at 11:43 AM, Magnus Westerlund >>> wrote: >>>=20 >>> MMUSIC and RTCWEB, >>>=20 >>> Here is now a more complete text proposal that also considers the >>> RTCP. It also goes further than what Appendix B defines in one >>> aspect, namely explicitly considering third party RTCP reporting >>> and what to do with it. >>>=20 >>> Feedback is much appreciated. I plan to put this into a PR towards >>> JSEP APPENDIX B on monday. If only to get the JSEP authors >>> attention ;-). However, the text is really intended for the next >>> version of BUNDLE. >>>=20 >>>=20 >>> X. Associating RTP/RTCP With Correct SDP Media Description >>>=20 >>> As described in [RFC3550], RTP packets are associated with RTP >>> streams [RFC7656]. Each RTP stream is identified by an SSRC >>> value, and each RTP packet carries an SSRC value that is used to >>> associate the packet with the correct RTP stream. RTCP packets >>> also uses SSRCs to identify on which RTP streams any report or >>> feedback relate to. Thus, an RTCP packet will commonly carry >>> multiple SSRC values, and might therefore be providing feedback or >>> report on multiple RTP streams. >>>=20 >>> In order to be able to process received RTP/RTCP packets correctly >>> it must be possible to associate an RTP stream with the correct >>> "m=3D" line, as the "m=3D" line and SDP attributes associated with the >>> "m=3D" line contain information needed to process the packets. >>>=20 >>> As all RTP streams associated with a BUNDLE group are part of the >>> same RTP session and using the same address:port combination for >>> sending and receiving RTP/RTCP packets, the local address:port >>> combination cannot be used to associate an RTP stream with the >>> correct "m=3D" line. In addition, multiple RTP streams might be >>> associated with the same "m=3D" line. >>>=20 >>> Also, as described in Section 10.1.1, the same payload type value >>> might be used by multiple RTP streams, in which case the payload >>> type value cannot be used to associate an RTP stream with the >>> correct "m=3D" line. However, there are cases where each "m=3D" line >>> has unique payload type values, and then the payload type could >>> serve as indicator to the relevant "m=3D" line the RTP stream is >>> associated with. >>>=20 >>> An offerer and answerer can inform each other which SSRC values >>> they will use for an RTP stream by using the SDP 'ssrc' attribute >>> [RFC5576]. However, an offerer will not know which SSRC values >>> the answerer will use until the offerer has received the answer >>> providing >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 >>> [Page 2] >>>=20 >>> Internet-Draft Abbreviated-Title January >>> 2017 >>>=20 >>>=20 >>> that information. Due to this, before the offerer has received >>> the answer, the offerer will not be able to associate an RTP stream >>> with the correct "m=3D" line using the SSRC value associated with the >>> RTP stream. In addition, the offerer and answerer may start using >>> new SSRC values mid-session, without informing each other using the >>> SDP 'ssrc' attribute. >>>=20 >>> In order for an offerer and answerer to always be able to >>> associate an RTP stream with the correct "m=3D" line, the offerer and >>> answerer using the BUNDLE extension MUST support the mechanism >>> defined in Section 14, where the offerer and answerer includes the >>> identification-tag (provided by the remote peer) associated with >>> an "m=3D" line in the RTP Streams and in RTCP SDES packets part of a >>> BUNDLE group. >>>=20 >>> The mapping from an SSRC to an identification-tag is carried in >>> RTCP SDES packets or in RTP header extensions (Section 14). Since >>> a compound RTCP packet can contain multiple RTCP SDES packets, and >>> each RTCP SDES packet can contain multiple chunks, an RTCP packet >>> can contain several SSRC to identification-tag mappings. The >>> offerer and answerer maintain tables mapping RTP streams identified >>> by SSRC to "m=3D" lines identified by the identification-tag. These >>> tables are updated each time new information that affects how >>> packets should be processed and routed are received. >>>=20 >>> To prepare for demultiplexing RTP streams to the correct "m=3D" >>> line, the following steps MUST be followed for each BUNDLE group >>> based on the SDP signalling information. >>>=20 >>> Construct a table mapping MID to "m=3D" line for each "m=3D" line in >>> this BUNDLE group. Note that an "m=3D" line may only have one MID. >>>=20 >>> Construct a table mapping incoming RTP streams (SSRCs) to their >>> "m=3D" line for each "m=3D" line in this BUNDLE group and for each RTP >>> stream explicitly signalled for receiving in that "m=3D" line. >>>=20 >>> Construct a table mapping payload types to "m=3D" line for each "m=3D" >>> line in the BUNDLE group and for each payload type configured for >>> receiving in that "m=3D" line. If any payload type is configured for >>> receiving in more than one "m=3D" line in the BUNDLE group, do not it >>> include it in the table. >>>=20 >>> Note that for each of these tables, there can only be one mapping >>> for any given key (MID, SSRC, or PT). In other words, the tables >>> are not multimaps. >>>=20 >>> As "m=3D" lines are added or removed from the BUNDLE groups, or >>> their configurations are changed, the tables above MUST also be >>> updated. >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 >>> [Page 3] >>>=20 >>> Internet-Draft Abbreviated-Title January >>> 2017 >>>=20 >>>=20 >>> Received RTP packets that are syntactically correct are processed >>> by the RTP/RTCP protocol implementation for statistics etc. After >>> this processing they need to be routed to the higher layer context >>> associated with the "m=3D" line within the BUNDLE group. Somewhere >>> in the process where an received RTP packet is processed to be >>> delivered to the higher layer by RTP the matching step below MUST >>> be performed: >>>=20 >>> 1. Reception of an RTP packet for an RTP stream that has an >>> existing mapping in the RTP stream to m=3D line table. Before >>> proceeding in delivering the packet to the higher layer context >>> according to the RTP stream to "m=3D" line mapping table the >>> following checks MUST be performed: >>>=20 >>> A. If the packet carries an RTP header extension with a SDES MID >>> value that is not in the table mapping MID to "m=3D" line, then do >>> not deliver the RTP packet to higher layers. >>>=20 >>> B. If the packet carries an RTP header extension with a SDES MID >>> value that is in the table mapping MID to "m=3D" line, and the value >>> indicates a different "m=3D" line than the current RTP stream to "m=3D" >>> line mapping table, then update the RTP stream to "m=3D" line >>> mapping. >>>=20 >>> 2. Reception of an RTP packet for an RTP stream that has no >>> existing mapping to an m=3D line. In this case the following actions >>> MUST be performed: >>>=20 >>> A. If the packet carries an RTP header extension with a SDES MID >>> value that is in the table mapping MID to "m=3D" line, then create an >>> entry in the RTP stream to "m=3D" line mapping table for this RTP >>> stream (SSRC). Then deliver the RTP packet to the "m=3D" line >>> context of the created mapping and stop. >>>=20 >>> B. If the packet carries a Payload Type that is in the payload >>> type table, then create an entry in the RTP stream to "m=3D" line >>> mapping table for this RTP stream (SSRC). Then deliver the RTP >>> packet to the "m=3D" line context of the created mapping and stop. >>>=20 >>> C. Otherwise do not deliver the RTP packet to higher layers. Note, >>> this includes unknown MID values. >>>=20 >>> For each RTCP packet received (including each RTCP packet that is >>> part of a compound RTCP packet), the RTCP packet needs to be >>> processed by the RTP/RTCP implementation and relevant information >>> and data from the RTCP packets needs to be routed to the >>> appropriate handler for the related RTP streams. The appropriate >>> handler is determined by using the RTP stream to "m=3D" line mapping >>> table. >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 >>> [Page 4] >>>=20 >>> Internet-Draft Abbreviated-Title January >>> 2017 >>>=20 >>>=20 >>> On reception of any compound RTCP packet prior to dispatching the >>> received information and data, if there is an RTCP SDES packet >>> included that SHOULD be processed first. If that SDES packet >>> contains SDES MID entries, this can results in updates and >>> additions to the RTP stream to "m=3D" line mapping table. Thus each >>> of the SDES MID items are processed and the current table entries >>> are checked if the corresponding MID value matches the current RTP >>> stream to "m=3D" line mapping, else the entry is updated. If there >>> is no RTP stream to "m=3D" line table mapping entry for the received >>> SDES item's SSRC, such an entry is created. Note, that in the >>> process of updating the table entries, update flap suppression as >>> discussed in Section 4.2.6 of [RFC7941] should be considered. >>>=20 >>> The various different RTCP packets as well as their various sub >>> parts, such as the various RTCP Feedback message types, relates to >>> the RTP streams in a couple of different ways. The currently >>> known patterns are the following: >>>=20 >>> Reports on outgoing RTP streams: For all RTP streams that this >>> endpoint is the source of, it can expect to receive report blocks >>> of several types identified as relating to an outgoing stream. The >>> basic pattern for these blocks are that the RTCP packet header >>> identifies the source of the reports, as identified by an SSRC, and >>> containing one or more report blocks, where each report block >>> identifies the RTP stream, using the SSRC, the report relates to. >>> For this pattern the relevant report information is provided to the >>> higher layer associated with the "m=3D" line the RTP Stream to "m=3D" >>> line table identifies. The source SSRC as identifier of the >>> endpoint that the report originates are relevant for interpreting >>> the information, but not necessarily for routing. Example of this >>> is pattern are: >>>=20 >>> Sender Report (SR) and Receiver Report (RR) The basic receiver >>> report blocks from RFC3550 start with the SSRC of the RTP stream >>> they report on. >>>=20 >>> Extended Reports (XR): RFC3611 is a framework that enables a large >>> number of different reports. However, a large number of these >>> report formats are reporting on specific RTP streams and thus each >>> individual report of these types contains a SSRC field to identify >>> the RTP stream. >>>=20 >>> RTCP Feedback Messages for outgoing RTP streams: The RFC 4585 >>> RTCP feedback messages allow for a number of different type of >>> feedback messages. However, the RTCP feedback message header >>> contains the SSRC identifying the source of the feedback messages >>> as well as the actual type of the feedback. Some of the feedback >>> messages also uses the target SSRC field in the header to identify >>> which >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 >>> [Page 5] >>>=20 >>> Internet-Draft Abbreviated-Title January >>> 2017 >>>=20 >>>=20 >>> RTP stream the feedback is related to. For these types all the FCI >>> entries, if multiple ones are forwarded to the identified handler. >>> Examples of this pattern are: >>>=20 >>> Picture Loss Indication (PLI): RFC 4585 (PT=3DPSFB, FMT=3D1). >>>=20 >>> Slice Loss Indication (SLI): RFC 4585 (PT=3DPSFB, FMT=3D2). >>>=20 >>> Reference Picture Selection Indication (RPSI): RFC 4585 (PT=3DPSFB, >>> FMT=3D3). >>>=20 >>> Generic NACK: [RFC4585] (PT=3DRTPFB and FMT=3D1). >>>=20 >>> Other feedback messages includes the target SSRC in the Feedback >>> Control Information (FCI). Here each FCI needs to be processed and >>> the SSRC field identified. And the individual FCI combined with >>> the RTCP packet header context needs to be forwarded to the >>> identified handler. Example of this pattern are: >>>=20 >>> Full Intra Request (FIR): [RFC5104] (PT=3DPSFB, FMT=3D4). >>>=20 >>> Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=3DPSFB, >>> FMT=3D5). >>>=20 >>> Temporal-Spatial Trade-off Notification (TSTN): This [RFC5104] >>> defined message (PT=3DPSFB, FMT=3D5) is actually a notifciation in >>> response to a TSTR this endpoint sent using the SSRC the FCI >>> identifies as source. >>>=20 >>> H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=3DPSFB, >>> FMT=3D7). >>>=20 >>> Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=3DPSFB, >>> FMT=3DTBD). >>>=20 >>> Descriptive or Notifications for an incoming RTP stream: There >>> exist some RTCP packet types that provides additional information >>> or notifies about events related to the RTP stream identified. In >>> these cases the RTP stream is identified using the SSRC field >>> value, and the information is provided to the higher layer >>> associated with the "m=3D" line for the incoming RTP stream as >>> identified by the current RTP stream to "m=3D" line table. For this >>> type of pattern it is common that the RTCP packets and information >>> is repeated, either periodically (e.g. SDES items), or for a >>> duration (e.g. BYE), thus suppression of repetitions can be >>> considered. Examples of these are: >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 >>> [Page 6] >>>=20 >>> Internet-Draft Abbreviated-Title January >>> 2017 >>>=20 >>>=20 >>> Source Description (SDES) RTCP Packet: The base RTP/RTCP protocol >>> [RFC3550] defines SDES RTCP packets as a way of providing per >>> source (SSRC) specific information about the source. An SDES >>> packet contains zero or more chunks, where a chunk contains the >>> SSRC for the source being described by the one or more items >>> included in the chunk. Forward the SDES items in each chunk to the >>> RTP stream's handler. >>>=20 >>> Goodbye (BYE) RTCP Packet: This RTP/RTCP protocol [RFC3550] >>> mechanism indicates that a particular RTP stream is leaving the RTP >>> session. Thus, a most relevant event to inform the handler for >>> this RTP steam of. >>>=20 >>> Third Party Targeted Reports or Feedback: There exist some >>> multiparty RTP Topologies that results in that an endpoint receives >>> third party reports (SR [RFC3550], RR [RFC3550] or XR [RFC3611]) as >>> well as Feedback Messages [RFC4585] that relates to or targets an >>> SSRC that originates from another endpoint, and where the source of >>> the RTCP packet is also another endpoint. This type of packets >>> should be forwarded to the higher layer function dealing with the >>> third party reporting. And if none exist then they can be >>> suppressed. As the third party handler can be focused on >>> determining the conditions for the source of the reports and >>> feedback, or focused on how the RTP stream source progresses, or >>> both recommendations can't be made. >>>=20 >>> APP Packets: The RTCP APP Packets [RFC3550] are a mechanism that >>> enables experimentation. The APP packet only specifies the source >>> of the packet. Thus this information can be related to any of the >>> "m=3D" lines, thus deliver a copy of the packet to each "m=3D" line or >>> an APP specific handler. >>>=20 >>> -- Cheers >>>=20 >>> Magnus Westerlund >>>=20 >>> ---------------------------------------------------------------------- >>>=20 >>>=20 > Services, Media and Network features, Ericsson Research EAB/TXM >>> ---------------------------------------------------------------------- >>>=20 >>>=20 > 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 > _______________________________________________ >>> mmusic mailing list mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 >>=20 >>=20 >=20 >=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 From nobody Wed Feb 1 12:03:37 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1595129573; Wed, 1 Feb 2017 12:03:27 -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_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 sIf4dIlUawrk; Wed, 1 Feb 2017 12:03:27 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2CE12956E; Wed, 1 Feb 2017 12:03:26 -0800 (PST) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v11Jx6P5003183; Wed, 1 Feb 2017 15:03:22 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 288px82xw1-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 01 Feb 2017 15:03:22 -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.0195.001; Wed, 1 Feb 2017 14:03:21 -0600 From: Jonathan Lennox To: Christer Holmberg Thread-Topic: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSe+hqNyVXjtU64EysMGTN3ByD2aFTP9MAgAFqoQCAAElBgIAABYiA Date: Wed, 1 Feb 2017 20:03:21 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BFD8C88@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFD8C88@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: text/plain; charset="utf-8" Content-ID: <821011E1FB73EE43B58A4FC338808759@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-01_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702010197 Archived-At: Cc: Magnus Westerlund , "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:03:28 -0000 V2VsbCwgeWVzLCBjbGVhcmx5IGlmIHRoZSBzb3VyY2UgaXMgc2VudCB3aXRoIGEgUFQgdGhhdCBp c27igJl0IGluIGFueSBtLWxpbmUgaW4gdGhlIGJ1bmRsZSwgb3Igd2l0aCBhIFBUIHRoYXTigJlz IG5vbi11bmlxdWUgYW5kIGlzbuKAmXQgaW4gdGhlIG0tbGluZSBpdOKAmXMgY3VycmVudGx5IGFz c29jaWF0ZWQgd2l0aCwgaXTigJlzIGFuIGVycm9yLg0KDQpUaGUgcXVlc3Rpb24gd2FzIHdoZXRo ZXIgd2Ugd2FudGVkIHRvIHRyZWF0IHRoZSB1bmlxdWUgUFQgY2FzZSBzcGVjaWFsbHksIGJ1dCBJ IGNhbiBhcHByZWNpYXRlIE1hZ251c+KAmXMgYXJndW1lbnQgdGhhdCB3ZSBzaG91bGRu4oCZdC4N Cg0KSeKAmWQgbGlrZSB0byBoZWFyIGNvbW1lbnQgZnJvbSB0aGUgZm9sa3Mgd2hv4oCZdmUgYmVl biBhcmd1aW5nIGluIGZhdm9yIG9mIFBULWJhc2VkIG1hcHBpbmcsIHRob3VnaC4gIChJIGdldCB0 aGUgZmVlbGluZyB0aGF0IE1hZ251cyBpcyBhZ3JlZWluZyB0byBpdCBvbmx5IGdydWRnaW5nbHku KQ0KDQo+IE9uIEZlYiAxLCAyMDE3LCBhdCAyOjQzIFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4+PiBJ IGhhdmUgb25lIHF1ZXN0aW9uLCBob3dldmVyLiAgV2hhdCBzaG91bGQgaGFwcGVuIGlmIGFuIFJU UCBwYWNrZXQgDQo+Pj4gKHdpdGhvdXQgYSBNSUQpIGlzIHJlY2VpdmVkIGZvciBhIHN0cmVhbSB0 aGF0IGhhcyBhbiBleGlzdGluZyBtYXBwaW5nIA0KPj4+IHRvIGFuIG09IGxpbmUsIGJ1dCB3aG9z ZSBQVCBpcyBub3QgdmFsaWQgZm9yIHRoYXQgbT0gbGluZT8NCj4gDQo+IEkgZG9uJ3QgdGhpbmsg dGhhdCBjYXNlIGlzIHNwZWNpZmljIHRvIEJVTkRMRSwgaXMgaXQ/IEl0IGNvdWxkIGhhcHBlbiBl dmVuIHdpdGhvdXQgbXVsdGlwbGV4aW5nLg0KPiANCj4gSSBhZ3JlZSB3aXRoIE1hZ251cyB0aGF0 IGl0IHNob3VsZCBiZSB0cmVhdGVkIGFzIGFuIGVycm9yLg0KPiANCj4gKFRoZXJlIGNvdWxkIGV2 ZW4gYmUgY2FzZXMgd2hlcmUgdGhlIFBUIGlzbid0IHZhbGlkIGZvciBBTlkgbS0gbGluZSkuDQo+ IA0KPiBSZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXINCg0K From nobody Wed Feb 1 12:04:58 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A77129573; Wed, 1 Feb 2017 12:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 IqwRqJcdpbj6; Wed, 1 Feb 2017 12:04:50 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A03129572; Wed, 1 Feb 2017 12:04:49 -0800 (PST) X-AuditID: c1b4fb3a-d5ffb70000004068-86-58923f5e67c8 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id DD.FB.16488.E5F32985; Wed, 1 Feb 2017 21:04:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0319.002; Wed, 1 Feb 2017 21:04:40 +0100 From: Christer Holmberg To: Alissa Cooper , The IESG Thread-Topic: Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) Thread-Index: AQHSfLiANa/BcGrwW06zr+Sq61BcZKFUkZKA Date: Wed, 1 Feb 2017 20:04:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se> References: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> In-Reply-To: <148597343438.19146.978420245557276514.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7mW6C/aQIgzUHmCymn/nLaHHw4jJW i/cXdC1m/JnIbHF+53omi6nLH7M4sHlM+b2R1ePLk5dMHkuW/GQKYI7isklJzcksSy3St0vg ynh15xNTwReBiq6509kaGPcIdDFyckgImEhMeLWerYuRi0NIYB2jxMeDm5khnEWMEtc/H2Tq YuTgYBOwkOj+pw3SICJgLzHt6g82EJtZoJNJYtJ5RxBbWCBeYsqHvawQNQkSZ6a1sEPYRhIn v04Gs1kEVCRmP9jBDGLzCvhKrJh8kxHEFhLwkfjz7xdYDSdQfO33+WA2o4CYxPdTa5ggdolL 3HoynwniaAGJJXvOM0PYohIvH/9jhbCVJBqXPGEFOZlZQFNi/S59iFZFiSndD9kh1gpKnJz5 hGUCo+gsJFNnIXTMQtIxC0nHAkaWVYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBMXVwy2+r HYwHnzseYhTgYFTi4TUwmBQhxJpYVlyZe4hRgoNZSYSXwRIoxJuSWFmVWpQfX1Sak1p8iFGa g0VJnNds5f1wIYH0xJLU7NTUgtQimCwTB6dUA6N45PZL/zpc9qb8/tB0WD7aOvyvQ+GO1FbP VNNu9vgbj79nPvtopXev13CL98VrjE/U1W9tiJ53eMp1jvX69hdV3xrOu366aGaLlabK9r7N G96u3se8SfxY87ZpZ485mWS7bFvYtTKjI/5L602RDj5jFvPTb5jtldI/nv9ssDQ1aLbjuuL2 hT5KLMUZiYZazEXFiQAuuXempQIAAA== Archived-At: Cc: "fandreas@cisco.com" , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-4572-update@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:04:51 -0000 SGkgQWxpc3NhLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3ISBTZWUgYmVsb3cuDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCj5TZWN0aW9uIDUuMSBzYXlz Og0KPg0KPiAgIkFuIGVuZHBvaW50IE1BWSwgaW4gYWRkaXRpb24gdG8gaXRzIG1vcmUgcHJlZmVy cmVkIGhhc2ggZnVuY3Rpb24sDQo+ICAgYWxzbyB2ZXJpZnkgdGhhdCBlYWNoIGNlcnRpZmljYXRl IHVzZWQgbWF0Y2hlcyBmaW5nZXJwcmludHMNCj4gICBjYWxjdWxhdGVkIHVzaW5nIG90aGVyIGhh c2ggZnVuY3Rpb25zLiAgVW5sZXNzIHRoZXJlIGlzIGEgbWF0Y2hpbmcNCj4gICBmaW5nZXJwcmlu dCBmb3IgZWFjaCB0ZXN0ZWQgaGFzaCBmdW5jdGlvbiwgdGhlIGVuZHBvaW50IE1VU1QgTk9UDQo+ ICAgZXN0YWJsaXNoIHRoZSBUTFMgY29ubmVjdGlvbi4iDQo+DQo+IFRoaXMgc2VlbXMgYSBsaXR0 bGUgd2VpcmQgdG8gbWUuIEl0J3MgdXAgdG8gdGhlIGVuZHBvaW50IHRvIGRlY2lkZSB3aGV0aGVy IHRvIGNoZWNrIGZvciBlcnJvcnMsIGFuZCB0aGVuIGlmIGl0IA0KPiBkb2VzIGZpbmQgYW4gZXJy b3IgaXQgY2FuJ3Qgc2V0dXAgdGhlIGNvbm5lY3Rpb24sIHdoZXJlYXMgaWYgaXQganVzdCBoYWRu J3QgY2hlY2tlZCBpdCB3b3VsZCBiZSBhYmxlIHRvIHNldHVwIA0KPiB0aGUgY29ubmVjdGlvbi4g SSB0aGluayBpdCB3b3VsZCBoZWxwIHRvIGV4cGxhaW4gd2h5IGFuIGVuZHBvaW50IHdvdWxkIGJl IG1vdGl2YXRlZCB0byBjaGVjayBtdWx0aXBsZSBmaW5nZXJwcmludHMuDQoNCkkgdGhpbmsgdGhl IG9ubHkgdXNlLWNhc2UgdGhhdCBjYW1lIHVwIHdhcyBhIHNpdHVhdGlvbiB3aGVyZSB0aGUgcmVj ZWl2ZXIgaXMgbm90IHN1cmUgd2hpY2ggaGFzaCBmdW5jdGlvbiBpcyB0aGUgInN0cm9uZ2VzdCIs IGFuZCB0aGVyZWZvciBjaGVja3MgbXVsdGlwbGUuIEhvd2V2ZXIsIGl0IHdhcyBhbHNvIHJlYWxp emVkIHRoYXQgd2l0aCB0aGUgbXVsdGlwbGUgc2V0IG9mIGhhc2ggZnVuY3Rpb25zIHN1Y2ggc2l0 dWF0aW9uIGlzIHZlcnkgdW5saWtlbHkgdG8gb2NjdXIuDQoNClNvLCBJIGNvdWxkIGFkZCB0aGUg Zm9sbG93aW5nIG5vdGU6DQoNCiJOT1RFOiBBbiBlbmRwb2ludCBtaWdodCBjaG9vc2UgdG8gbWF0 Y2ggZWFjaCB1c2VkIGNlcnRpZmljYXRlIGFnYWluc3QgZmluZ2VycHJpbnRzIGNhbGN1bGF0ZWQg dXNpbmcgbXVsdGlwbGUNCmhhc2ggZnVuY3Rpb25zIGUuZywgaWYgdGhlIGVuZHBvaW50IGlzIHVu c3VyZSB3aGljaCBoYXNoIGZ1bmN0aW9uIGlzIHRoZSBzdHJvbmdlc3QuIg0KDQouLi5vciB3ZSBj b3VsZCBzaW1wbHkgZGVsZXRlIHRoZSB0ZXh0LiBJIHBlcnNvbmFsbHkgd291bGQgZ28gZm9yIHRo YXQsIGJ1dCBpbiBjYXNlIG90aGVycyB3YW50IHRvIGtlZXAgaXQgSSBoYXZlIG5vIHByb2JsZW0g d2l0aCB0aGF0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg== From nobody Wed Feb 1 12:13:19 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECE21299DB; Wed, 1 Feb 2017 12:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 6tLI9B4jg_p8; Wed, 1 Feb 2017 12:13:17 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E2712956E; Wed, 1 Feb 2017 12:13:16 -0800 (PST) X-AuditID: c1b4fb2d-e76b398000007e3d-56-5892415a762d Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id A7.A6.32317.A5142985; Wed, 1 Feb 2017 21:13:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Wed, 1 Feb 2017 21:12:53 +0100 From: Christer Holmberg To: Stephen Farrell , Jonathan Lennox Thread-Topic: Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS) Thread-Index: AQHSe9xPXcuaz7bZMUKOtO0DGNu5LqFSxOkAgAFij4CAAG+J8A== Date: Wed, 1 Feb 2017 20:12:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFD8E2F@ESESSMB209.ericsson.se> References: <148587892598.2448.6982128247176255180.idtracker@ietfa.amsl.com> <3DCBB043-EF35-425A-A005-93488A726369@vidyo.com> <36000381-1043-e5a8-b03d-000eef833cef@cs.tcd.ie> In-Reply-To: <36000381-1043-e5a8-b03d-000eef833cef@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000B_01D27CD8.52546B10" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPIsWRmVeSWpSXmKPExsUyM2K7q26U46QIg9a96hYHLy5jtXh/Qddi xp+JzBb7F59ntji/cz2TxdTlj1kspu+9xu7A7jHl90ZWj7XdV9k8liz5yeTR9uwOewBLFJdN SmpOZllqkb5dAlfGsjOr2AteZlSsv3eJsYHxTHwXIyeHhICJxJGty9i7GLk4hATWMUpsmAnj LGKUePf/JVsXIwcHm4CFRPc/bZAGEYFwic175zKD1DALvGeUmN+6lhUkISwQI7HvzHQWkHoR gViJ1beg6p0kNrx5BjaGRUBF4vV6IZAwr4CvxK++K2CdQgKbGCVe31IGsTkFbCWOHVrOCGIz CohJfD+1hgnEZhYQl7j1ZD4TxM0iEg8vnmaDsEUlXj7+xwphK0k0LnnCCnFaL6PEifv/mSGW CUqcnPmEZQKjyCwks2Yhq5uFpA6iSFvi6c2ncPayha+ZIWxriRm/DrJB2IoSU7ofskPYphKv j35kXMDIsYpRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMGoPbvmtu4Nx9WvHQ4wCHIxKPLwG BpMihFgTy4orcw8xqgDNebRh9QVGKZa8/LxUJRFeBkugNG9KYmVValF+fFFpTmrxIUZpDhYl cV6zlffDhQTSE0tSs1NTC1KLYLJMHJxSDYy+L+XEfcrM189fJXP4Vly8vK8xo4z8dcv/l5fb rt583Phg11tG7Y3/al0DH+49Oi/u+OyYxHcztTbun1de81KttkHm/8ECc3n/m9v3ajQJBje4 XEn2f20Yp1kZU7xA/FMQW9W6ydKc79Ue3hVke5ZU6hYXyNG2lHF7W9zStG1zG9z/myV3eiix FGckGmoxFxUnAgBYsTFv4gIAAA== Archived-At: Cc: Flemming Andreasen , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-4572-update@ietf.org" , The The IESG , mmusic Subject: Re: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:13:19 -0000 ------=_NextPart_000_000B_01D27CD8.52546B10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, >Bottom line I guess is I'm still not sure that the right >set of hashes are included but we've discussed it so I'll >clear. I'm happy to continue to discuss it if you want, or >you can continue to discuss amongst yourselves if that's >better, or you can just forge on and be glad I'm out of >your hair if that's right:-) It won't last for long, though, because I have two other security = related drafts coming up for review soon :) Thanks! Regards, Christer Collating various responses into one... On 31/01/17 17:23, Jonathan Lennox wrote: >=20 >> On Jan 31, 2017, at 11:08 AM, Stephen Farrell >> wrote: >>=20 >> = ---------------------------------------------------------------------- >> >>=20 DISCUSS: >> = ---------------------------------------------------------------------- >> >> >> >>=20 I've two (or 4 depending how you count:-) things >> I'd like to check here. Should be pretty easy to handle. >>=20 >> (1) section 5: I'm wondering if we have the right set of hash >> functions here. Deprecating md2 and md5 is great, but I have a >> bunch of questions about the others: >>=20 >> (1.1) why not also say that sha-1 MUST NOT be used for new things >> (or similar)? >=20 > We say (section 5.1) that SHA-256 MUST be used for one of the > fingerprints; implementations MAY send additional fingerprints as > well. >=20 > There=E2=80=99s concern that there may be existing implementations = needing > SHA-1 (since 4572 made that the MTI algorithm). The need for interop > makes defining =E2=80=9Cnew things=E2=80=9D rather complicated. >=20 > Is that sufficient? I guess. But is there really that much use of fingerprints today that you need to preserve sha-1? (Honest question, I'm just ignorant:-) >=20 >=20 >> (1.2) do you really need sha-224 and 384? I think nobody uses those >> at all. On 01/02/17 07:18, Eric Rescorla wrote: > > It's certainly not correct that nobody uses SHA-384. > > In fact, for TLS 1.3, you can't sign anything with P-384 without using > SHA-384. Well, tls1.3 isn't used yet but even so, I'd say the set of folks using p384 will be tiny. Enough that this spec could say "these are just here in case they're needed, but we don't think you ought use 'em and you might not get great interop if you do" >>=20 >> (1.3) I'm a bit surprised you didn't add sha3 (and maybe remove >> sha-512 if that's not needed) Even if you don't encourage use of >> sha3, it might be good to include it in the abnf now in case it >> gets popular. >=20 > The policy is that the set of hash functions supported corresponds to > the hash functions defined for X.509 certificates. Unless I=E2=80=99m = missing > something, there=E2=80=99s no definition of SHA-3 for X.509 yet, is = there? > (If I=E2=80=99ve overlooked something, please let me know.) I'm not sure what'd be needed to use it? There are, I'm sure, OIDs, and once you have that you're all set. That is, I don't think one'd need an RFC to use sha-3 with x.509. >=20 > The list is an IANA registry, so once SHA-3 is defined for X.509, it > can also be added to the registry without needing an update to this > document. >=20 > For the same reason, this is why we included SHA-224 and SHA-384. If > no one=E2=80=99s using them, I=E2=80=99d think an update to RFC 4055 = would be in > order? Maybe in theory. I'm not sure who'd be motivated to do that though. >=20 >=20 >> (2) Wouldn't it be a good plan to say that TLS as-used MUST conform >> to BCP195? If not, why not? >=20 > My inclination would be to say yes, but I=E2=80=99ll let people with = more of > the existing implementations comment further in case there=E2=80=99s = some > issue. On 31/01/17 22:59, Martin Thomson wrote: > If we said MUST, I suspect that we'd end up making a whole lot of > implementations non-compliant. There's a lot of DTLS 1.0 out there. > That said, the same applies to SHA-1. > > I guess it depends on your stance regarding what is as opposed to what > should be. > > FWIW, we didn't ask this sort of question because the intent was to > clarify hash usage only, avoiding touching the rest of the document. > I'd be fine if you said "SHOULD" for BCP195 compliance. Would that work? >=20 >=20 >=20 ------=_NextPart_000_000B_01D27CD8.52546B10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVXDCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF+TCCA+GgAwIBAgIQ MQ1yPcGTNYDzhYWhrkFQyDANBgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMG A1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjAeFw0xNDExMDQxMjI4MTlaFw0xNzEx MDQxMjI4MThaMG8xETAPBgNVBAoMCEVyaWNzc29uMRowGAYDVQQDDBFDaHJpc3RlciBIb2xtYmVy ZzEtMCsGCSqGSIb3DQEJARYeY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tMQ8wDQYDVQQF EwZMTUZDSEgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCMb7fHWIV9CIFYYov86NR/ 6ibdVV0I+ZqVLE21zQB7otFv6DTKlVXE7iiC4HCvMhlGkg3/qFmAhAti5Z1Z7+5eEMEIP5JJEZ7f Mm6BME33Bkdgg4EfJrq4FUG28Hw2//0qx3jZWvK2W751AmEuUJ5nkZ6F00GnzJmOhbveadC8E5ke qwow9ria0/WazHiK3wxzjbanoQaZIA+oCKj5YyCv8cCTaSk4pEAbXwxthJ97BaZPahsnb4EZEP08 gxR5IE9NRi47Eqh6LtBjiWpaB42EmCEBxc2uIQ87tlJ0e2SvCo74rqxndXtUeaWauMjjt4DnhJdi XZY244D5J1gWssRFAgMBAAGjggHEMIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRy dXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEFBQcBAQR2 MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKG PGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYy LmNlcjApBgNVHREEIjAggR5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20wVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud DgQWBBRUo03/DrRAW2xpMmhN2uGkvDgx6jAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9L NzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALbwqG5inhl/xPxsuQWcH7GOUZIP Aw0JlKltVQ/TlsF7ig0J1iyzao6GsXItJ9H3WZPrCy5EQchJm7qcn2kKX8OGb+Yr53FisLR2gx+q krQMDOdix9Was0cvIjDWjAQnEZbxz/a+dzdAP0TrwNvD8282bIy0fCt/3uoBfzMnvQG+4wG018bD unc+NCj1FkSKkSRb9fP2Z2li65pfJcxtGIfb5zsXJZG4Gtbe0/hxlj3NccjB/zVPO7PQ+lnWmxtO iJQ2loA+62vQreUQr328XK4IHFnoU+zXiVfUN2urvvirQH7Ha70TBMa20J8Nn2aEvY6QYMEQJhAi VmNTiv4EGGv5heX5vb8yaj7pr4YIvb6D0r+pwpvfEE8YhAEWJgCZP7k5zQwhrpuSF/s+wEruXo59 sq9bOCefghktc5fwDu8ved98cifRPUnuT/c5slJJ8LjFn8d+LnGklUdFA9kLjIJVVx+TM4D/OTaR G+mPFbY2pTyR0V84PG7HLekupNsFzcme7IBkQ+1zkb9hjz6pyiodf6rh7ph+8XHWNgzbC5PdGCAN g8fVWrxqqOoEzvcUcPMy6XXJs0JWhWas8mJdHq2kGDDEpA7BbBatmtEqziXRnYGJeQK3eMDXXtmO eBSA4y7YZ47y+CxvbknSQ5dyghwkEq+a7ORPGVjsjtWJYJ6dMIIGtjCCBJ6gAwIBAgIRAKAMy8yb mZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNV BAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXs MmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHf Ozlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FA cLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenI UwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP 5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA1 41dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6Mqe aTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYB BQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20w SwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxp YXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYB BAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNv bmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9 kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg 36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiX g5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ 6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5 tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6 n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHr ZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIDLDCCAygC AQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MgIQMQ1yPcGTNYDzhYWhrkFQyDAJBgUrDgMCGgUAoIIBszAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDEyMDEyNDhaMCMGCSqGSIb3DQEJBDEWBBSC EFbs5oIKlqGmUgvXCI1vZxvrFzBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhAxDXI9wZM1gPOFhaGuQVDI MF8GCyqGSIb3DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQMQ1yPcGTNYDzhYWhrkFQyDCBkwYJKoZIhvcNAQkPMYGF MIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZI AWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQA5lZsgtKYUFXjUIj0pW+fM6YF9 TTLA4KNbLqsXmhm3qguBzj5ijfEP5dohMqMGlVz0arw3Ipm3Hjr6nizA5PwbtmTplNTpV+7MPPrA F/zs1Aiw9+WLxpk8LQ3BTm9I9f3B0vzx/vuP6cdBWBs+gMXEMDa6YI2bZzxUFZtM9+Hi4hev0tUz 1Nb7/lHIMg11N43F46z59zF5nMcVhEnlyrA4eBtszD+hd2kmklgEm+m71mG6Np4NTP+lQwIyGDlQ tZHpWJxSmTqm8VVWly3tdftoCVjV9eDKXwY/YMxGwLVBDe9BImP3t3v86nhpctVccNTXQ+XCFieI D5tGi0XYnY7NAAAAAAAA ------=_NextPart_000_000B_01D27CD8.52546B10-- From nobody Wed Feb 1 12:14:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24AB1293F9; Wed, 1 Feb 2017 12:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=XG2sWzHc; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Vr0RSpkL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMoylOfNEKV1; Wed, 1 Feb 2017 12:14:49 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5988612956E; Wed, 1 Feb 2017 12:14:49 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C0E93209E6; Wed, 1 Feb 2017 15:14:48 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 01 Feb 2017 15:14:48 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=kLmu8YPTRxqRzN0 S8CTwzD7VDdE=; b=XG2sWzHc6cW72a9gtCZlm9cSX39mxZd0MX7Eni1Z83Q14v7 zslGvRYAmWxmu4PpbgTyBBHNkDo72FlTK0BNC3S5uLbG50vb1/Iau542yjnLG8dU WwOwqPZppQsyvT7yMR2LOflHIvkTUc2Ry/sgySa7+QuOvRknVoL2qGf8U5+g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=kLmu8YPTRxqRzN0S8CTwzD7VDdE=; b=Vr0RSpkL+rxTcqiOf5rN PvfFoccIqH1daR5y6cJ4L55Lq89DpfxgiPApuidSg2goheQyEbs8lrHsaXlqr6El j9EXi+CFFyBTlPiWPCFFy/2DJNYyi1ENx6oEVghonxjl6G2K2pBWfY9ZkNjAcktl Sx0Ig8fZUWGVpKH6TcJ2zGc= X-ME-Sender: X-Sasl-enc: VFDJeQYt9ONlCN7OOy7mLxW8Girz2cDbgP+st0avLuhV 1485980088 Received: from dhcp-10-150-9-217.cisco.com (unknown [173.38.117.85]) by mail.messagingengine.com (Postfix) with ESMTPA id 5779E241E0; Wed, 1 Feb 2017 15:14:48 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se> Date: Wed, 1 Feb 2017 15:14:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Flemming Andreasen , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-4572-update@ietf.org" , IESG , "mmusic@ietf.org" Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:14:50 -0000 > On Feb 1, 2017, at 3:04 PM, Christer Holmberg = wrote: >=20 > Hi Alissa, >=20 > Thank you for your review! See below. >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >> Section 5.1 says: >>=20 >> "An endpoint MAY, in addition to its more preferred hash function, >> also verify that each certificate used matches fingerprints >> calculated using other hash functions. Unless there is a matching >> fingerprint for each tested hash function, the endpoint MUST NOT >> establish the TLS connection." >>=20 >> This seems a little weird to me. It's up to the endpoint to decide = whether to check for errors, and then if it=20 >> does find an error it can't setup the connection, whereas if it just = hadn't checked it would be able to setup=20 >> the connection. I think it would help to explain why an endpoint = would be motivated to check multiple fingerprints. >=20 > I think the only use-case that came up was a situation where the = receiver is not sure which hash function is the "strongest", and = therefor checks multiple. However, it was also realized that with the = multiple set of hash functions such situation is very unlikely to occur. >=20 > So, I could add the following note: >=20 > "NOTE: An endpoint might choose to match each used certificate against = fingerprints calculated using multiple > hash functions e.g, if the endpoint is unsure which hash function is = the strongest." >=20 > ...or we could simply delete the text. I personally would go for that, = but in case others want to keep it I have no problem with that. It would make more sense to me to delete it but either solution would be = an improvement I think. Thanks, Alissa >=20 > Regards, >=20 > Christer >=20 >=20 From nobody Wed Feb 1 12:16:54 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADC7129566; Wed, 1 Feb 2017 12:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 7qqz0OpBA9d4; Wed, 1 Feb 2017 12:16:52 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7AFD12956E; Wed, 1 Feb 2017 12:16:51 -0800 (PST) X-AuditID: c1b4fb30-13a0498000007085-f2-589242327e5e Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id ED.BD.28805.13242985; Wed, 1 Feb 2017 21:16:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Wed, 1 Feb 2017 21:16:49 +0100 From: Christer Holmberg To: Jonathan Lennox Thread-Topic: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSeLyCjrr91gBvrE2+PKFOpdD0GaFS0M+AgAFqpACAAFjGoP//9gOAgAAT3cA= Date: Wed, 1 Feb 2017 20:16:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFD8E8E@ESESSMB209.ericsson.se> References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BFD8C88@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7pa6R06QIg7+feS2mz3rHZjG/Yx2b xf7F55ktpi5/zGKx9l87uwOrx5IlP5k8vlz+zObR9uwOewBzFJdNSmpOZllqkb5dAlfG571v 2Ase8VRsmP6NuYFxB08XIyeHhICJxO3uTqYuRi4OIYF1jBIXrj1jhHAWMUpcXXITKMPBwSZg IdH9TxukQURAQ+Lisw9sIDXMAjuZJN5OnM8KkhAWKJKYum8/E0RRscS6lzNZIGw/iY5X98Fs FgEViaUXloLV8wr4Stx+e5IFYtl8Jol5+xcygiQ4BWwlFryfCGYzCohJfD+1Bmwos4C4xK0n 85kgzhaQWLLnPDOELSrx8vE/VghbSaJxyRNWkKOZBTQl1u/Sh2hVlJjS/ZAdYq+gxMmZT1gm MIrOQjJ1FkLHLCQds5B0LGBkWcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGE8Ht/w22MH4 8rnjIUYBDkYlHl4Dg0kRQqyJZcWVuYcYJTiYlUR4GSyBQrwpiZVVqUX58UWlOanFhxilOViU xHnNVt4PFxJITyxJzU5NLUgtgskycXBKNTCKmit2sAskfKqp6PpyWb0x5fTeeJnVAXtuz7ba p6jAPCVx3zrhst0LX2xgu7Jd/cfP/19jFRru7goqWc7Uu8dmts950bDcX/XO94062A/azBe4 elSxw7aMb5rh3YCkM9LP1+kcD/bLCVzacDfced6+1xyBlfcCnO51bChntv5z5veFC1MnXduv xFKckWioxVxUnAgA1DZ5BaMCAAA= Archived-At: Cc: Magnus Westerlund , "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:16:53 -0000 SGksDQoNCi4uLg0KDQo+SeKAmWQgbGlrZSB0byBoZWFyIGNvbW1lbnQgZnJvbSB0aGUgZm9sa3Mg d2hv4oCZdmUgYmVlbiBhcmd1aW5nIGluIGZhdm9yIG9mIFBULWJhc2VkID5tYXBwaW5nLCB0aG91 Z2guICAoSSBnZXQgdGhlIGZlZWxpbmcgdGhhdCBNYWdudXMgaXMgYWdyZWVpbmcgdG8gaXQgb25s eSBncnVkZ2luZ2x5LikNCg0KTXkgdW5kZXJzdGFuZGluZyBvZiBNYWdudXMnIHRleHQgaXMgdGhh dCwgYXQgYW55IGdpdmVuIHRpbWUsIHRoZXJlIHdpbGwgb25seSBiZSBPTkUgbWFwcGluZyBtZWNo YW5pc20uIFNvLCBpZiBlLmcsIE1JRCBpcyB1c2VkIGZvciBtYXBwaW5nLCBhbmQgdGhlIFJUUCBw YWNrZXQgaXMgbWFwcGVkIHRvIGFuIG0tIGxpbmUgZm9yIHdoaWNoIHRoZSBQVCB2YWx1ZSBoYXNu J3QgYmVlbiBkZWZpbmVkLCBpdCBzaG91bGQgYmUgdHJlYXRlZCBhcyBhbiBlcnJvci4NCg0KSSBk b24ndCB0aGluayBvbmUgc2hvdWxkICJzd2l0Y2giIHRvIGFub3RoZXIgbWFwcGluZyBtZWNoYW5p c20gYW5kIHNlZSB3aGV0aGVyIGFuIG0tIGxpbmUgZm9yIHRoYXQgUFQgaXMgZm91bmQuDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQo+IE9uIEZlYiAxLCAyMDE3LCBhdCAyOjQzIFBNLCBD aHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToN Cj4gDQo+IEhpLA0KPiANCj4+PiBJIGhhdmUgb25lIHF1ZXN0aW9uLCBob3dldmVyLiAgV2hhdCBz aG91bGQgaGFwcGVuIGlmIGFuIFJUUCBwYWNrZXQgDQo+Pj4gKHdpdGhvdXQgYSBNSUQpIGlzIHJl Y2VpdmVkIGZvciBhIHN0cmVhbSB0aGF0IGhhcyBhbiBleGlzdGluZyANCj4+PiBtYXBwaW5nIHRv IGFuIG09IGxpbmUsIGJ1dCB3aG9zZSBQVCBpcyBub3QgdmFsaWQgZm9yIHRoYXQgbT0gbGluZT8N Cj4gDQo+IEkgZG9uJ3QgdGhpbmsgdGhhdCBjYXNlIGlzIHNwZWNpZmljIHRvIEJVTkRMRSwgaXMg aXQ/IEl0IGNvdWxkIGhhcHBlbiBldmVuIHdpdGhvdXQgbXVsdGlwbGV4aW5nLg0KPiANCj4gSSBh Z3JlZSB3aXRoIE1hZ251cyB0aGF0IGl0IHNob3VsZCBiZSB0cmVhdGVkIGFzIGFuIGVycm9yLg0K PiANCj4gKFRoZXJlIGNvdWxkIGV2ZW4gYmUgY2FzZXMgd2hlcmUgdGhlIFBUIGlzbid0IHZhbGlk IGZvciBBTlkgbS0gbGluZSkuDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXINCg0K From nobody Wed Feb 1 12:19:18 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C6B1299D7; Wed, 1 Feb 2017 12:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 fXwSAkiOsIG8; Wed, 1 Feb 2017 12:19:04 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75121299A3; Wed, 1 Feb 2017 12:19:00 -0800 (PST) X-AuditID: c1b4fb2d-a87ff70000007e3d-eb-589242b194ef Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id E9.27.32317.1B242985; Wed, 1 Feb 2017 21:18:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0319.002; Wed, 1 Feb 2017 21:18:57 +0100 From: Christer Holmberg To: Alissa Cooper Thread-Topic: Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) Thread-Index: AQHSfLiANa/BcGrwW06zr+Sq61BcZKFUkZKA///z5ICAABGQgA== Date: Wed, 1 Feb 2017 20:18:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFD8EB8@ESESSMB209.ericsson.se> References: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFD8E04@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7je5mp0kRBpunCVtMP/OX0eLgxWWs Fu8v6FrM+DOR2eL8zvVMFlOXP2ZxYPOY8nsjq8eXJy+ZPJYs+ckUwBzFZZOSmpNZllqkb5fA lfGq8TpjQZtwxa5r7WwNjGf5uxg5OSQETCSuvv/N1sXIxSEksI5RYsXvJywQziJGifU7jzJ1 MXJwsAlYSHT/0wZpEBFQlbh67AdYA7PAJ0aJv/feMYMkhAXiJaZ82MsKUZQgcWZaCztIr4iA k0T7dxaQMIuAisStzY/BbF4BX4k7G+YyQ+w6wihx9fQXRpAEp4CdxIrbk8FsRgExie+n1jCB 2MwC4hK3nsxngrhaQGLJnvPMELaoxMvH/1ghbCWJxiVPWCHqdSQW7P7EBmFrSyxb+JoZYrGg xMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMLIO bvmtu4Nx9WvHQ4wCHIxKPLwGBpMihFgTy4orcw8xSnAwK4nwMlgChXhTEiurUovy44tKc1KL DzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamDM9/i6pfjyiWod7fKz3kkfr0Rdz7qT NfH6goVpjxdPnWNw2qfGounXnecan3/KOGyb58fV0ed3baqxnKbl2ffVH6WOl+bv9nns/PRN 0+ztu0rPaVt43jh8+u7+7fVhH+W3tPu5T5CcvqEhcoftmvSGi+t4Z5edlkyskZgpnKYw8emx XZ6vH6duUWIpzkg01GIuKk4EAGqBeoWoAgAA Archived-At: Cc: Flemming Andreasen , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-4572-update@ietf.org" , IESG , "mmusic@ietf.org" Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:19:17 -0000 Does anyone object to deleting the text? Martin? Ekr? Roman? Cullen? Regards, Christer -----Original Message----- From: Alissa Cooper [mailto:alissa@cooperw.in]=20 Sent: 01 February 2017 22:15 To: Christer Holmberg Cc: IESG ; draft-ietf-mmusic-4572-update@ietf.org; Flemming = Andreasen ; mmusic-chairs@ietf.org; mmusic@ietf.org Subject: Re: Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-= 12: (with COMMENT) > On Feb 1, 2017, at 3:04 PM, Christer Holmberg wrote: >=20 > Hi Alissa, >=20 > Thank you for your review! See below. >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >> Section 5.1 says: >>=20 >> "An endpoint MAY, in addition to its more preferred hash function, =20 >> also verify that each certificate used matches fingerprints =20 >> calculated using other hash functions. Unless there is a matching =20 >> fingerprint for each tested hash function, the endpoint MUST NOT =20 >> establish the TLS connection." >>=20 >> This seems a little weird to me. It's up to the endpoint to decide=20 >> whether to check for errors, and then if it does find an error it=20 >> can't setup the connection, whereas if it just hadn't checked it would b= e able to setup the connection. I think it would help to explain why an end= point would be motivated to check multiple fingerprints. >=20 > I think the only use-case that came up was a situation where the receiver= is not sure which hash function is the "strongest", and therefor checks mu= ltiple. However, it was also realized that with the multiple set of hash fu= nctions such situation is very unlikely to occur. >=20 > So, I could add the following note: >=20 > "NOTE: An endpoint might choose to match each used certificate against=20 > fingerprints calculated using multiple hash functions e.g, if the endpoin= t is unsure which hash function is the strongest." >=20 > ...or we could simply delete the text. I personally would go for that, bu= t in case others want to keep it I have no problem with that. It would make more sense to me to delete it but either solution would be an= improvement I think. Thanks, Alissa >=20 > Regards, >=20 > Christer >=20 >=20 From nobody Wed Feb 1 12:25:14 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADA21299A3; Wed, 1 Feb 2017 12:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=unavailable autolearn_force=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 cQnBWCL78cjY; Wed, 1 Feb 2017 12:25:08 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24701294F5; Wed, 1 Feb 2017 12:25:08 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v11KOwj4079417 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 1 Feb 2017 14:24:59 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Christer Holmberg" Date: Wed, 01 Feb 2017 14:24:58 -0600 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se> References: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , The IESG , "draft-ietf-mmusic-4572-update@ietf.org" Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:25:09 -0000 On 1 Feb 2017, at 14:04, Christer Holmberg wrote: > Hi Alissa, > > Thank you for your review! See below. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > >> Section 5.1 says: >> >> "An endpoint MAY, in addition to its more preferred hash function, >> also verify that each certificate used matches fingerprints >> calculated using other hash functions. Unless there is a matching >> fingerprint for each tested hash function, the endpoint MUST NOT >> establish the TLS connection." >> >> This seems a little weird to me. It's up to the endpoint to decide >> whether to check for errors, and then if it >> does find an error it can't setup the connection, whereas if it just >> hadn't checked it would be able to setup >> the connection. I think it would help to explain why an endpoint >> would be motivated to check multiple fingerprints. > > I think the only use-case that came up was a situation where the > receiver is not sure which hash function is the "strongest", and > therefor checks multiple. However, it was also realized that with the > multiple set of hash functions such situation is very unlikely to > occur. > > So, I could add the following note: > > "NOTE: An endpoint might choose to match each used certificate against > fingerprints calculated using multiple > hash functions e.g, if the endpoint is unsure which hash function is > the strongest." In retrospect, I have to question that motivation. Is it that hard to figure out? It seems like if you have two hash functions that are reasonably equal, an implementation could just pick one. > > ...or we could simply delete the text. I personally would go for that, > but in case others want to keep it I have no problem with that. Given that this has caused confusion at every step, I support removing the text. Thanks! Ben. From nobody Wed Feb 1 12:34:37 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4521299FC for ; Wed, 1 Feb 2017 12:34:32 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdi-XddlF4GX for ; Wed, 1 Feb 2017 12:34:30 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96941299EE for ; Wed, 1 Feb 2017 12:34:29 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id u68so74227958ywg.0 for ; Wed, 01 Feb 2017 12:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zdVVdQzUB4xG02qNJplt3ZS1G0OAxYtNOMdk4nYX+Do=; b=nCnZddQFf+q5KvqgxY09KEY/R+xN8P14rwN6GapaGfVcchvmry4fiXJeNrjTnk6Kge mY1h2cHadHezn3ksrOk1gT/YROKxlGsI3TczgKet0+Q+wBPfWqdMMUz54p2Bc82JjbzF jDl6vYvfNdtCrPG+ab9T/gTpO47cQF0qnBSkJF2dSPcA56S/eJRi49oglRdjV6lwQHZ/ IgfH6fC/CTfUveGmXLlT1/mltiCdEueUEU4yK3dn+VqxZRUanHl7uX2SckYY6RH9iVHU 6DdCp7EKeULD7UfeCuJB1RFoGulWP/zBfeUJ4CGrBgmL6+bpKxjD1lFdp8H+Hakg7sFR GUhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zdVVdQzUB4xG02qNJplt3ZS1G0OAxYtNOMdk4nYX+Do=; b=Z8RC9KMwMTT2WDIbWIH0pDQy9KH+OrNv/BiJgDvO/DHV7p0UecwBvvlQFe8zzCmrFJ pVp0JYyW2Ndce4sHu+FIfSA+w7im378OvcudCEgZn8nAwiG54/60+JcHFwD/4AzzbQDS jYu55gr2ZlYrfDwcjkkrLNU8h+NOgFsM4CjyN0kvjbw8tJbQeAZifvybK//VQhmRlvuv c00wTlubwkjJZDQSz9ybxVjMtaNjNwSDls1bjruDyf0V3LCWdwzvj3IOY/tRSBSb5n7B Gm7kFWpbnY5xyHMxKsVE0YX2sj/uXYmeBnTw9eVj6MQJrDK4qdzdvlQx64LXNqkG3lh6 djNQ== X-Gm-Message-State: AIkVDXJ1/9dwIPBpDzo4eE67OJF2IBLDT4gTVuE94Ijk8p1Z9A6ZHN0B7JoNe7kG1anGaQ== X-Received: by 10.55.5.11 with SMTP id 11mr4681653qkf.262.1485981268776; Wed, 01 Feb 2017 12:34:28 -0800 (PST) Received: from mail-qt0-f176.google.com (mail-qt0-f176.google.com. [209.85.216.176]) by smtp.gmail.com with ESMTPSA id a54sm19517871qta.48.2017.02.01.12.34.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 12:34:28 -0800 (PST) Received: by mail-qt0-f176.google.com with SMTP id x49so282985683qtc.2; Wed, 01 Feb 2017 12:34:27 -0800 (PST) X-Received: by 10.55.184.3 with SMTP id i3mr5018120qkf.234.1485981267747; Wed, 01 Feb 2017 12:34:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Wed, 1 Feb 2017 12:34:27 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFD8EB8@ESESSMB209.ericsson.se> References: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFD8EB8@ESESSMB209.ericsson.se> From: Roman Shpount Date: Wed, 1 Feb 2017 15:34:27 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c05d26a9b8e4705477df949 Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , Flemming Andreasen , IESG , "draft-ietf-mmusic-4572-update@ietf.org" Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:34:33 -0000 --94eb2c05d26a9b8e4705477df949 Content-Type: text/plain; charset=UTF-8 I am for removing the text. _____________ Roman Shpount On Wed, Feb 1, 2017 at 3:18 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Does anyone object to deleting the text? Martin? Ekr? Roman? Cullen? > > Regards, > > Christer > > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in] > Sent: 01 February 2017 22:15 > To: Christer Holmberg > Cc: IESG ; draft-ietf-mmusic-4572-update@ietf.org; > Flemming Andreasen ; mmusic-chairs@ietf.org; > mmusic@ietf.org > Subject: Re: Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: > (with COMMENT) > > > > On Feb 1, 2017, at 3:04 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > > Hi Alissa, > > > > Thank you for your review! See below. > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > >> Section 5.1 says: > >> > >> "An endpoint MAY, in addition to its more preferred hash function, > >> also verify that each certificate used matches fingerprints > >> calculated using other hash functions. Unless there is a matching > >> fingerprint for each tested hash function, the endpoint MUST NOT > >> establish the TLS connection." > >> > >> This seems a little weird to me. It's up to the endpoint to decide > >> whether to check for errors, and then if it does find an error it > >> can't setup the connection, whereas if it just hadn't checked it would > be able to setup the connection. I think it would help to explain why an > endpoint would be motivated to check multiple fingerprints. > > > > I think the only use-case that came up was a situation where the > receiver is not sure which hash function is the "strongest", and therefor > checks multiple. However, it was also realized that with the multiple set > of hash functions such situation is very unlikely to occur. > > > > So, I could add the following note: > > > > "NOTE: An endpoint might choose to match each used certificate against > > fingerprints calculated using multiple hash functions e.g, if the > endpoint is unsure which hash function is the strongest." > > > > ...or we could simply delete the text. I personally would go for that, > but in case others want to keep it I have no problem with that. > > It would make more sense to me to delete it but either solution would be > an improvement I think. > > Thanks, > Alissa > > > > > Regards, > > > > Christer > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c05d26a9b8e4705477df949 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am for removing the text.=C2=A0

_____________
Roman Shpount

On Wed, Feb 1, 2017 at 3:18 PM, Christer Hol= mberg <christer.holmberg@ericsson.com> wrote:
Does anyone object to deleting the text? M= artin? Ekr? Roman? Cullen?

Regards,

Christer

-----Original Message-----
From: Alissa Cooper [mailto:alissa@coo= perw.in]
Sent: 01 February 2017 22:15
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: IESG <iesg@ietf.org>; draft-ietf-mmusic-4572-= update@ietf.org; Flemming Andreasen <fandreas@cisco.com>; mmusic-chairs@ietf.org; mmusi= c@ietf.org
Subject: Re: Alissa Cooper's No Objection on draft-ietf-mmusic-4572-upd= ate-12: (with COMMENT)


> On Feb 1, 2017, at 3:04 PM, Christer Holmberg <christer.holmberg@ericsson.com> w= rote:
>
> Hi Alissa,
>
> Thank you for your review! See below.
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
>> Section 5.1 says:
>>
>> "An endpoint MAY, in addition to its more preferred hash func= tion,
>> also verify that each certificate used matches fingerprints
>> calculated using other hash functions.=C2=A0 Unless there is a mat= ching
>> fingerprint for each tested hash function, the endpoint MUST NOT >> establish the TLS connection."
>>
>> This seems a little weird to me. It's up to the endpoint to de= cide
>> whether to check for errors, and then if it does find an error it<= br> >> can't setup the connection, whereas if it just hadn't chec= ked it would be able to setup the connection. I think it would help to expl= ain why an endpoint would be motivated to check multiple fingerprints.
>
> I think the only use-case that came up was a situation where the recei= ver is not sure which hash function is the "strongest", and there= for checks multiple. However, it was also realized that with the multiple s= et of hash functions such situation is very unlikely to occur.
>
> So, I could add the following note:
>
> "NOTE: An endpoint might choose to match each used certificate ag= ainst
> fingerprints calculated using multiple hash functions e.g, if the endp= oint is unsure which hash function is the strongest."
>
> ...or we could simply delete the text. I personally would go for that,= but in case others want to keep it I have no problem with that.

It would make more sense to me to delete it but either solution would be an= improvement I think.

Thanks,
Alissa

>
> Regards,
>
> Christer
>
>

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

--94eb2c05d26a9b8e4705477df949-- From nobody Wed Feb 1 12:35:39 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C4F1299F0 for ; Wed, 1 Feb 2017 12:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpPPUw30jZW7 for ; Wed, 1 Feb 2017 12:35:36 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B813A1299EE for ; Wed, 1 Feb 2017 12:35:36 -0800 (PST) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-04v.sys.comcast.net with SMTP id Z1boc2hjA75mkZ1ctcbxLA; Wed, 01 Feb 2017 20:35:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485981335; bh=VBQbTjhbIRns+m4SVUxyaFdpS/R0BqGeD9OH+/4dxKE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=UlZOQUGTyvCBKQkJv0032GxtGqGxS8jDneLL0h+hiXYlXvb7zinXrkYge+lfPC69C SZvcPYE1kzH2oPIbcogLOME6rNe5L071PmTufApqhF0Zp0427HrsWtHRU8fW7wAT6S ViN9D+oXZuo9ujIUd3rJLmW9a3+vo503ZIlp6lnB2sCYi9xbCPaRftY4reR3xp+y2t G9CVsjtMaDAWXY0GJ6ATWvrSzpM7Q4N8X127lsBrLxWnbxvKlOPynDJMJFZQ94km29 MpRWXCp5tun0aAiIi+zYeg6uqzYTmNWgGMHfzTHZ9qIeCnXppS5+/mkTMjigYtLwXU c5yamYJiVRaMg== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-02v.sys.comcast.net with SMTP id Z1cscVmWhk3bxZ1ctcPuCK; Wed, 01 Feb 2017 20:35:35 +0000 To: mmusic@ietf.org References: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <22b63f2b-5f73-bca2-09b1-6c983126d21f@comcast.net> Date: Wed, 1 Feb 2017 15:35:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfLdd5bch53Xzf2nD0MdfGdEHkbLBUc0F67NIw0aMd06eciePPU5kx9JDqeqRkFvkNNg4wM+VdAILlGqhbkVU6A10LQFtjZSxlYgOLF73WEy4ihViu8hU 9bssjfvKkPtV9L3AXyIJ56Ek53Rm6BdSfLOBr/jf2g2Kwms+WDstZearZ7sKELQ4lejbyHhERisytg== Archived-At: Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:35:38 -0000 On 2/1/17 3:24 PM, Ben Campbell wrote: > On 1 Feb 2017, at 14:04, Christer Holmberg wrote: > >> Hi Alissa, >> >> Thank you for your review! See below. >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >>> Section 5.1 says: >>> >>> "An endpoint MAY, in addition to its more preferred hash function, >>> also verify that each certificate used matches fingerprints >>> calculated using other hash functions. Unless there is a matching >>> fingerprint for each tested hash function, the endpoint MUST NOT >>> establish the TLS connection." >>> >>> This seems a little weird to me. It's up to the endpoint to decide >>> whether to check for errors, and then if it >>> does find an error it can't setup the connection, whereas if it just >>> hadn't checked it would be able to setup >>> the connection. I think it would help to explain why an endpoint >>> would be motivated to check multiple fingerprints. >> >> I think the only use-case that came up was a situation where the >> receiver is not sure which hash function is the "strongest", and >> therefor checks multiple. However, it was also realized that with the >> multiple set of hash functions such situation is very unlikely to occur. >> >> So, I could add the following note: >> >> "NOTE: An endpoint might choose to match each used certificate against >> fingerprints calculated using multiple >> hash functions e.g, if the endpoint is unsure which hash function is >> the strongest." > > In retrospect, I have to question that motivation. Is it that hard to > figure out? It seems like if you have two hash functions that are > reasonably equal, an implementation could just pick one. > >> >> ...or we could simply delete the text. I personally would go for that, >> but in case others want to keep it I have no problem with that. > > Given that this has caused confusion at every step, I support removing > the text. ISTM that the main point here is: *if* the recipient happens to check more than one hash, a failure of any one of them is to be considered an overall failure, rather than a success of one and a failure of another being considered a success. Perhaps that ought to be obvious, but I have long since given up giving the benefit of the doubt on obviousness. Thanks, Paul From nobody Wed Feb 1 12:42:40 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A901299ED; Wed, 1 Feb 2017 12:42:39 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RT_x7jpCiU-B; Wed, 1 Feb 2017 12:42:22 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0ECD129431; Wed, 1 Feb 2017 12:42:22 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id 204so112036418pge.0; Wed, 01 Feb 2017 12:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w7cS+1GDgMHYsT7OBaQLNm8prQhFfWbbbG95E8JQr+c=; b=U8zWFtjPoMjq1lhnzylD2tntTNqcEx4X6MZo19F/6tPOXLO6mNfbN2HSAOeZLXIcsL xsNL133fGNmd6FihKliZNdV5imVpoTV4YUp1Wr+ArcAlL13UrXnDITBgBJpdbF3y4dtA zeqEjnEBjywTUJYSV0Yn0r3QjfAn7YUDvz6643RjjV0HPEG4pladZeJVq1v2lRew7hYU KghbjVpOzA78t7LJ0Ot+UAqi8/LFkYFX5wjZJruciFJU8huGegUzl/UFf2X7KxPNqI+J yhMlTPJqmGDgr05ORyBUDpydeQPr6KhKrZ0mU4pKd0G5OGW0EiisDFVcvncBKBjrNkU2 t9jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w7cS+1GDgMHYsT7OBaQLNm8prQhFfWbbbG95E8JQr+c=; b=bHFN7wXVwsNkoxvZUXOPgU/JZi45Vepwltr/odFRdFOdQ12yIVuwEI9v/0NzIXZujX hV9iAwRutX7er7vmnGIWbNUO1fyPQLFPrKc0+GZ9xpNDExrY5YK04qUurIvAyOcwvmgY qZwoJOjQ//Iq+84vx4E9NcWCmX0yYX54KfAnVbu/feOVoGwFBnVCn/uOPibwptVop4mQ 2B04vVzzkuzrq3ByrQ9dgl6/sx+E/vrCLnoHjxaZCuwhVfmPtbAC6B3swI2ASWVhqbd/ GYjgf5uM6niScAzw/8sW1ls8jy46xRPq36p1SgsItMkFCTPQEzmaqlnUfmkaxvmgEOz9 1Frw== X-Gm-Message-State: AIkVDXJVopAt/X4k6OKYAkzyoR8FysD1NZ7ERI0m9DQtXuoN6Q5f5jP6eGFR0kxfAZTsbA== X-Received: by 10.99.213.81 with SMTP id v17mr6111745pgi.130.1485981741913; Wed, 01 Feb 2017 12:42:21 -0800 (PST) Received: from [192.168.0.166] (71-212-77-30.tukw.qwest.net. [71.212.77.30]) by smtp.gmail.com with ESMTPSA id c11sm51933302pfk.14.2017.02.01.12.42.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 12:42:21 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (14D27) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFD8C88@ESESSMB209.ericsson.se> Date: Wed, 1 Feb 2017 12:41:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BFD8C88@ESESSMB209.ericsson.se> To: Christer Holmberg Archived-At: Cc: Magnus Westerlund , mmusic , Jonathan Lennox , "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:42:39 -0000 *Any* RTP packet routed to an m-line needs to have a PT field that is valid f= or that m-line. This is true whether the routing was done via MID match, SSR= C match or PT match.=20 Also, Magnus mentioned a case where a BYE is received for an SSRC then subse= quently the SSRC is reused, potentially with a new MID and/or PT. Does the proposed text handle this? I do not think so. SSRC entries that are= "latched" need to be removed when a BYE is received. > On Feb 1, 2017, at 11:43 AM, Christer Holmberg wrote: >=20 > Hi, >=20 >>> I have one question, however. What should happen if an RTP packet=20 >>> (without a MID) is received for a stream that has an existing mapping=20= >>> to an m=3D line, but whose PT is not valid for that m=3D line? >=20 > I don't think that case is specific to BUNDLE, is it? It could happen even= without multiplexing. >=20 > I agree with Magnus that it should be treated as an error. >=20 > (There could even be cases where the PT isn't valid for ANY m- line). >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Feb 1 13:46:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDC712957E; Wed, 1 Feb 2017 13:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 yhfR941azJBF; Wed, 1 Feb 2017 13:46:34 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 960591295AA; Wed, 1 Feb 2017 13:46:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 065242D299; Wed, 1 Feb 2017 23:46:28 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpgY86z-195W; Wed, 1 Feb 2017 23:46:27 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 14B8A2CC9B; Wed, 1 Feb 2017 23:46:27 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6BDC5AD5-E9D4-44F3-AD23-01DB3D80A052"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFC08AC@ESESSMB209.ericsson.se> Date: Wed, 1 Feb 2017 22:46:25 +0100 Message-Id: <80FA28DD-1CEE-44B0-B14C-AA991B5AB4CE@piuha.net> References: <7594FB04B1934943A5C02806D1A2204B4BFC08AC@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "draft-ietf-mmusic-4572-update.all@ietf.org" , "gen-art@ietf.org" , Elwyn Davies , "ietf@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [Gen-art] Review of draft-ietf-mmusic-4572-update-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 21:46:40 -0000 --Apple-Mail=_6BDC5AD5-E9D4-44F3-AD23-01DB3D80A052 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Elwyn, Christer =97 many thanks for the in-depth review and updates. I have posted a =93no objection=94 position for this document for = tomorrow=92s IESG telechat. Jari --Apple-Mail=_6BDC5AD5-E9D4-44F3-AD23-01DB3D80A052 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYklcxAAoJEM80gCTQU46qCecQAKTTljd03QyNy67KotiAfIvD yyaAnNThfefM4/XhMpxXvYrHPEcHwBVJ87mWPOr0RAiIqAYJEhCgNyH1MXGT1Bkw LZ+2m4xrxoX2U0e1WliLdCJIRgev5i/YIefJ3Q7XnESZfqSgUzzZhyLtTCoqPjf8 19YNuc+/0c/RqeOna8kPyGXB1+HkS/zF2v8or211eQUwuoqHBK9IYji2w3ZvRl1B QeKLvmUmOUecvYtzZK4i1M6FHsj7atsKBfa3+JTgfjBXwqnFr84bKl9IimhGXKVr yCzDhAb+qJwUhRAQC2v4fuVGsfazfL83eJ0ajBj3MLWv3WjNzIkenZWmUoVIxKP8 Osc0HAu5K2/uuzwFxibTuAeV/D+9BBIbQ3OrUimowp1i645cFusOwJNNgsTixAAf EuywN1QeBh6MHr8xbwUZ69lL7uJ2LDSB0+pCB5HDDyp84UK0TkYq8qHx3PUT4g2W QbQ1DZgT2IHj1nBPwHbyxdWeoneyBY60l/YLveGUHSvvJIK2kyAxKorvupbHEXAT mEDBmg+uSIpjjuL5J+sCv3xUU++9IuDOU010w4UmMsVyg2ka+WYeb2JD+BPLBWrQ bAY6noNNn05Zl4APYG64lPiHbrwA6ZPrWZMRtV5HPsMFdhilJkJZdCEnjQLNav+M YbfKInfJ2sSJwWDi5W8s =jIAc -----END PGP SIGNATURE----- --Apple-Mail=_6BDC5AD5-E9D4-44F3-AD23-01DB3D80A052-- From nobody Thu Feb 2 00:29:25 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A447F1293F2 for ; Thu, 2 Feb 2017 00:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 zOXXOi52VqPQ for ; Thu, 2 Feb 2017 00:29:23 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB9B128AB0 for ; Thu, 2 Feb 2017 00:29:23 -0800 (PST) X-AuditID: c1b4fb2d-e76b398000007e3d-55-5892ede1d482 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id 85.F1.32317.1EDE2985; Thu, 2 Feb 2017 09:29:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0319.002; Thu, 2 Feb 2017 09:28:17 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) Thread-Index: AQHSfLiANa/BcGrwW06zr+Sq61BcZKFUkZKA///2vACAAAL3AIAA6SoA Date: Thu, 2 Feb 2017 08:28:17 +0000 Message-ID: References: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se> <22b63f2b-5f73-bca2-09b1-6c983126d21f@comcast.net> In-Reply-To: <22b63f2b-5f73-bca2-09b1-6c983126d21f@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9D586B9C21211843AB2A61A8B6A1E5D8@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7se7Dt5MiDI7f1bKYuvwxi8WDH71s Dkwekx/PYfRYsuQnUwBTFJdNSmpOZllqkb5dAlfGvh1djAWzhCtmvlvD1MC4i7+LkZNDQsBE YsuXJrYuRi4OIYF1jBLXp82FchYxSrw73craxcjBwSZgIdH9TxukQUQgSGJu4xcmEFtYIEPi TFc/G0Q8U+Ll6a8sELabxK5VbYwgNouAikTb56nMIDavgLXElPNXoeb/YpSYeaKFHSTBKWAv sfTwK1YQm1FATOL7qTVgC5gFxCVuPZnPBHGpgMSSPeeZIWxRiZeP/4HViwroSSx/voYZ5E4J AUWJ5f1yEK16EjemTmGDsK0lJl28zAhha0ssW/ga6h5BiZMzn7BMYBSbhWTbLCTts5C0z0LS PgtJ+wJG1lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgXF1cMtv3R2Mq187HmIU4GBU4uE1 MJgUIcSaWFZcmXuIUYKDWUmE1+AFUIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6Ykl qdmpqQWpRTBZJg5OqQbGvBjnmKh5n+Z6cH56/ypTN6LXkMHbe+UEWe32A6f1ef6XSBycrz5P SK2PIe3qlA25V/WPP05xCHjTaXyvq20hh+BN4xV91ttftp/kYe/hr5yd4dXoWuL8p5SXTVd/ 5+JSk7Lyi4nhhpaBxc0RjY9zNk6TcNsaK7r5i6FlXvyy/MT9bEnPc5VYijMSDbWYi4oTAUQU L9+nAgAA Archived-At: Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 08:29:25 -0000 Hi Paul, >>>---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>>> Section 5.1 says: >>>> >>>> "An endpoint MAY, in addition to its more preferred hash function, >>>> also verify that each certificate used matches fingerprints >>>> calculated using other hash functions. Unless there is a matching >>>> fingerprint for each tested hash function, the endpoint MUST NOT >>>> establish the TLS connection." >>>> >>>> This seems a little weird to me. It's up to the endpoint to decide >>>> whether to check for errors, and then if it >>>> does find an error it can't setup the connection, whereas if it just >>>> hadn't checked it would be able to setup >>>> the connection. I think it would help to explain why an endpoint >>>> would be motivated to check multiple fingerprints. >>> >>> I think the only use-case that came up was a situation where the >>> receiver is not sure which hash function is the "strongest", and >>> therefor checks multiple. However, it was also realized that with the >>> multiple set of hash functions such situation is very unlikely to >>>occur. >>> >>> So, I could add the following note: >>> >>> "NOTE: An endpoint might choose to match each used certificate against >>> fingerprints calculated using multiple >>> hash functions e.g, if the endpoint is unsure which hash function is >>> the strongest." >> >> In retrospect, I have to question that motivation. Is it that hard to >> figure out? It seems like if you have two hash functions that are >> reasonably equal, an implementation could just pick one. >> >>> >>> ...or we could simply delete the text. I personally would go for that, >>> but in case others want to keep it I have no problem with that. >> >> Given that this has caused confusion at every step, I support removing >> the text. > >ISTM that the main point here is: *if* the recipient happens to check >more than one hash, a failure of any one of them is to be considered an >overall failure, rather than a success of one and a failure of another >being considered a success. The question was WHY an endpoint would check more than one hash function to begin with, and the only reason we have came up with is if the endpoint doesn=B9t =B3know" which is the strongest hash - which sounds a little weir= d. Regards, Christer From nobody Thu Feb 2 01:25:57 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519801293E8; Thu, 2 Feb 2017 01:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 gQpBd6Mylrrf; Thu, 2 Feb 2017 01:25:52 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7351289B0; Thu, 2 Feb 2017 01:25:51 -0800 (PST) X-AuditID: c1b4fb25-5ba3c980000036c9-45-5892fb1db71e Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 79.B2.14025.D1BF2985; Thu, 2 Feb 2017 10:25:49 +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.3.319.2; Thu, 2 Feb 2017 10:25:48 +0100 To: Jonathan Lennox References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> From: Magnus Westerlund Message-ID: Date: Thu, 2 Feb 2017 10:25:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM2K7pa7s70kRBi9aVS2mz3rHZjG/Yx2b xf7F55ktpi5/zGKx9l87uwOrx5IlP5k8vlz+zObR9uwOewBzFJdNSmpOZllqkb5dAldG98KD LAWT+So6n+xmbmBcw93FyMkhIWAi8eX6ObYuRi4OIYF1jBKrP61ihXCWMUqs2X+UBaRKWKBI 4sDLNmYQW0RAQ+Lisw9QHbcZJc63LGQHcZgFmpkk7uyewg5SxSZgIXHzRyMbiM0rYC9xtO0D K4jNIqAi8W5PGxOILSoQI/FyzyoWiBpBiZMzn4DZnAK2El/+rADq5QAaai/xYGsZSJhZQF6i eetssCOEBLQlGpo6WCcwCsxC0j0LoWMWko4FjMyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2 MQID+OCW36o7GC+/cTzEKMDBqMTDa2AwKUKINbGsuDL3EKMEB7OSCG/wN6AQb0piZVVqUX58 UWlOavEhRmkOFiVxXrOV98OFBNITS1KzU1MLUotgskwcnFINjK5aR+e8ONO160aZ2eIros8v OBdfmxi4W91o9ru1/rcZ1Zt0HK97b7V13TaTY3e/uctrG+FwUy5BvTuHb/D6/WWoXzzxm/TH xcZVtj8UDRuVN71vOJZy57nyHrkPNeyx+qa9m0RMvJlZGw4I80g+Pmml+tf88+nbTfOebDJY l/z14vtXKhWvJymxFGckGmoxFxUnAgCpdWq1XAIAAA== Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 09:25:53 -0000 Den 2017-02-01 kl. 21:02, skrev Jonathan Lennox: > >> On Feb 1, 2017, at 10:21 AM, Magnus Westerlund >> wrote: >> We also noted that BUNDLE should clarify how MID relates to a=ssrc >> (RFC5576). My interpretation is that a=ssrc locks a RTP stream to a >> particular m= line, and can't be moved. So any MID value other than >> that matches the m= line that has the a=ssrc value would be an >> error case. For usages that intend to have a RTP stream to bounce >> between m= lines should not use a=ssrc, only MID. I think it would >> be good to clarify this in the BUNDLE specification. > > That seems reasonable, but it’s not what your proposed algorithm > does, as far as I can tell. Receiving a MID for a different m= line > moves the source, regardless of how the source initially ended up > associated. > No, this was something that was realized in the discussion that I had with Bo after your question. And, I think a possible way to realize this is to add to the entries in the table RTP stream to "m=" line a property "set by a=ssrc" that makes the entry immutable, with the exception for SDP signalling updates. That way one can also handle if RTCP BYE should after a timeout remove the entry from this table, which is what Bernard asked about. 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 2 01:29:33 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1815A1293E8; Thu, 2 Feb 2017 01:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 LJDB4HqdV21J; Thu, 2 Feb 2017 01:29:31 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21231289B0; Thu, 2 Feb 2017 01:29:30 -0800 (PST) X-AuditID: c1b4fb25-5ba3c980000036c9-8b-5892fbf8e967 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 34.73.14025.8FBF2985; Thu, 2 Feb 2017 10:29: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.3.319.2; Thu, 2 Feb 2017 10:29:26 +0100 To: Bernard Aboba , Christer Holmberg References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BFD8C88@ESESSMB209.ericsson.se> From: Magnus Westerlund Message-ID: <80fb40bf-4625-39c7-4806-9442c71937e8@ericsson.com> Date: Thu, 2 Feb 2017 10:29:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM2J7oO7P35MiDB5s57TYsO8/s8X0We/Y LOZ3rGOz2L/4PLPF1OWPWSzW/mtnd2Dz2DnrLrvHkiU/mTy+XP7M5tH27A57AEsUl01Kak5m WWqRvl0CV8bzNwtZCw5yV9x9n9PAOJuzi5GTQ0LAROL8zvWMILaQwDpGibbv/l2MXED2MkaJ De8WM4MkhAWqJTbM/skEYosIJEqsmP6BGaJhPpNE3y8fkAZmgZVMEm/2PmQBSbAJWEjc/NHI BmLzCthLbNl2hh3EZhFQkdj4cTvYIFGBGImXe1axQNQISpyc+QTM5hSwlVi5fjLQRRxAQ+0l HmwtAwkzC8hLNG+dDbVXW6KhqYN1AqPALCTdsxA6ZiHpWMDIvIpRtDi1OCk33chYL7UoM7m4 OD9PLy+1ZBMjMJwPbvmtuoPx8hvHQ4wCHIxKPLwGBpMihFgTy4orcw8xSnAwK4nwcgKjQYg3 JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQbG4iyv2qx4lraF 7G62IjaLi7y/lxglxG2ICUlbe+btdSGLx9sXLJ9/fsPGUyYb8j9pOda3G2XN1W/aqKTw+cdN i6z+4IkeWmeUk8Q/2+zaEWtttOgpl3JLjaZHp9HfcI+G681TnfaGJlvWfuyUdJPmqJiwJzjh uLFA6KQLz55KXc+zOOO0uVyJpTgj0VCLuag4EQCQBALeYwIAAA== Archived-At: Cc: Jonathan Lennox , "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 09:29:32 -0000 Den 2017-02-01 kl. 21:41, skrev Bernard Aboba: > *Any* RTP packet routed to an m-line needs to have a PT field that is > valid for that m-line. This is true whether the routing was done via > MID match, SSRC match or PT match. Agreed. > > Also, Magnus mentioned a case where a BYE is received for an SSRC > then subsequently the SSRC is reused, potentially with a new MID > and/or PT. > > Does the proposed text handle this? I do not think so. SSRC entries > that are "latched" need to be removed when a BYE is received. > Yes, that is not covered here. I think this could be clarified. There needs to exist a timeout before the entry is actually removed, to avoid rebinding in case of packet re-order. Thus the regular SSRC timeout should be sufficient for this, i.e. 5*Td (using timeout mins). However, I think also this case needs to consider a=ssrc. If a=ssrc is set, then the RTP stream to m= line mapping is maintained, until signalling change. 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 2 03:43:26 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87C4129633; Thu, 2 Feb 2017 03:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 PXvt8g6oGISD; Thu, 2 Feb 2017 03:43:21 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ECA9129629; Thu, 2 Feb 2017 03:43:20 -0800 (PST) X-AuditID: c1b4fb25-1cbff700000036c9-e5-58931b55929e Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 69.83.14025.55B13985; Thu, 2 Feb 2017 12:43:18 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0319.002; Thu, 2 Feb 2017 12:43:17 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) Thread-Index: AQHSfLiANa/BcGrwW06zr+Sq61BcZKFUkZKA///z5ICAABGQgP//8++AgAEf9IA= Date: Thu, 2 Feb 2017 11:43:17 +0000 Message-ID: References: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFD8EB8@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D4B8E82017487christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUyM2J7oG6Y9OQIg+azOhbTz/xltDh4cRmr xfsLuhYz/kxktji/cz2TxdTlj1ksZlyYyuzA7jHl90ZWjy9PXjJ5LFnyk8nj1pSCAJYoLpuU 1JzMstQifbsEroy1j9cyFiyOqGhsf8/WwPjNp4uRk0NCwERiV98SNhBbSGAdo8T5fRpdjFxA 9iJGia3bn7J3MXJwsAlYSHT/0wapERFQlfj7fTITSA2zwHQmiXXvvoM1CwtkSJzp6meDKMqU eHn6KwuE7Sdx6i5IAycHi4CKxJzGbkYQm1fAWuLTz5fMEIvPM0mc35IJYnMKBEqsPnQdrJ5R QEzi+6k1YDazgLjErSfzmSCOFpBYsuc8M4QtKvHy8T9WEFtUQE9i+fM1UHFFiavTlzOB3M8s kCCxdU4QxFpBiZMzn7BMYBSdhWTqLISqWUiqIEp0JBbs/sQGYWtLLFv4mhnGPnPgMROEbS3x 5kwrE7KaBYwcqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECo/jglt+qOxgvv3E8xCjAwajE w2tgMClCiDWxrLgy9xCjBAezkghvkcTkCCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8ZivvhwsJ pCeWpGanphakFsFkmTg4pRoY2SZll/xQ/l/HNj/e/4BV+ZX+L9FfdS+drO8vFl3Wd9f4mqoN 06xjm0Ludx298FVlWpOWyamFa86nMz9ZYbfhsnlq3U9Jtiw+tRtWqyoetj0yFrhy+BfXel6L O9sedybaf0sI92pIDmY9zcDl6u26SHf2r7rzebfb3nkXPQ/ozc26+2j+m0vsSizFGYmGWsxF xYkAaFWyQt4CAAA= Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , Flemming Andreasen , IESG , "draft-ietf-mmusic-4572-update@ietf.org" Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 11:43:24 -0000 --_000_D4B8E82017487christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Ok, it seems like there is stronger preference for removing the text, and n= obody has objected. So, I will remove the text in the next version of the document. Regards, Christer From: Roman Shpount > Date: Wednesday 1 February 2017 at 22:34 To: Christer Holmberg > Cc: "alissa@cooperw.in" >, Flemming Andreasen >, "mmusic-chairs@ietf.org" >, "draft-ietf-mmusic-457= 2-update@ietf.org" >, "iesg@ietf.org" >, "mmusic@ietf.org" > Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-457= 2-update-12: (with COMMENT) I am for removing the text. _____________ Roman Shpount On Wed, Feb 1, 2017 at 3:18 PM, Christer Holmberg > wrote: Does anyone object to deleting the text? Martin? Ekr? Roman? Cullen? Regards, Christer -----Original Message----- From: Alissa Cooper [mailto:alissa@cooperw.in] Sent: 01 February 2017 22:15 To: Christer Holmberg > Cc: IESG >; draft-ietf-mmusic-4572-upda= te@ietf.org; Flemming Andrea= sen >; mmusic-chairs@ietf.org= ; mmusic@ietf.org Subject: Re: Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-= 12: (with COMMENT) > On Feb 1, 2017, at 3:04 PM, Christer Holmberg > wrote: > > Hi Alissa, > > Thank you for your review! See below. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > >> Section 5.1 says: >> >> "An endpoint MAY, in addition to its more preferred hash function, >> also verify that each certificate used matches fingerprints >> calculated using other hash functions. Unless there is a matching >> fingerprint for each tested hash function, the endpoint MUST NOT >> establish the TLS connection." >> >> This seems a little weird to me. It's up to the endpoint to decide >> whether to check for errors, and then if it does find an error it >> can't setup the connection, whereas if it just hadn't checked it would b= e able to setup the connection. I think it would help to explain why an end= point would be motivated to check multiple fingerprints. > > I think the only use-case that came up was a situation where the receiver= is not sure which hash function is the "strongest", and therefor checks mu= ltiple. However, it was also realized that with the multiple set of hash fu= nctions such situation is very unlikely to occur. > > So, I could add the following note: > > "NOTE: An endpoint might choose to match each used certificate against > fingerprints calculated using multiple hash functions e.g, if the endpoin= t is unsure which hash function is the strongest." > > ...or we could simply delete the text. I personally would go for that, bu= t in case others want to keep it I have no problem with that. It would make more sense to me to delete it but either solution would be an= improvement I think. Thanks, Alissa > > Regards, > > Christer > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_D4B8E82017487christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Ok, it seems like there is stronger preference for removing the text, = and nobody has objected.

So, I will remove the text in the next version of the document.

Regards,

Christer

From: Roman Shpount <roman@telurix.com>
Date: Wednesday 1 February 2017 at = 22:34
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "alissa@cooperw.in" <alissa@cooperw.in>, Flemming Andreasen <fandreas@cisco.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org&g= t;, "draft-i= etf-mmusic-4572-update@ietf.org" <draft-ietf-mmusic-4572-update@ietf.org>= , "iesg@ietf.org" <iesg@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Alissa Cooper= 's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT)

I am for removing the text. 

_________= ____
Roman Shpount

On Wed, Feb 1, 2017 at 3:18 PM, Christer Holmber= g <chr= ister.holmberg@ericsson.com> wrote:
Does anyone object to deleting the text? Martin? Ekr? Roman? Cullen?

Regards,

Christer

-----Original Message-----
From: Alissa Cooper [mailto:alissa@coo= perw.in]
Sent: 01 February 2017 22:15
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: IESG <iesg@ietf.org>; draft-ietf-mmusic-4572-update@ietf.org; Flemming Andreasen <fandreas@cisco.com>; mmusic-chairs@ietf.org; mmusic@ietf.org
Subject: Re: Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-= 12: (with COMMENT)


> On Feb 1, 2017, at 3:04 PM, Christer Holmberg <christer.holmberg@ericsson.com> w= rote:
>
> Hi Alissa,
>
> Thank you for your review! See below.
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
>> Section 5.1 says:
>>
>> "An endpoint MAY, in addition to its more preferred hash func= tion,
>> also verify that each certificate used matches fingerprints
>> calculated using other hash functions.  Unless there is a mat= ching
>> fingerprint for each tested hash function, the endpoint MUST NOT >> establish the TLS connection."
>>
>> This seems a little weird to me. It's up to the endpoint to decide=
>> whether to check for errors, and then if it does find an error it<= br> >> can't setup the connection, whereas if it just hadn't checked it w= ould be able to setup the connection. I think it would help to explain why = an endpoint would be motivated to check multiple fingerprints.
>
> I think the only use-case that came up was a situation where the recei= ver is not sure which hash function is the "strongest", and there= for checks multiple. However, it was also realized that with the multiple s= et of hash functions such situation is very unlikely to occur.
>
> So, I could add the following note:
>
> "NOTE: An endpoint might choose to match each used certificate ag= ainst
> fingerprints calculated using multiple hash functions e.g, if the endp= oint is unsure which hash function is the strongest."
>
> ...or we could simply delete the text. I personally would go for that,= but in case others want to keep it I have no problem with that.

It would make more sense to me to delete it but either solution would be an= improvement I think.

Thanks,
Alissa

>
> Regards,
>
> Christer
>
>

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

--_000_D4B8E82017487christerholmbergericssoncom_-- From nobody Thu Feb 2 04:49:34 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7BB12940E; Thu, 2 Feb 2017 04:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 rn3I4VPqOGDH; Thu, 2 Feb 2017 04:49:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34592129400; Thu, 2 Feb 2017 04:49:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFR17800; Thu, 02 Feb 2017 12:49:19 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 2 Feb 2017 12:49:18 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0301.000; Thu, 2 Feb 2017 20:49:12 +0800 From: Roni Even To: Magnus Westerlund , "mmusic (E-mail)" , "rtcweb@ietf.org" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" , "draft-ietf-rtcweb-jsep@tools.ietf.org" Thread-Topic: [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSeLyNdlGsubKC20y06tuA5xxgmqFVs8jg Date: Thu, 2 Feb 2017 12:49:12 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7716D7@DGGEMM506-MBX.china.huawei.com> References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> In-Reply-To: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58932AD0.037F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 359c90da364523be5d4230b6c7375327 Archived-At: Subject: Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 12:49:27 -0000 SGkgTWFnbnVzLA0KSXMgdGhlcmUgYSBuZWVkIHRvIHNwZWNpZnkgdGhlIG1hcHBpbmcgZm9yIHRo ZSBzaW11bGNhc3QgY2FzZSB3aGVyZSB0aGUgcmlkIGlkZW50aWZ5IHRoZSBtYXBwaW5nIGluIHRo ZSBtLWxpbmU/DQpSb25pDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog cnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYWdu dXMNCj4gV2VzdGVybHVuZA0KPiBTZW50OiDXmdeV153CoNeVIDI3INeZ16DXldeQ16ggMjAxNyAx ODo0Mw0KPiBUbzogbW11c2ljIChFLW1haWwpOyBydGN3ZWJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt bW11c2ljLXNkcC1idW5kbGUtDQo+IG5lZ290aWF0aW9uQGlldGYub3JnOyBkcmFmdC1pZXRmLXJ0 Y3dlYi1qc2VwQHRvb2xzLmlldGYub3JnDQo+IFN1YmplY3Q6IFtydGN3ZWJdIFRleHQgcHJvcG9z YWwgZm9yIEJ1bmRsZSByZWdhcmRpbmcgQXNzb2NpYXRpbmcgUlRQL1JUQ1ANCj4gV2l0aCBDb3Jy ZWN0IFNEUCBNZWRpYSBEZXNjcmlwdGlvbg0KPiANCj4gTU1VU0lDIGFuZCBSVENXRUIsDQo+IA0K PiBIZXJlIGlzIG5vdyBhIG1vcmUgY29tcGxldGUgdGV4dCBwcm9wb3NhbCB0aGF0IGFsc28gY29u c2lkZXJzIHRoZSBSVENQLg0KPiBJdCBhbHNvIGdvZXMgZnVydGhlciB0aGFuIHdoYXQgQXBwZW5k aXggQiBkZWZpbmVzIGluIG9uZSBhc3BlY3QsIG5hbWVseQ0KPiBleHBsaWNpdGx5IGNvbnNpZGVy aW5nIHRoaXJkIHBhcnR5IFJUQ1AgcmVwb3J0aW5nIGFuZCB3aGF0IHRvIGRvIHdpdGggaXQuDQo+ IA0KPiBGZWVkYmFjayBpcyBtdWNoIGFwcHJlY2lhdGVkLiBJIHBsYW4gdG8gcHV0IHRoaXMgaW50 byBhIFBSIHRvd2FyZHMgSlNFUA0KPiBBUFBFTkRJWCBCIG9uIG1vbmRheS4gSWYgb25seSB0byBn ZXQgdGhlIEpTRVAgYXV0aG9ycyBhdHRlbnRpb24gOy0pLg0KPiBIb3dldmVyLCB0aGUgdGV4dCBp cyByZWFsbHkgaW50ZW5kZWQgZm9yIHRoZSBuZXh0IHZlcnNpb24gb2YgQlVORExFLg0KPiANCj4g DQo+IFguICBBc3NvY2lhdGluZyBSVFAvUlRDUCBXaXRoIENvcnJlY3QgU0RQIE1lZGlhIERlc2Ny aXB0aW9uDQo+IA0KPiAgICAgQXMgZGVzY3JpYmVkIGluIFtSRkMzNTUwXSwgUlRQIHBhY2tldHMg YXJlIGFzc29jaWF0ZWQgd2l0aCBSVFANCj4gICAgIHN0cmVhbXMgW1JGQzc2NTZdLiAgRWFjaCBS VFAgc3RyZWFtIGlzIGlkZW50aWZpZWQgYnkgYW4gU1NSQyB2YWx1ZSwNCj4gICAgIGFuZCBlYWNo IFJUUCBwYWNrZXQgY2FycmllcyBhbiBTU1JDIHZhbHVlIHRoYXQgaXMgdXNlZCB0byBhc3NvY2lh dGUNCj4gICAgIHRoZSBwYWNrZXQgd2l0aCB0aGUgY29ycmVjdCBSVFAgc3RyZWFtLiAgUlRDUCBw YWNrZXRzIGFsc28gdXNlcyBTU1JDcw0KPiAgICAgdG8gaWRlbnRpZnkgb24gd2hpY2ggUlRQIHN0 cmVhbXMgYW55IHJlcG9ydCBvciBmZWVkYmFjayByZWxhdGUgdG8uDQo+ICAgICBUaHVzLCBhbiBS VENQIHBhY2tldCB3aWxsIGNvbW1vbmx5IGNhcnJ5IG11bHRpcGxlIFNTUkMgdmFsdWVzLCBhbmQN Cj4gICAgIG1pZ2h0IHRoZXJlZm9yZSBiZSBwcm92aWRpbmcgZmVlZGJhY2sgb3IgcmVwb3J0IG9u IG11bHRpcGxlIFJUUA0KPiAgICAgc3RyZWFtcy4NCj4gDQo+ICAgICBJbiBvcmRlciB0byBiZSBh YmxlIHRvIHByb2Nlc3MgcmVjZWl2ZWQgUlRQL1JUQ1AgcGFja2V0cyBjb3JyZWN0bHkgaXQNCj4g ICAgIG11c3QgYmUgcG9zc2libGUgdG8gYXNzb2NpYXRlIGFuIFJUUCBzdHJlYW0gd2l0aCB0aGUg Y29ycmVjdCAibT0iDQo+ICAgICBsaW5lLCBhcyB0aGUgIm09IiBsaW5lIGFuZCBTRFAgYXR0cmli dXRlcyBhc3NvY2lhdGVkIHdpdGggdGhlICJtPSINCj4gICAgIGxpbmUgY29udGFpbiBpbmZvcm1h dGlvbiBuZWVkZWQgdG8gcHJvY2VzcyB0aGUgcGFja2V0cy4NCj4gDQo+ICAgICBBcyBhbGwgUlRQ IHN0cmVhbXMgYXNzb2NpYXRlZCB3aXRoIGEgQlVORExFIGdyb3VwIGFyZSBwYXJ0IG9mIHRoZQ0K PiAgICAgc2FtZSBSVFAgc2Vzc2lvbiBhbmQgdXNpbmcgdGhlIHNhbWUgYWRkcmVzczpwb3J0IGNv bWJpbmF0aW9uIGZvcg0KPiAgICAgc2VuZGluZyBhbmQgcmVjZWl2aW5nIFJUUC9SVENQIHBhY2tl dHMsIHRoZSBsb2NhbCBhZGRyZXNzOnBvcnQNCj4gICAgIGNvbWJpbmF0aW9uIGNhbm5vdCBiZSB1 c2VkIHRvIGFzc29jaWF0ZSBhbiBSVFAgc3RyZWFtIHdpdGggdGhlDQo+ICAgICBjb3JyZWN0ICJt PSIgbGluZS4gIEluIGFkZGl0aW9uLCBtdWx0aXBsZSBSVFAgc3RyZWFtcyBtaWdodCBiZQ0KPiAg ICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBzYW1lICJtPSIgbGluZS4NCj4gDQo+ICAgICBBbHNvLCBh cyBkZXNjcmliZWQgaW4gU2VjdGlvbiAxMC4xLjEsIHRoZSBzYW1lIHBheWxvYWQgdHlwZSB2YWx1 ZQ0KPiAgICAgbWlnaHQgYmUgdXNlZCBieSBtdWx0aXBsZSBSVFAgc3RyZWFtcywgaW4gd2hpY2gg Y2FzZSB0aGUgcGF5bG9hZCB0eXBlDQo+ICAgICB2YWx1ZSBjYW5ub3QgYmUgdXNlZCB0byBhc3Nv Y2lhdGUgYW4gUlRQIHN0cmVhbSB3aXRoIHRoZSBjb3JyZWN0ICJtPSINCj4gICAgIGxpbmUuICBI b3dldmVyLCB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgZWFjaCAibT0iIGxpbmUgaGFzIHVuaXF1ZQ0K PiAgICAgcGF5bG9hZCB0eXBlIHZhbHVlcywgYW5kIHRoZW4gdGhlIHBheWxvYWQgdHlwZSBjb3Vs ZCBzZXJ2ZSBhcw0KPiAgICAgaW5kaWNhdG9yIHRvIHRoZSByZWxldmFudCAibT0iIGxpbmUgdGhl IFJUUCBzdHJlYW0gaXMgYXNzb2NpYXRlZA0KPiAgICAgd2l0aC4NCj4gDQo+ICAgICBBbiBvZmZl cmVyIGFuZCBhbnN3ZXJlciBjYW4gaW5mb3JtIGVhY2ggb3RoZXIgd2hpY2ggU1NSQyB2YWx1ZXMg dGhleQ0KPiAgICAgd2lsbCB1c2UgZm9yIGFuIFJUUCBzdHJlYW0gYnkgdXNpbmcgdGhlIFNEUCAn c3NyYycgYXR0cmlidXRlDQo+ICAgICBbUkZDNTU3Nl0uICBIb3dldmVyLCBhbiBvZmZlcmVyIHdp bGwgbm90IGtub3cgd2hpY2ggU1NSQyB2YWx1ZXMgdGhlDQo+ICAgICBhbnN3ZXJlciB3aWxsIHVz ZSB1bnRpbCB0aGUgb2ZmZXJlciBoYXMgcmVjZWl2ZWQgdGhlIGFuc3dlciBwcm92aWRpbmcNCj4g DQo+IA0KPiANCj4gTmFtZSAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMzEsIDIw MTcgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQo+IA0KDQo+IEludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBBYmJyZXZpYXRlZC1UaXRsZSAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNw0KPiAN Cj4gDQo+ICAgICB0aGF0IGluZm9ybWF0aW9uLiAgRHVlIHRvIHRoaXMsIGJlZm9yZSB0aGUgb2Zm ZXJlciBoYXMgcmVjZWl2ZWQgdGhlDQo+ICAgICBhbnN3ZXIsIHRoZSBvZmZlcmVyIHdpbGwgbm90 IGJlIGFibGUgdG8gYXNzb2NpYXRlIGFuIFJUUCBzdHJlYW0gd2l0aA0KPiAgICAgdGhlIGNvcnJl Y3QgIm09IiBsaW5lIHVzaW5nIHRoZSBTU1JDIHZhbHVlIGFzc29jaWF0ZWQgd2l0aCB0aGUgUlRQ DQo+ICAgICBzdHJlYW0uICBJbiBhZGRpdGlvbiwgdGhlIG9mZmVyZXIgYW5kIGFuc3dlcmVyIG1h eSBzdGFydCB1c2luZyBuZXcNCj4gICAgIFNTUkMgdmFsdWVzIG1pZC1zZXNzaW9uLCB3aXRob3V0 IGluZm9ybWluZyBlYWNoIG90aGVyIHVzaW5nIHRoZSBTRFANCj4gICAgICdzc3JjJyBhdHRyaWJ1 dGUuDQo+IA0KPiAgICAgSW4gb3JkZXIgZm9yIGFuIG9mZmVyZXIgYW5kIGFuc3dlcmVyIHRvIGFs d2F5cyBiZSBhYmxlIHRvIGFzc29jaWF0ZQ0KPiAgICAgYW4gUlRQIHN0cmVhbSB3aXRoIHRoZSBj b3JyZWN0ICJtPSIgbGluZSwgdGhlIG9mZmVyZXIgYW5kIGFuc3dlcmVyDQo+ICAgICB1c2luZyB0 aGUgQlVORExFIGV4dGVuc2lvbiBNVVNUIHN1cHBvcnQgdGhlIG1lY2hhbmlzbSBkZWZpbmVkIGlu DQo+ICAgICBTZWN0aW9uIDE0LCB3aGVyZSB0aGUgb2ZmZXJlciBhbmQgYW5zd2VyZXIgaW5jbHVk ZXMgdGhlDQo+ICAgICBpZGVudGlmaWNhdGlvbi10YWcgKHByb3ZpZGVkIGJ5IHRoZSByZW1vdGUg cGVlcikgYXNzb2NpYXRlZCB3aXRoIGFuDQo+ICAgICAibT0iIGxpbmUgaW4gdGhlIFJUUCBTdHJl YW1zIGFuZCBpbiBSVENQIFNERVMgcGFja2V0cyBwYXJ0IG9mIGENCj4gICAgIEJVTkRMRSBncm91 cC4NCj4gDQo+ICAgICBUaGUgbWFwcGluZyBmcm9tIGFuIFNTUkMgdG8gYW4gaWRlbnRpZmljYXRp b24tdGFnIGlzIGNhcnJpZWQgaW4gUlRDUA0KPiAgICAgU0RFUyBwYWNrZXRzIG9yIGluIFJUUCBo ZWFkZXIgZXh0ZW5zaW9ucyAoU2VjdGlvbiAxNCkuICBTaW5jZSBhDQo+ICAgICBjb21wb3VuZCBS VENQIHBhY2tldCBjYW4gY29udGFpbiBtdWx0aXBsZSBSVENQIFNERVMgcGFja2V0cywgYW5kIGVh Y2gNCj4gICAgIFJUQ1AgU0RFUyBwYWNrZXQgY2FuIGNvbnRhaW4gbXVsdGlwbGUgY2h1bmtzLCBh biBSVENQIHBhY2tldCBjYW4NCj4gICAgIGNvbnRhaW4gc2V2ZXJhbCBTU1JDIHRvIGlkZW50aWZp Y2F0aW9uLXRhZyBtYXBwaW5ncy4gIFRoZSBvZmZlcmVyIGFuZA0KPiAgICAgYW5zd2VyZXIgbWFp bnRhaW4gdGFibGVzIG1hcHBpbmcgUlRQIHN0cmVhbXMgaWRlbnRpZmllZCBieSBTU1JDIHRvDQo+ ICAgICAibT0iIGxpbmVzIGlkZW50aWZpZWQgYnkgdGhlIGlkZW50aWZpY2F0aW9uLXRhZy4gIFRo ZXNlIHRhYmxlcyBhcmUNCj4gICAgIHVwZGF0ZWQgZWFjaCB0aW1lIG5ldyBpbmZvcm1hdGlvbiB0 aGF0IGFmZmVjdHMgaG93IHBhY2tldHMgc2hvdWxkIGJlDQo+ICAgICBwcm9jZXNzZWQgYW5kIHJv dXRlZCBhcmUgcmVjZWl2ZWQuDQo+IA0KPiAgICAgVG8gcHJlcGFyZSBmb3IgZGVtdWx0aXBsZXhp bmcgUlRQIHN0cmVhbXMgdG8gdGhlIGNvcnJlY3QgIm09IiBsaW5lLA0KPiAgICAgdGhlIGZvbGxv d2luZyBzdGVwcyBNVVNUIGJlIGZvbGxvd2VkIGZvciBlYWNoIEJVTkRMRSBncm91cCBiYXNlZCBv bg0KPiAgICAgdGhlIFNEUCBzaWduYWxsaW5nIGluZm9ybWF0aW9uLg0KPiANCj4gICAgICAgIENv bnN0cnVjdCBhIHRhYmxlIG1hcHBpbmcgTUlEIHRvICJtPSIgbGluZSBmb3IgZWFjaCAibT0iIGxp bmUgaW4NCj4gICAgICAgIHRoaXMgQlVORExFIGdyb3VwLiAgTm90ZSB0aGF0IGFuICJtPSIgbGlu ZSBtYXkgb25seSBoYXZlIG9uZSBNSUQuDQo+IA0KPiAgICAgICAgQ29uc3RydWN0IGEgdGFibGUg bWFwcGluZyBpbmNvbWluZyBSVFAgc3RyZWFtcyAoU1NSQ3MpIHRvIHRoZWlyDQo+ICAgICAgICAi bT0iIGxpbmUgZm9yIGVhY2ggIm09IiBsaW5lIGluIHRoaXMgQlVORExFIGdyb3VwIGFuZCBmb3Ig ZWFjaCBSVFANCj4gICAgICAgIHN0cmVhbSBleHBsaWNpdGx5IHNpZ25hbGxlZCBmb3IgcmVjZWl2 aW5nIGluIHRoYXQgIm09IiBsaW5lLg0KPiANCj4gICAgICAgIENvbnN0cnVjdCBhIHRhYmxlIG1h cHBpbmcgcGF5bG9hZCB0eXBlcyB0byAibT0iIGxpbmUgZm9yIGVhY2ggIm09Ig0KPiAgICAgICAg bGluZSBpbiB0aGUgQlVORExFIGdyb3VwIGFuZCBmb3IgZWFjaCBwYXlsb2FkIHR5cGUgY29uZmln dXJlZCBmb3INCj4gICAgICAgIHJlY2VpdmluZyBpbiB0aGF0ICJtPSIgbGluZS4gIElmIGFueSBw YXlsb2FkIHR5cGUgaXMgY29uZmlndXJlZA0KPiAgICAgICAgZm9yIHJlY2VpdmluZyBpbiBtb3Jl IHRoYW4gb25lICJtPSIgbGluZSBpbiB0aGUgQlVORExFIGdyb3VwLCBkbw0KPiAgICAgICAgbm90 IGl0IGluY2x1ZGUgaXQgaW4gdGhlIHRhYmxlLg0KPiANCj4gICAgIE5vdGUgdGhhdCBmb3IgZWFj aCBvZiB0aGVzZSB0YWJsZXMsIHRoZXJlIGNhbiBvbmx5IGJlIG9uZSBtYXBwaW5nIGZvcg0KPiAg ICAgYW55IGdpdmVuIGtleSAoTUlELCBTU1JDLCBvciBQVCkuICBJbiBvdGhlciB3b3JkcywgdGhl IHRhYmxlcyBhcmUgbm90DQo+ICAgICBtdWx0aW1hcHMuDQo+IA0KPiAgICAgQXMgIm09IiBsaW5l cyBhcmUgYWRkZWQgb3IgcmVtb3ZlZCBmcm9tIHRoZSBCVU5ETEUgZ3JvdXBzLCBvciB0aGVpcg0K PiAgICAgY29uZmlndXJhdGlvbnMgYXJlIGNoYW5nZWQsIHRoZSB0YWJsZXMgYWJvdmUgTVVTVCBh bHNvIGJlIHVwZGF0ZWQuDQo+IA0KPiANCj4gDQo+IE5hbWUgICAgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBKdWx5IDMxLCAyMDE3ICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KPiANCg0KPiBJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQWJicmV2aWF0ZWQtVGl0bGUgICAgICAgICAgICAg ICBKYW51YXJ5IDIwMTcNCj4gDQo+IA0KPiAgICAgUmVjZWl2ZWQgUlRQIHBhY2tldHMgdGhhdCBh cmUgc3ludGFjdGljYWxseSBjb3JyZWN0IGFyZSBwcm9jZXNzZWQgYnkNCj4gICAgIHRoZSBSVFAv UlRDUCBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbiBmb3Igc3RhdGlzdGljcyBldGMuICBBZnRlciB0 aGlzDQo+ICAgICBwcm9jZXNzaW5nIHRoZXkgbmVlZCB0byBiZSByb3V0ZWQgdG8gdGhlIGhpZ2hl ciBsYXllciBjb250ZXh0DQo+ICAgICBhc3NvY2lhdGVkIHdpdGggdGhlICJtPSIgbGluZSB3aXRo aW4gdGhlIEJVTkRMRSBncm91cC4gIFNvbWV3aGVyZSBpbg0KPiAgICAgdGhlIHByb2Nlc3Mgd2hl cmUgYW4gcmVjZWl2ZWQgUlRQIHBhY2tldCBpcyBwcm9jZXNzZWQgdG8gYmUgZGVsaXZlcmVkDQo+ ICAgICB0byB0aGUgaGlnaGVyIGxheWVyIGJ5IFJUUCB0aGUgbWF0Y2hpbmcgc3RlcCBiZWxvdyBN VVNUIGJlIHBlcmZvcm1lZDoNCj4gDQo+ICAgICAxLiAgUmVjZXB0aW9uIG9mIGFuIFJUUCBwYWNr ZXQgZm9yIGFuIFJUUCBzdHJlYW0gdGhhdCBoYXMgYW4gZXhpc3RpbmcNCj4gICAgICAgICBtYXBw aW5nIGluIHRoZSBSVFAgc3RyZWFtIHRvIG09IGxpbmUgdGFibGUuICBCZWZvcmUgcHJvY2VlZGlu ZyBpbg0KPiAgICAgICAgIGRlbGl2ZXJpbmcgdGhlIHBhY2tldCB0byB0aGUgaGlnaGVyIGxheWVy IGNvbnRleHQgYWNjb3JkaW5nIHRvDQo+ICAgICAgICAgdGhlIFJUUCBzdHJlYW0gdG8gIm09IiBs aW5lIG1hcHBpbmcgdGFibGUgdGhlIGZvbGxvd2luZyBjaGVja3MNCj4gICAgICAgICBNVVNUIGJl IHBlcmZvcm1lZDoNCj4gDQo+ICAgICAgICAgQS4gIElmIHRoZSBwYWNrZXQgY2FycmllcyBhbiBS VFAgaGVhZGVyIGV4dGVuc2lvbiB3aXRoIGEgU0RFUyBNSUQNCj4gICAgICAgICAgICAgdmFsdWUg dGhhdCBpcyBub3QgaW4gdGhlIHRhYmxlIG1hcHBpbmcgTUlEIHRvICJtPSIgbGluZSwgdGhlbg0K PiAgICAgICAgICAgICBkbyBub3QgZGVsaXZlciB0aGUgUlRQIHBhY2tldCB0byBoaWdoZXIgbGF5 ZXJzLg0KPiANCj4gICAgICAgICBCLiAgSWYgdGhlIHBhY2tldCBjYXJyaWVzIGFuIFJUUCBoZWFk ZXIgZXh0ZW5zaW9uIHdpdGggYSBTREVTIE1JRA0KPiAgICAgICAgICAgICB2YWx1ZSB0aGF0IGlz IGluIHRoZSB0YWJsZSBtYXBwaW5nIE1JRCB0byAibT0iIGxpbmUsIGFuZCB0aGUNCj4gICAgICAg ICAgICAgdmFsdWUgaW5kaWNhdGVzIGEgZGlmZmVyZW50ICJtPSIgbGluZSB0aGFuIHRoZSBjdXJy ZW50IFJUUA0KPiAgICAgICAgICAgICBzdHJlYW0gdG8gIm09IiBsaW5lIG1hcHBpbmcgdGFibGUs IHRoZW4gdXBkYXRlIHRoZSBSVFAgc3RyZWFtDQo+ICAgICAgICAgICAgIHRvICJtPSIgbGluZSBt YXBwaW5nLg0KPiANCj4gICAgIDIuICBSZWNlcHRpb24gb2YgYW4gUlRQIHBhY2tldCBmb3IgYW4g UlRQIHN0cmVhbSB0aGF0IGhhcyBubyBleGlzdGluZw0KPiAgICAgICAgIG1hcHBpbmcgdG8gYW4g bT0gbGluZS4gIEluIHRoaXMgY2FzZSB0aGUgZm9sbG93aW5nIGFjdGlvbnMgTVVTVA0KPiAgICAg ICAgIGJlIHBlcmZvcm1lZDoNCj4gDQo+ICAgICAgICAgQS4gIElmIHRoZSBwYWNrZXQgY2Fycmll cyBhbiBSVFAgaGVhZGVyIGV4dGVuc2lvbiB3aXRoIGEgU0RFUyBNSUQNCj4gICAgICAgICAgICAg dmFsdWUgdGhhdCBpcyBpbiB0aGUgdGFibGUgbWFwcGluZyBNSUQgdG8gIm09IiBsaW5lLCB0aGVu DQo+ICAgICAgICAgICAgIGNyZWF0ZSBhbiBlbnRyeSBpbiB0aGUgUlRQIHN0cmVhbSB0byAibT0i IGxpbmUgbWFwcGluZyB0YWJsZQ0KPiAgICAgICAgICAgICBmb3IgdGhpcyBSVFAgc3RyZWFtIChT U1JDKS4gIFRoZW4gZGVsaXZlciB0aGUgUlRQIHBhY2tldCB0bw0KPiAgICAgICAgICAgICB0aGUg Im09IiBsaW5lIGNvbnRleHQgb2YgdGhlIGNyZWF0ZWQgbWFwcGluZyBhbmQgc3RvcC4NCj4gDQo+ ICAgICAgICAgQi4gIElmIHRoZSBwYWNrZXQgY2FycmllcyBhIFBheWxvYWQgVHlwZSB0aGF0IGlz IGluIHRoZSBwYXlsb2FkDQo+ICAgICAgICAgICAgIHR5cGUgdGFibGUsIHRoZW4gY3JlYXRlIGFu IGVudHJ5IGluIHRoZSBSVFAgc3RyZWFtIHRvICJtPSINCj4gICAgICAgICAgICAgbGluZSBtYXBw aW5nIHRhYmxlIGZvciB0aGlzIFJUUCBzdHJlYW0gKFNTUkMpLiAgVGhlbiBkZWxpdmVyDQo+ICAg ICAgICAgICAgIHRoZSBSVFAgcGFja2V0IHRvIHRoZSAibT0iIGxpbmUgY29udGV4dCBvZiB0aGUg Y3JlYXRlZA0KPiAgICAgICAgICAgICBtYXBwaW5nIGFuZCBzdG9wLg0KPiANCj4gICAgICAgICBD LiAgT3RoZXJ3aXNlIGRvIG5vdCBkZWxpdmVyIHRoZSBSVFAgcGFja2V0IHRvIGhpZ2hlciBsYXll cnMuDQo+ICAgICAgICAgICAgIE5vdGUsIHRoaXMgaW5jbHVkZXMgdW5rbm93biBNSUQgdmFsdWVz Lg0KPiANCj4gICAgIEZvciBlYWNoIFJUQ1AgcGFja2V0IHJlY2VpdmVkIChpbmNsdWRpbmcgZWFj aCBSVENQIHBhY2tldCB0aGF0IGlzDQo+ICAgICBwYXJ0IG9mIGEgY29tcG91bmQgUlRDUCBwYWNr ZXQpLCB0aGUgUlRDUCBwYWNrZXQgbmVlZHMgdG8gYmUNCj4gICAgIHByb2Nlc3NlZCBieSB0aGUg UlRQL1JUQ1AgaW1wbGVtZW50YXRpb24gYW5kIHJlbGV2YW50IGluZm9ybWF0aW9uIGFuZA0KPiAg ICAgZGF0YSBmcm9tIHRoZSBSVENQIHBhY2tldHMgbmVlZHMgdG8gYmUgcm91dGVkIHRvIHRoZSBh cHByb3ByaWF0ZQ0KPiAgICAgaGFuZGxlciBmb3IgdGhlIHJlbGF0ZWQgUlRQIHN0cmVhbXMuICBU aGUgYXBwcm9wcmlhdGUgaGFuZGxlciBpcw0KPiAgICAgZGV0ZXJtaW5lZCBieSB1c2luZyB0aGUg UlRQIHN0cmVhbSB0byAibT0iIGxpbmUgbWFwcGluZyB0YWJsZS4NCj4gDQo+IA0KPiANCj4gTmFt ZSAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMzEsIDIwMTcgICAgICAgICAgICAg ICAgIFtQYWdlIDRdDQo+IA0KDQo+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBBYmJyZXZp YXRlZC1UaXRsZSAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNw0KPiANCj4gDQo+ICAgICBPbiBy ZWNlcHRpb24gb2YgYW55IGNvbXBvdW5kIFJUQ1AgcGFja2V0IHByaW9yIHRvIGRpc3BhdGNoaW5n IHRoZQ0KPiAgICAgcmVjZWl2ZWQgaW5mb3JtYXRpb24gYW5kIGRhdGEsIGlmIHRoZXJlIGlzIGFu IFJUQ1AgU0RFUyBwYWNrZXQNCj4gICAgIGluY2x1ZGVkIHRoYXQgU0hPVUxEIGJlIHByb2Nlc3Nl ZCBmaXJzdC4gIElmIHRoYXQgU0RFUyBwYWNrZXQNCj4gICAgIGNvbnRhaW5zIFNERVMgTUlEIGVu dHJpZXMsIHRoaXMgY2FuIHJlc3VsdHMgaW4gdXBkYXRlcyBhbmQgYWRkaXRpb25zDQo+ICAgICB0 byB0aGUgUlRQIHN0cmVhbSB0byAibT0iIGxpbmUgbWFwcGluZyB0YWJsZS4gIFRodXMgZWFjaCBv ZiB0aGUgU0RFUw0KPiAgICAgTUlEIGl0ZW1zIGFyZSBwcm9jZXNzZWQgYW5kIHRoZSBjdXJyZW50 IHRhYmxlIGVudHJpZXMgYXJlIGNoZWNrZWQgaWYNCj4gICAgIHRoZSBjb3JyZXNwb25kaW5nIE1J RCB2YWx1ZSBtYXRjaGVzIHRoZSBjdXJyZW50IFJUUCBzdHJlYW0gdG8gIm09Ig0KPiAgICAgbGlu ZSBtYXBwaW5nLCBlbHNlIHRoZSBlbnRyeSBpcyB1cGRhdGVkLiAgSWYgdGhlcmUgaXMgbm8gUlRQ IHN0cmVhbQ0KPiAgICAgdG8gIm09IiBsaW5lIHRhYmxlIG1hcHBpbmcgZW50cnkgZm9yIHRoZSBy ZWNlaXZlZCBTREVTIGl0ZW0ncyBTU1JDLA0KPiAgICAgc3VjaCBhbiBlbnRyeSBpcyBjcmVhdGVk LiAgTm90ZSwgdGhhdCBpbiB0aGUgcHJvY2VzcyBvZiB1cGRhdGluZyB0aGUNCj4gICAgIHRhYmxl IGVudHJpZXMsIHVwZGF0ZSBmbGFwIHN1cHByZXNzaW9uIGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9u IDQuMi42DQo+ICAgICBvZiBbUkZDNzk0MV0gc2hvdWxkIGJlIGNvbnNpZGVyZWQuDQo+IA0KPiAg ICAgVGhlIHZhcmlvdXMgZGlmZmVyZW50IFJUQ1AgcGFja2V0cyBhcyB3ZWxsIGFzIHRoZWlyIHZh cmlvdXMgc3ViDQo+ICAgICBwYXJ0cywgc3VjaCBhcyB0aGUgdmFyaW91cyBSVENQIEZlZWRiYWNr IG1lc3NhZ2UgdHlwZXMsIHJlbGF0ZXMgdG8NCj4gICAgIHRoZSBSVFAgc3RyZWFtcyBpbiBhIGNv dXBsZSBvZiBkaWZmZXJlbnQgd2F5cy4gIFRoZSBjdXJyZW50bHkga25vd24NCj4gICAgIHBhdHRl cm5zIGFyZSB0aGUgZm9sbG93aW5nOg0KPiANCj4gICAgIFJlcG9ydHMgb24gb3V0Z29pbmcgUlRQ IHN0cmVhbXM6ICBGb3IgYWxsIFJUUCBzdHJlYW1zIHRoYXQgdGhpcw0KPiAgICAgICAgZW5kcG9p bnQgaXMgdGhlIHNvdXJjZSBvZiwgaXQgY2FuIGV4cGVjdCB0byByZWNlaXZlIHJlcG9ydCBibG9j a3MNCj4gICAgICAgIG9mIHNldmVyYWwgdHlwZXMgaWRlbnRpZmllZCBhcyByZWxhdGluZyB0byBh biBvdXRnb2luZyBzdHJlYW0uDQo+ICAgICAgICBUaGUgYmFzaWMgcGF0dGVybiBmb3IgdGhlc2Ug YmxvY2tzIGFyZSB0aGF0IHRoZSBSVENQIHBhY2tldCBoZWFkZXINCj4gICAgICAgIGlkZW50aWZp ZXMgdGhlIHNvdXJjZSBvZiB0aGUgcmVwb3J0cywgYXMgaWRlbnRpZmllZCBieSBhbiBTU1JDLA0K PiAgICAgICAgYW5kIGNvbnRhaW5pbmcgb25lIG9yIG1vcmUgcmVwb3J0IGJsb2Nrcywgd2hlcmUg ZWFjaCByZXBvcnQgYmxvY2sNCj4gICAgICAgIGlkZW50aWZpZXMgdGhlIFJUUCBzdHJlYW0sIHVz aW5nIHRoZSBTU1JDLCB0aGUgcmVwb3J0IHJlbGF0ZXMgdG8uDQo+ICAgICAgICBGb3IgdGhpcyBw YXR0ZXJuIHRoZSByZWxldmFudCByZXBvcnQgaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQgdG8NCj4g ICAgICAgIHRoZSBoaWdoZXIgbGF5ZXIgYXNzb2NpYXRlZCB3aXRoIHRoZSAibT0iIGxpbmUgdGhl IFJUUCBTdHJlYW0gdG8NCj4gICAgICAgICJtPSIgbGluZSB0YWJsZSBpZGVudGlmaWVzLiAgVGhl IHNvdXJjZSBTU1JDIGFzIGlkZW50aWZpZXIgb2YgdGhlDQo+ICAgICAgICBlbmRwb2ludCB0aGF0 IHRoZSByZXBvcnQgb3JpZ2luYXRlcyBhcmUgcmVsZXZhbnQgZm9yIGludGVycHJldGluZw0KPiAg ICAgICAgdGhlIGluZm9ybWF0aW9uLCBidXQgbm90IG5lY2Vzc2FyaWx5IGZvciByb3V0aW5nLiAg RXhhbXBsZSBvZiB0aGlzDQo+ICAgICAgICBpcyBwYXR0ZXJuIGFyZToNCj4gDQo+ICAgICAgICBT ZW5kZXIgUmVwb3J0IChTUikgYW5kIFJlY2VpdmVyIFJlcG9ydCAoUlIpICBUaGUgYmFzaWMgcmVj ZWl2ZXINCj4gICAgICAgICAgIHJlcG9ydCBibG9ja3MgZnJvbSBSRkMzNTUwIHN0YXJ0IHdpdGgg dGhlIFNTUkMgb2YgdGhlIFJUUA0KPiAgICAgICAgICAgc3RyZWFtIHRoZXkgcmVwb3J0IG9uLg0K PiANCj4gICAgICAgIEV4dGVuZGVkIFJlcG9ydHMgKFhSKTogIFJGQzM2MTEgaXMgYSBmcmFtZXdv cmsgdGhhdCBlbmFibGVzIGENCj4gICAgICAgICAgIGxhcmdlIG51bWJlciBvZiBkaWZmZXJlbnQg cmVwb3J0cy4gIEhvd2V2ZXIsIGEgbGFyZ2UgbnVtYmVyIG9mDQo+ICAgICAgICAgICB0aGVzZSBy ZXBvcnQgZm9ybWF0cyBhcmUgcmVwb3J0aW5nIG9uIHNwZWNpZmljIFJUUCBzdHJlYW1zIGFuZA0K PiAgICAgICAgICAgdGh1cyBlYWNoIGluZGl2aWR1YWwgcmVwb3J0IG9mIHRoZXNlIHR5cGVzIGNv bnRhaW5zIGEgU1NSQw0KPiAgICAgICAgICAgZmllbGQgdG8gaWRlbnRpZnkgdGhlIFJUUCBzdHJl YW0uDQo+IA0KPiAgICAgUlRDUCBGZWVkYmFjayBNZXNzYWdlcyBmb3Igb3V0Z29pbmcgUlRQIHN0 cmVhbXM6ICBUaGUgUkZDIDQ1ODUgUlRDUA0KPiAgICAgICAgZmVlZGJhY2sgbWVzc2FnZXMgYWxs b3cgZm9yIGEgbnVtYmVyIG9mIGRpZmZlcmVudCB0eXBlIG9mIGZlZWRiYWNrDQo+ICAgICAgICBt ZXNzYWdlcy4gIEhvd2V2ZXIsIHRoZSBSVENQIGZlZWRiYWNrIG1lc3NhZ2UgaGVhZGVyIGNvbnRh aW5zIHRoZQ0KPiAgICAgICAgU1NSQyBpZGVudGlmeWluZyB0aGUgc291cmNlIG9mIHRoZSBmZWVk YmFjayBtZXNzYWdlcyBhcyB3ZWxsIGFzDQo+ICAgICAgICB0aGUgYWN0dWFsIHR5cGUgb2YgdGhl IGZlZWRiYWNrLiAgU29tZSBvZiB0aGUgZmVlZGJhY2sgbWVzc2FnZXMNCj4gICAgICAgIGFsc28g dXNlcyB0aGUgdGFyZ2V0IFNTUkMgZmllbGQgaW4gdGhlIGhlYWRlciB0byBpZGVudGlmeSB3aGlj aA0KPiANCj4gDQo+IA0KPiBOYW1lICAgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAz MSwgMjAxNyAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCj4gDQoNCj4gSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIEFiYnJldmlhdGVkLVRpdGxlICAgICAgICAgICAgICAgSmFudWFyeSAyMDE3 DQo+IA0KPiANCj4gICAgICAgIFJUUCBzdHJlYW0gdGhlIGZlZWRiYWNrIGlzIHJlbGF0ZWQgdG8u ICBGb3IgdGhlc2UgdHlwZXMgYWxsIHRoZQ0KPiAgICAgICAgRkNJIGVudHJpZXMsIGlmIG11bHRp cGxlIG9uZXMgYXJlIGZvcndhcmRlZCB0byB0aGUgaWRlbnRpZmllZA0KPiAgICAgICAgaGFuZGxl ci4gIEV4YW1wbGVzIG9mIHRoaXMgcGF0dGVybiBhcmU6DQo+IA0KPiAgICAgICAgUGljdHVyZSBM b3NzIEluZGljYXRpb24gKFBMSSk6ICBSRkMgNDU4NSAoUFQ9UFNGQiwgRk1UPTEpLg0KPiANCj4g ICAgICAgIFNsaWNlIExvc3MgSW5kaWNhdGlvbiAoU0xJKTogIFJGQyA0NTg1IChQVD1QU0ZCLCBG TVQ9MikuDQo+IA0KPiAgICAgICAgUmVmZXJlbmNlIFBpY3R1cmUgU2VsZWN0aW9uIEluZGljYXRp b24gKFJQU0kpOiAgUkZDIDQ1ODUgKFBUPVBTRkIsDQo+ICAgICAgICAgICBGTVQ9MykuDQo+IA0K PiAgICAgICAgR2VuZXJpYyBOQUNLOiAgW1JGQzQ1ODVdIChQVD1SVFBGQiBhbmQgRk1UPTEpLg0K PiANCj4gICAgICAgIE90aGVyIGZlZWRiYWNrIG1lc3NhZ2VzIGluY2x1ZGVzIHRoZSB0YXJnZXQg U1NSQyBpbiB0aGUgRmVlZGJhY2sNCj4gICAgICAgIENvbnRyb2wgSW5mb3JtYXRpb24gKEZDSSku ICBIZXJlIGVhY2ggRkNJIG5lZWRzIHRvIGJlIHByb2Nlc3NlZA0KPiAgICAgICAgYW5kIHRoZSBT U1JDIGZpZWxkIGlkZW50aWZpZWQuICBBbmQgdGhlIGluZGl2aWR1YWwgRkNJIGNvbWJpbmVkDQo+ ICAgICAgICB3aXRoIHRoZSBSVENQIHBhY2tldCBoZWFkZXIgY29udGV4dCBuZWVkcyB0byBiZSBm b3J3YXJkZWQgdG8gdGhlDQo+ICAgICAgICBpZGVudGlmaWVkIGhhbmRsZXIuICBFeGFtcGxlIG9m IHRoaXMgcGF0dGVybiBhcmU6DQo+IA0KPiAgICAgICAgRnVsbCBJbnRyYSBSZXF1ZXN0IChGSVIp OiAgW1JGQzUxMDRdIChQVD1QU0ZCLCBGTVQ9NCkuDQo+IA0KPiAgICAgICAgVGVtcG9yYWwtU3Bh dGlhbCBUcmFkZS1vZmYgUmVxdWVzdCAoVFNUUik6ICBbUkZDNTEwNF0gKFBUPVBTRkIsDQo+ICAg ICAgICAgICBGTVQ9NSkuDQo+IA0KPiAgICAgICAgVGVtcG9yYWwtU3BhdGlhbCBUcmFkZS1vZmYg Tm90aWZpY2F0aW9uIChUU1ROKTogIFRoaXMgW1JGQzUxMDRdDQo+ICAgICAgICAgICBkZWZpbmVk IG1lc3NhZ2UgKFBUPVBTRkIsIEZNVD01KSBpcyBhY3R1YWxseSBhIG5vdGlmY2lhdGlvbiBpbg0K PiAgICAgICAgICAgcmVzcG9uc2UgdG8gYSBUU1RSIHRoaXMgZW5kcG9pbnQgc2VudCB1c2luZyB0 aGUgU1NSQyB0aGUgRkNJDQo+ICAgICAgICAgICBpZGVudGlmaWVzIGFzIHNvdXJjZS4NCj4gDQo+ ICAgICAgICBILjI3MSBWaWRlbyBCYWNrIENoYW5uZWwgTWVzc2FnZSAoVkJDTSk6ICBbUkZDNTEw NF0gKFBUPVBTRkIsDQo+ICAgICAgICAgICBGTVQ9NykuDQo+IA0KPiAgICAgICAgTGF5ZXIgUmVm cmVzaCBSZXF1ZXN0IChMUlIpOiAgW0ktRC5pZXRmLWF2dGV4dC1scnJdIChQVD1QU0ZCLA0KPiAg ICAgICAgICAgRk1UPVRCRCkuDQo+IA0KPiAgICAgRGVzY3JpcHRpdmUgb3IgTm90aWZpY2F0aW9u cyBmb3IgYW4gaW5jb21pbmcgUlRQIHN0cmVhbTogIFRoZXJlIGV4aXN0DQo+ICAgICAgICBzb21l IFJUQ1AgcGFja2V0IHR5cGVzIHRoYXQgcHJvdmlkZXMgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBv cg0KPiAgICAgICAgbm90aWZpZXMgYWJvdXQgZXZlbnRzIHJlbGF0ZWQgdG8gdGhlIFJUUCBzdHJl YW0gaWRlbnRpZmllZC4gIEluDQo+ICAgICAgICB0aGVzZSBjYXNlcyB0aGUgUlRQIHN0cmVhbSBp cyBpZGVudGlmaWVkIHVzaW5nIHRoZSBTU1JDIGZpZWxkDQo+ICAgICAgICB2YWx1ZSwgYW5kIHRo ZSBpbmZvcm1hdGlvbiBpcyBwcm92aWRlZCB0byB0aGUgaGlnaGVyIGxheWVyDQo+ICAgICAgICBh c3NvY2lhdGVkIHdpdGggdGhlICJtPSIgbGluZSBmb3IgdGhlIGluY29taW5nIFJUUCBzdHJlYW0g YXMNCj4gICAgICAgIGlkZW50aWZpZWQgYnkgdGhlIGN1cnJlbnQgUlRQIHN0cmVhbSB0byAibT0i IGxpbmUgdGFibGUuICBGb3IgdGhpcw0KPiAgICAgICAgdHlwZSBvZiBwYXR0ZXJuIGl0IGlzIGNv bW1vbiB0aGF0IHRoZSBSVENQIHBhY2tldHMgYW5kIGluZm9ybWF0aW9uDQo+ICAgICAgICBpcyBy ZXBlYXRlZCwgZWl0aGVyIHBlcmlvZGljYWxseSAoZS5nLiAgU0RFUyBpdGVtcyksIG9yIGZvciBh DQo+ICAgICAgICBkdXJhdGlvbiAoZS5nLiAgQllFKSwgdGh1cyBzdXBwcmVzc2lvbiBvZiByZXBl dGl0aW9ucyBjYW4gYmUNCj4gICAgICAgIGNvbnNpZGVyZWQuICBFeGFtcGxlcyBvZiB0aGVzZSBh cmU6DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gTmFtZSAgICAgICAgICAgICAgICAgICAgICBFeHBp cmVzIEp1bHkgMzEsIDIwMTcgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQo+IA0KDQo+IEludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBBYmJyZXZpYXRlZC1UaXRsZSAgICAgICAgICAgICAgIEph bnVhcnkgMjAxNw0KPiANCj4gDQo+ICAgICAgICBTb3VyY2UgRGVzY3JpcHRpb24gKFNERVMpIFJU Q1AgUGFja2V0OiAgVGhlIGJhc2UgUlRQL1JUQ1AgcHJvdG9jb2wNCj4gICAgICAgICAgIFtSRkMz NTUwXSBkZWZpbmVzIFNERVMgUlRDUCBwYWNrZXRzIGFzIGEgd2F5IG9mIHByb3ZpZGluZyBwZXIN Cj4gICAgICAgICAgIHNvdXJjZSAoU1NSQykgc3BlY2lmaWMgaW5mb3JtYXRpb24gYWJvdXQgdGhl IHNvdXJjZS4gIEFuIFNERVMNCj4gICAgICAgICAgIHBhY2tldCBjb250YWlucyB6ZXJvIG9yIG1v cmUgY2h1bmtzLCB3aGVyZSBhIGNodW5rIGNvbnRhaW5zIHRoZQ0KPiAgICAgICAgICAgU1NSQyBm b3IgdGhlIHNvdXJjZSBiZWluZyBkZXNjcmliZWQgYnkgdGhlIG9uZSBvciBtb3JlIGl0ZW1zDQo+ ICAgICAgICAgICBpbmNsdWRlZCBpbiB0aGUgY2h1bmsuICBGb3J3YXJkIHRoZSBTREVTIGl0ZW1z IGluIGVhY2ggY2h1bmsgdG8NCj4gICAgICAgICAgIHRoZSBSVFAgc3RyZWFtJ3MgaGFuZGxlci4N Cj4gDQo+ICAgICAgICBHb29kYnllIChCWUUpIFJUQ1AgUGFja2V0OiAgVGhpcyBSVFAvUlRDUCBw cm90b2NvbCBbUkZDMzU1MF0NCj4gICAgICAgICAgIG1lY2hhbmlzbSBpbmRpY2F0ZXMgdGhhdCBh IHBhcnRpY3VsYXIgUlRQIHN0cmVhbSBpcyBsZWF2aW5nIHRoZQ0KPiAgICAgICAgICAgUlRQIHNl c3Npb24uICBUaHVzLCBhIG1vc3QgcmVsZXZhbnQgZXZlbnQgdG8gaW5mb3JtIHRoZSBoYW5kbGVy DQo+ICAgICAgICAgICBmb3IgdGhpcyBSVFAgc3RlYW0gb2YuDQo+IA0KPiAgICAgVGhpcmQgUGFy dHkgVGFyZ2V0ZWQgUmVwb3J0cyBvciBGZWVkYmFjazogIFRoZXJlIGV4aXN0IHNvbWUNCj4gICAg ICAgIG11bHRpcGFydHkgUlRQIFRvcG9sb2dpZXMgdGhhdCByZXN1bHRzIGluIHRoYXQgYW4gZW5k cG9pbnQNCj4gICAgICAgIHJlY2VpdmVzIHRoaXJkIHBhcnR5IHJlcG9ydHMgKFNSIFtSRkMzNTUw XSwgUlIgW1JGQzM1NTBdIG9yIFhSDQo+ICAgICAgICBbUkZDMzYxMV0pIGFzIHdlbGwgYXMgRmVl ZGJhY2sgTWVzc2FnZXMgW1JGQzQ1ODVdIHRoYXQgcmVsYXRlcyB0bw0KPiAgICAgICAgb3IgdGFy Z2V0cyBhbiBTU1JDIHRoYXQgb3JpZ2luYXRlcyBmcm9tIGFub3RoZXIgZW5kcG9pbnQsIGFuZA0K PiAgICAgICAgd2hlcmUgdGhlIHNvdXJjZSBvZiB0aGUgUlRDUCBwYWNrZXQgaXMgYWxzbyBhbm90 aGVyIGVuZHBvaW50Lg0KPiAgICAgICAgVGhpcyB0eXBlIG9mIHBhY2tldHMgc2hvdWxkIGJlIGZv cndhcmRlZCB0byB0aGUgaGlnaGVyIGxheWVyDQo+ICAgICAgICBmdW5jdGlvbiBkZWFsaW5nIHdp dGggdGhlIHRoaXJkIHBhcnR5IHJlcG9ydGluZy4gIEFuZCBpZiBub25lDQo+ICAgICAgICBleGlz dCB0aGVuIHRoZXkgY2FuIGJlIHN1cHByZXNzZWQuICBBcyB0aGUgdGhpcmQgcGFydHkgaGFuZGxl ciBjYW4NCj4gICAgICAgIGJlIGZvY3VzZWQgb24gZGV0ZXJtaW5pbmcgdGhlIGNvbmRpdGlvbnMg Zm9yIHRoZSBzb3VyY2Ugb2YgdGhlDQo+ICAgICAgICByZXBvcnRzIGFuZCBmZWVkYmFjaywgb3Ig Zm9jdXNlZCBvbiBob3cgdGhlIFJUUCBzdHJlYW0gc291cmNlDQo+ICAgICAgICBwcm9ncmVzc2Vz LCBvciBib3RoIHJlY29tbWVuZGF0aW9ucyBjYW4ndCBiZSBtYWRlLg0KPiANCj4gICAgIEFQUCBQ YWNrZXRzOiAgVGhlIFJUQ1AgQVBQIFBhY2tldHMgW1JGQzM1NTBdIGFyZSBhIG1lY2hhbmlzbSB0 aGF0DQo+ICAgICAgICBlbmFibGVzIGV4cGVyaW1lbnRhdGlvbi4gIFRoZSBBUFAgcGFja2V0IG9u bHkgc3BlY2lmaWVzIHRoZSBzb3VyY2UNCj4gICAgICAgIG9mIHRoZSBwYWNrZXQuICBUaHVzIHRo aXMgaW5mb3JtYXRpb24gY2FuIGJlIHJlbGF0ZWQgdG8gYW55IG9mIHRoZQ0KPiAgICAgICAgIm09 IiBsaW5lcywgdGh1cyBkZWxpdmVyIGEgY29weSBvZiB0aGUgcGFja2V0IHRvIGVhY2ggIm09IiBs aW5lIG9yDQo+ICAgICAgICBhbiBBUFAgc3BlY2lmaWMgaGFuZGxlci4NCj4gDQo+IC0tDQo+IENo ZWVycw0KPiANCj4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gU2Vy dmljZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIv VFhNDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgIHwgUGhv bmUgICs0NiAxMCA3MTQ4Mjg3DQo+IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgIHwgTW9i aWxlICs0NiA3MyAwOTQ5MDc5DQo+IFNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0 bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHJ0Y3dl YiBtYWlsaW5nIGxpc3QNCj4gcnRjd2ViQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo= From nobody Thu Feb 2 04:50:26 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340FA1293EC; Thu, 2 Feb 2017 04:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ludkPUqzYFtW; Thu, 2 Feb 2017 04:50:18 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D9A1279EB; Thu, 2 Feb 2017 04:50:17 -0800 (PST) X-AuditID: c1b4fb3a-12eaf98000004068-b3-58932b075107 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 47.93.16488.70B23985; Thu, 2 Feb 2017 13:50:15 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0319.002; Thu, 2 Feb 2017 13:49:24 +0100 From: Christer Holmberg To: Christer Holmberg , Roman Shpount Thread-Topic: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) Thread-Index: AQHSfLiANa/BcGrwW06zr+Sq61BcZKFUkZKA///z5ICAABGQgP//8++AgAEf9ICAABJ5AA== Date: Thu, 2 Feb 2017 12:49:24 +0000 Message-ID: References: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFD8EB8@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D4B8F7CE1749Cchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUyM2J7oC679uQIgzVP9S2mn/nLaHHw4jJW i/cXdC1m/JnIbHF+53omi6nLH7NYzLgwldmB3WPK742sHl+evGTyWLLkJ5PHrSkFASxRXDYp qTmZZalF+nYJXBnX99gXrKmoOHihm62BcVtWFyMHh4SAicS7CexdjFwcQgLrGCXaHj1jgXAW MUosbN3GClLEJmAh0f1Pu4uRk0NEIFriw4cFTCA1zALTmSTWvfvOBpIQFsiQONPVzwZRlCnx 8vRXFgg7TGLmradMIDaLgIrE8w9XwGxeAWuJhSd+sEEsa2SWWPPrGRPIMk4BG4m/3/VBahgF xCS+n1oDVs8sIC5x68l8MFtCQEBiyZ7zzBC2qMTLx/9YQWxRAT2J5c/XQMUVJT6+2scI0Zsg 0bHoMyvEXkGJkzOfsExgFJ2FZOwsJGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxVK+1xMML s1mQ1Sxg5FjFKFqcWlycm25kpJdalJlcXJyfp5eXWrKJERjHB7f8ttrBePC54yFGAQ5GJR5e A4NJEUKsiWXFlbmHGCU4mJVEeGNUJ0cI8aYkVlalFuXHF5XmpBYfYpTmYFES5zVbeT9cSCA9 sSQ1OzW1ILUIJsvEwSnVwMh8cq7VI91PulViutUP5h1rS3A+PFtM0cCr5miFro7njIWxO1kv CSjd05NQfKO7LpjhS9/Bg2slPXbGuXb/f6795MdKjQzT9/k+l7asqz4ucmPDugdzn6ey3Wcx 2FWyLCv1XWffGuboUz03nuevuFa089ppaQfWRIl9WsK7K9mPt10XufFoeZISS3FGoqEWc1Fx IgCR7Xbl3wIAAA== Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , Flemming Andreasen , IESG , "draft-ietf-mmusic-4572-update@ietf.org" Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 12:50:21 -0000 --_000_D4B8F7CE1749Cchristerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pull request: https://github.com/fluffy/4572bis/pull/14 Regards, Christer From: Christer Holmberg > Date: Thursday 2 February 2017 at 13:43 To: Roman Shpount > Cc: "alissa@cooperw.in" >, Flemming Andreasen >, "mmusic-chairs@ietf.org" >, "draft-ietf-mmusic-457= 2-update@ietf.org" >, "iesg@ietf.org" >, "mmusic@ietf.org" > Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-457= 2-update-12: (with COMMENT) Resent-From: > Resent-To: Christer Holmberg >, Jonathan Lennox > Resent-Date: Thursday 2 February 2017 at 13:43 Hi, Ok, it seems like there is stronger preference for removing the text, and n= obody has objected. So, I will remove the text in the next version of the document. Regards, Christer From: Roman Shpount > Date: Wednesday 1 February 2017 at 22:34 To: Christer Holmberg > Cc: "alissa@cooperw.in" >, Flemming Andreasen >, "mmusic-chairs@ietf.org" >, "draft-ietf-mmusic-457= 2-update@ietf.org" >, "iesg@ietf.org" >, "mmusic@ietf.org" > Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-457= 2-update-12: (with COMMENT) I am for removing the text. _____________ Roman Shpount On Wed, Feb 1, 2017 at 3:18 PM, Christer Holmberg > wrote: Does anyone object to deleting the text? Martin? Ekr? Roman? Cullen? Regards, Christer -----Original Message----- From: Alissa Cooper [mailto:alissa@cooperw.in] Sent: 01 February 2017 22:15 To: Christer Holmberg > Cc: IESG >; draft-ietf-mmusic-4572-upda= te@ietf.org; Flemming Andrea= sen >; mmusic-chairs@ietf.org= ; mmusic@ietf.org Subject: Re: Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-= 12: (with COMMENT) > On Feb 1, 2017, at 3:04 PM, Christer Holmberg > wrote: > > Hi Alissa, > > Thank you for your review! See below. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > >> Section 5.1 says: >> >> "An endpoint MAY, in addition to its more preferred hash function, >> also verify that each certificate used matches fingerprints >> calculated using other hash functions. Unless there is a matching >> fingerprint for each tested hash function, the endpoint MUST NOT >> establish the TLS connection." >> >> This seems a little weird to me. It's up to the endpoint to decide >> whether to check for errors, and then if it does find an error it >> can't setup the connection, whereas if it just hadn't checked it would b= e able to setup the connection. I think it would help to explain why an end= point would be motivated to check multiple fingerprints. > > I think the only use-case that came up was a situation where the receiver= is not sure which hash function is the "strongest", and therefor checks mu= ltiple. However, it was also realized that with the multiple set of hash fu= nctions such situation is very unlikely to occur. > > So, I could add the following note: > > "NOTE: An endpoint might choose to match each used certificate against > fingerprints calculated using multiple hash functions e.g, if the endpoin= t is unsure which hash function is the strongest." > > ...or we could simply delete the text. I personally would go for that, bu= t in case others want to keep it I have no problem with that. It would make more sense to me to delete it but either solution would be an= improvement I think. Thanks, Alissa > > Regards, > > Christer > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_D4B8F7CE1749Cchristerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Regards,

Christer

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Thursday 2 February 2017 at 1= 3:43
To: Roman Shpount <roman@telurix.com>
Cc: "alissa@cooperw.in" <alissa@cooperw.in>, Flemming Andreasen <fandreas@cisco.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org&g= t;, "draft-i= etf-mmusic-4572-update@ietf.org" <draft-ietf-mmusic-4572-update@ietf.org>= , "iesg@ietf.org" <iesg@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Alissa Cooper= 's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT)
Resent-From: <alias-bounces@ietf.org>
Resent-To: Christer Holmberg <christer.holmberg@ericsson.= com>, Jonathan Lennox <jona= than@vidyo.com>
Resent-Date: Thursday 2 February 20= 17 at 13:43

Hi,

Ok, it seems like there is stronger preference for removing the text, = and nobody has objected.

So, I will remove the text in the next version of the document.

Regards,

Christer

From: Roman Shpount <roman@telurix.com>
Date: Wednesday 1 February 2017 at = 22:34
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "alissa@cooperw.in" <alissa@cooperw.in>, Flemming Andreasen <fandreas@cisco.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org&g= t;, "draft-i= etf-mmusic-4572-update@ietf.org" <draft-ietf-mmusic-4572-update@ietf.org>= , "iesg@ietf.org" <iesg@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Alissa Cooper= 's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT)

I am for removing the text. 

_________= ____
Roman Shpount

On Wed, Feb 1, 2017 at 3:18 PM, Christer Holmber= g <chr= ister.holmberg@ericsson.com> wrote:
Does anyone object to deleting the text? Martin? Ekr? Roman? Cullen?

Regards,

Christer

-----Original Message-----
From: Alissa Cooper [mailto:alissa@coo= perw.in]
Sent: 01 February 2017 22:15
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: IESG <iesg@ietf.org>; draft-ietf-mmusic-4572-update@ietf.org; Flemming Andreasen <fandreas@cisco.com>; mmusic-chairs@ietf.org; mmusic@ietf.org
Subject: Re: Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-= 12: (with COMMENT)


> On Feb 1, 2017, at 3:04 PM, Christer Holmberg <christer.holmberg@ericsson.com> w= rote:
>
> Hi Alissa,
>
> Thank you for your review! See below.
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
>> Section 5.1 says:
>>
>> "An endpoint MAY, in addition to its more preferred hash func= tion,
>> also verify that each certificate used matches fingerprints
>> calculated using other hash functions.  Unless there is a mat= ching
>> fingerprint for each tested hash function, the endpoint MUST NOT >> establish the TLS connection."
>>
>> This seems a little weird to me. It's up to the endpoint to decide=
>> whether to check for errors, and then if it does find an error it<= br> >> can't setup the connection, whereas if it just hadn't checked it w= ould be able to setup the connection. I think it would help to explain why = an endpoint would be motivated to check multiple fingerprints.
>
> I think the only use-case that came up was a situation where the recei= ver is not sure which hash function is the "strongest", and there= for checks multiple. However, it was also realized that with the multiple s= et of hash functions such situation is very unlikely to occur.
>
> So, I could add the following note:
>
> "NOTE: An endpoint might choose to match each used certificate ag= ainst
> fingerprints calculated using multiple hash functions e.g, if the endp= oint is unsure which hash function is the strongest."
>
> ...or we could simply delete the text. I personally would go for that,= but in case others want to keep it I have no problem with that.

It would make more sense to me to delete it but either solution would be an= improvement I think.

Thanks,
Alissa

>
> Regards,
>
> Christer
>
>

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

--_000_D4B8F7CE1749Cchristerholmbergericssoncom_-- From nobody Thu Feb 2 09:15:50 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC021129494 for ; Thu, 2 Feb 2017 09:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cniU8QCWBTei for ; Thu, 2 Feb 2017 09:15:47 -0800 (PST) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F48F1294C2 for ; Thu, 2 Feb 2017 09:15:45 -0800 (PST) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-09v.sys.comcast.net with SMTP id ZKybc19oq3kZMZKz2ceQUb; Thu, 02 Feb 2017 17:15:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1486055744; bh=CXf9xbWaWbRJrQbxIHP8NxOHwKZgA63fc9jZpZVHMK4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=kw9oqL5iPz+AXYCUC0FT4PchHOlZaC3X6Sr/SmaShpdOZEE1P1HrEUrAQGA9FkBFw hMTSW+8FA38qCW3bzfKk8Uq8xhOr7Y4qpKbiq9+g9gp9tlly5IrM8+gj7SehnMsVPC 42QzASjh/z5sSUp5jvhCZctO9fuKijFxmGJVfe2MfH9/CyMPvraBArjL9HKHVarB3S OWa5uWQgkpOmK9Mlhf6rwfMtA+GpO3X2kGxJPoGHALCA8zVF3RrD6Dvo3clI+bvjZI voL+ewKlMUHkhotk46ceQ3q+ttMJLc2ZNEGnTFGMnX3DVWGUc2k/7aPTyiWmn1ECMO XhW55cL7+fc+g== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-02v.sys.comcast.net with SMTP id ZKz0cZqtzk3bxZKz1cRj1c; Thu, 02 Feb 2017 17:15:43 +0000 To: Christer Holmberg , "mmusic@ietf.org" References: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se> <22b63f2b-5f73-bca2-09b1-6c983126d21f@comcast.net> From: Paul Kyzivat Message-ID: <87100955-2655-90fe-70db-aaf0182a2224@comcast.net> Date: Thu, 2 Feb 2017 12:15:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfIIfuJ6OKFYb3q/BflNgC342Fek8tOOgylXjuYANEsGk1ETRorwqLSAk1qeO92mXUboyW4Yf4UA+JNccuj/4dVHyCmV9shbuQpVOoJNuH5eKWtN+mo8O 3iBdC2dD5qaizQl3YWme+yAiEY0cfR8YnEJ6vWWE4NEBiO/PkigKhD0uA546uwvDNROUNmFDD/PsiK9iByiVpWt2JZdQ6dcaWfmLvtvYBKI2CYJiZs61ghe1 Archived-At: Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 17:15:49 -0000 On 2/2/17 3:28 AM, Christer Holmberg wrote: > Hi Paul, > >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>>> Section 5.1 says: >>>>> >>>>> "An endpoint MAY, in addition to its more preferred hash function, >>>>> also verify that each certificate used matches fingerprints >>>>> calculated using other hash functions. Unless there is a matching >>>>> fingerprint for each tested hash function, the endpoint MUST NOT >>>>> establish the TLS connection." >>>>> >>>>> This seems a little weird to me. It's up to the endpoint to decide >>>>> whether to check for errors, and then if it >>>>> does find an error it can't setup the connection, whereas if it just >>>>> hadn't checked it would be able to setup >>>>> the connection. I think it would help to explain why an endpoint >>>>> would be motivated to check multiple fingerprints. >>>> >>>> I think the only use-case that came up was a situation where the >>>> receiver is not sure which hash function is the "strongest", and >>>> therefor checks multiple. However, it was also realized that with the >>>> multiple set of hash functions such situation is very unlikely to >>>> occur. >>>> >>>> So, I could add the following note: >>>> >>>> "NOTE: An endpoint might choose to match each used certificate against >>>> fingerprints calculated using multiple >>>> hash functions e.g, if the endpoint is unsure which hash function is >>>> the strongest." >>> >>> In retrospect, I have to question that motivation. Is it that hard to >>> figure out? It seems like if you have two hash functions that are >>> reasonably equal, an implementation could just pick one. >>> >>>> >>>> ...or we could simply delete the text. I personally would go for that, >>>> but in case others want to keep it I have no problem with that. >>> >>> Given that this has caused confusion at every step, I support removing >>> the text. >> >> ISTM that the main point here is: *if* the recipient happens to check >> more than one hash, a failure of any one of them is to be considered an >> overall failure, rather than a success of one and a failure of another >> being considered a success. > > The question was WHY an endpoint would check more than one hash function > to begin with, and the only reason we have came up with is if the endpoint > doesn¹t ³know" which is the strongest hash - which sounds a little weird. I don't see why we need to know why. Maybe they intend to try them all, just for completeness. But if there is ever a question about the validity of an implementation, I don't want to be arguing with somebody who says: "I tried them all, and several failed but one succeeded so I decided it must be ok." Thanks, Paul From nobody Thu Feb 2 09:48:06 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7474D1294CA for ; Thu, 2 Feb 2017 09:48: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PurUUm_5svFc for ; Thu, 2 Feb 2017 09:48:03 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD96129485 for ; Thu, 2 Feb 2017 09:48:03 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id x49so42580258qtc.2 for ; Thu, 02 Feb 2017 09:48:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dtJVdkm+V0RoZir4KM0e1bdrj/w0h2NZYmOCtDwX+Uw=; b=sExu4xXL04UlksdlRn5HnWvh6faxUC5vpqBYZx1eq5xk+VPIdwontLntkiaCHniPms Z9xfl8bdcpvzO/xR26ndvTb9WeFumfSbVo0dx4d9XQneB7Sywf5wOaV1JqW88IyB/aYt Xa29zr30zW/fEyf2YrNWV+UN2O2q6URcyT74lMIS9983lcnAf3dl9pPhtouqV6LQbUNu Zk9cTzB2q67Jpogh+yCPA9TfOUnKpsnFZfgNeOG5TcUmGdQ+LDR1MPLzkmU3dAT2mo9i zywl8eCSBIbmLgSvbC6bqn/aAqN+DP2SNVwmzoHgkZXpHEMfd+PSmOadW2HMBHzWvg70 pHIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dtJVdkm+V0RoZir4KM0e1bdrj/w0h2NZYmOCtDwX+Uw=; b=bchkXp+zxDmV/d45VAb/sm8EdcHoGYaLC6vzljcezXOf4oaw4EnvDBYEqkwBSkYVlI FcHDHKX4EKY9Mz00QlHywSB2xhPQ2smWFc3Cy9mjLYLcKyijdAB9AwrgpkzTRr/X/4Yt /FKWdwvgi/jP6iN1vu6S3iKEjrDxgOfeIyLeE3guYC3UZb/1dboyOPWEza7c04D2pUhO LSkhFZ4LJICBasmCe1tKRWX3DMKeNA99x6Q09osxdBXEo8AuK/EyjCIopah74xnP2h2I R8cJPUT5mZ5tzEjT3Vn9EQdQ5TMPqDV9pW8Oh8KOrbjNhcHqeC2GFSQYgoWih7uEJ/Ms W6fg== X-Gm-Message-State: AIkVDXLFZ436j2+S+O6RZx64k5EFA3SUHJwHyjPGc3KksXQirI017NWPcyIFPJpJeAh6Ag== X-Received: by 10.55.214.207 with SMTP id p76mr9156648qkl.241.1486057682008; Thu, 02 Feb 2017 09:48:02 -0800 (PST) Received: from mail-qt0-f172.google.com (mail-qt0-f172.google.com. [209.85.216.172]) by smtp.gmail.com with ESMTPSA id 23sm22058421qtp.20.2017.02.02.09.48.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 09:48:01 -0800 (PST) Received: by mail-qt0-f172.google.com with SMTP id v23so42919099qtb.0 for ; Thu, 02 Feb 2017 09:48:01 -0800 (PST) X-Received: by 10.237.50.101 with SMTP id y92mr9907907qtd.179.1486057681179; Thu, 02 Feb 2017 09:48:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Thu, 2 Feb 2017 09:48:00 -0800 (PST) In-Reply-To: <87100955-2655-90fe-70db-aaf0182a2224@comcast.net> References: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se> <22b63f2b-5f73-bca2-09b1-6c983126d21f@comcast.net> <87100955-2655-90fe-70db-aaf0182a2224@comcast.net> From: Roman Shpount Date: Thu, 2 Feb 2017 12:48:00 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a114d7daa33e2d805478fc435 Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 17:48:05 -0000 --001a114d7daa33e2d805478fc435 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 2, 2017 at 12:15 PM, Paul Kyzivat wrote: > On 2/2/17 3:28 AM, Christer Holmberg wrote: > >> Hi Paul, >> >> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------= - >>>>> >>>>> Section 5.1 says: >>>>>> >>>>>> "An endpoint MAY, in addition to its more preferred hash function, >>>>>> also verify that each certificate used matches fingerprints >>>>>> calculated using other hash functions. Unless there is a matching >>>>>> fingerprint for each tested hash function, the endpoint MUST NOT >>>>>> establish the TLS connection." >>>>>> >>>>>> This seems a little weird to me. It's up to the endpoint to decide >>>>>> whether to check for errors, and then if it >>>>>> does find an error it can't setup the connection, whereas if it just >>>>>> hadn't checked it would be able to setup >>>>>> the connection. I think it would help to explain why an endpoint >>>>>> would be motivated to check multiple fingerprints. >>>>>> >>>>> >>>>> I think the only use-case that came up was a situation where the >>>>> receiver is not sure which hash function is the "strongest", and >>>>> therefor checks multiple. However, it was also realized that with the >>>>> multiple set of hash functions such situation is very unlikely to >>>>> occur. >>>>> >>>>> So, I could add the following note: >>>>> >>>>> "NOTE: An endpoint might choose to match each used certificate agains= t >>>>> fingerprints calculated using multiple >>>>> hash functions e.g, if the endpoint is unsure which hash function is >>>>> the strongest." >>>>> >>>> >>>> In retrospect, I have to question that motivation. Is it that hard to >>>> figure out? It seems like if you have two hash functions that are >>>> reasonably equal, an implementation could just pick one. >>>> >>>> >>>>> ...or we could simply delete the text. I personally would go for that= , >>>>> but in case others want to keep it I have no problem with that. >>>>> >>>> >>>> Given that this has caused confusion at every step, I support removing >>>> the text. >>>> >>> >>> ISTM that the main point here is: *if* the recipient happens to check >>> more than one hash, a failure of any one of them is to be considered an >>> overall failure, rather than a success of one and a failure of another >>> being considered a success. >>> >> >> The question was WHY an endpoint would check more than one hash function >> to begin with, and the only reason we have came up with is if the endpoi= nt >> doesn=C2=B9t =C2=B3know" which is the strongest hash - which sounds a li= ttle weird. >> > > I don't see why we need to know why. Maybe they intend to try them all, > just for completeness. > > But if there is ever a question about the validity of an implementation, = I > don't want to be arguing with somebody who says: > > "I tried them all, and several failed but one succeeded so I decided it > must be ok." > What we are trying to say is: There MUST be a fingerprint matching the used certificate for each hash algorithm present. End point SHOULD pick a set of one or more preferred hash functions that should be checked to satisfy end point's security requirements. Unless there is a matching fingerprint for each tested hash function, the endpoint MUST NOT establish the TLS connection. It is recommended that a single matching SHA-256 fingerprint should be sufficient to verify the certificate. Think of this as personal ID. You need one photo ID to get on the plain, but bank will ask for two forms of ID before giving you money. _____________ Roman Shpount --001a114d7daa33e2d805478fc435 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 2, 2017 at 12:15 PM, Paul Kyzivat <paul.kyzivat@co= mcast.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
On 2/2/17 3:28 AM, Christer Holmberg wrote:
Hi Paul,

-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Section 5.1 says:

=C2=A0"An endpoint MAY, in addition to its more preferred hash functio= n,
=C2=A0 also verify that each certificate used matches fingerprints
=C2=A0 calculated using other hash functions.=C2=A0 Unless there is a match= ing
=C2=A0 fingerprint for each tested hash function, the endpoint MUST NOT
=C2=A0 establish the TLS connection."

This seems a little weird to me. It's up to the endpoint to decide
whether to check for errors, and then if it
does find an error it can't setup the connection, whereas if it just hadn't checked it would be able to setup
the connection. I think it would help to explain why an endpoint
would be motivated to check multiple fingerprints.

I think the only use-case that came up was a situation where the
receiver is not sure which hash function is the "strongest", and<= br> therefor checks multiple. However, it was also realized that with the
multiple set of hash functions such situation is very unlikely to
occur.

So, I could add the following note:

"NOTE: An endpoint might choose to match each used certificate against=
fingerprints calculated using multiple
hash functions e.g, if the endpoint is unsure which hash function is
the strongest."

In retrospect, I have to question that motivation. Is it that hard to
figure out? It seems like if you have two hash functions that are
reasonably equal, an implementation could just pick one.


...or we could simply delete the text. I personally would go for that,
but in case others want to keep it I have no problem with that.

Given that this has caused confusion at every step, I support removing
the text.

ISTM that the main point here is: *if* the recipient happens to check
more than one hash, a failure of any one of them is to be considered an
overall failure, rather than a success of one and a failure of another
being considered a success.

The question was WHY an endpoint would check more than one hash function to begin with, and the only reason we have came up with is if the endpoint<= br> doesn=C2=B9t =C2=B3know" which is the strongest hash - which sounds a = little weird.

I don't see why we need to know why. Maybe they intend to try them all,= just for completeness.

But if there is ever a question about the validity of an implementation, I = don't want to be arguing with somebody who says:

"I tried them all, and several failed but one succeeded so I decided i= t must be ok."

What we are trying = to say is:

There MUST be a fingerprint matching th= e used certificate for each hash algorithm present. End point SHOULD pick a= set of one or more preferred hash functions that should be checked to sati= sfy end point's security requirements. Unless there is a matching finge= rprint for each tested hash function, the endpoint MUST NOT establish the T= LS connection. It is recommended that a single matching SHA-256 fingerprint= should be sufficient to verify the certificate.

T= hink of this as personal ID. You need one photo ID to get on the plain, but= bank will ask for two forms of ID before giving you money.
_____________
Roman Shpount
= =C2=A0
--001a114d7daa33e2d805478fc435-- From nobody Thu Feb 2 10:01:47 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A721294D6 for ; Thu, 2 Feb 2017 10:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 a1IAZkChNmWO for ; Thu, 2 Feb 2017 10:01:43 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1870B129978 for ; Thu, 2 Feb 2017 10:00:38 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v12I0a39090185 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 2 Feb 2017 12:00:37 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Christer Holmberg" Date: Thu, 02 Feb 2017 12:00:35 -0600 Message-ID: In-Reply-To: References: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFD8EB8@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_6D57CB39-84FE-42FA-B289-889766E78F83_=" Embedded-HTML: [{"HTML":[536, 8936], "plain":[140, 5396], "uuid":"DE6FCB6E-6130-4F6B-B5DA-0BC134189919"}] X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , Flemming Andreasen , IESG , "draft-ietf-mmusic-4572-update@ietf.org" Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 18:01:45 -0000 --=_MailMate_6D57CB39-84FE-42FA-B289-889766E78F83_= Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable That looks good to me. Please submit a new revision when you are ready. Thanks! Ben. On 2 Feb 2017, at 6:49, Christer Holmberg wrote: > Pull request: https://github.com/fluffy/4572bis/pull/14 > > Regards, > > Christer > > From: Christer Holmberg = > >= > Date: Thursday 2 February 2017 at 13:43 > To: Roman Shpount > > Cc: "alissa@cooperw.in" = > >, Flemming Andreasen = > >, = > "mmusic-chairs@ietf.org" = > >, = > "draft-ietf-mmusic-4572-update@ietf.org" = > >, = > "iesg@ietf.org" = > >, = > "mmusic@ietf.org" = > > > Subject: Re: [MMUSIC] Alissa Cooper's No Objection on = > draft-ietf-mmusic-4572-update-12: (with COMMENT) > Resent-From: > > Resent-To: Christer Holmberg = > >= , = > Jonathan Lennox > > Resent-Date: Thursday 2 February 2017 at 13:43 > > Hi, > > Ok, it seems like there is stronger preference for removing the text, = > and nobody has objected. > > So, I will remove the text in the next version of the document. > > Regards, > > Christer > > From: Roman Shpount > > Date: Wednesday 1 February 2017 at 22:34 > To: Christer Holmberg = > >= > Cc: "alissa@cooperw.in" = > >, Flemming Andreasen = > >, = > "mmusic-chairs@ietf.org" = > >, = > "draft-ietf-mmusic-4572-update@ietf.org" = > >, = > "iesg@ietf.org" = > >, = > "mmusic@ietf.org" = > > > Subject: Re: [MMUSIC] Alissa Cooper's No Objection on = > draft-ietf-mmusic-4572-update-12: (with COMMENT) > > I am for removing the text. > > _____________ > Roman Shpount > > On Wed, Feb 1, 2017 at 3:18 PM, Christer Holmberg = > >= = > wrote: > Does anyone object to deleting the text? Martin? Ekr? Roman? Cullen? > > Regards, > > Christer > > -----Original Message----- > From: Alissa Cooper = > [mailto:alissa@cooperw.in] > Sent: 01 February 2017 22:15 > To: Christer Holmberg = > >= > Cc: IESG >; = > draft-ietf-mmusic-4572-update@ietf.org; = > Flemming Andreasen >; = > mmusic-chairs@ietf.org; = > mmusic@ietf.org > Subject: Re: Alissa Cooper's No Objection on = > draft-ietf-mmusic-4572-update-12: (with COMMENT) > > >> On Feb 1, 2017, at 3:04 PM, Christer Holmberg = >> = > = >> wrote: >> >> Hi Alissa, >> >> Thank you for your review! See below. >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >>> Section 5.1 says: >>> >>> "An endpoint MAY, in addition to its more preferred hash function, >>> also verify that each certificate used matches fingerprints >>> calculated using other hash functions. Unless there is a matching >>> fingerprint for each tested hash function, the endpoint MUST NOT >>> establish the TLS connection." >>> >>> This seems a little weird to me. It's up to the endpoint to decide >>> whether to check for errors, and then if it does find an error it >>> can't setup the connection, whereas if it just hadn't checked it = >>> would be able to setup the connection. I think it would help to = >>> explain why an endpoint would be motivated to check multiple = >>> fingerprints. >> >> I think the only use-case that came up was a situation where the = >> receiver is not sure which hash function is the "strongest", and = >> therefor checks multiple. However, it was also realized that with the = >> multiple set of hash functions such situation is very unlikely to = >> occur. >> >> So, I could add the following note: >> >> "NOTE: An endpoint might choose to match each used certificate = >> against >> fingerprints calculated using multiple hash functions e.g, if the = >> endpoint is unsure which hash function is the strongest." >> >> ...or we could simply delete the text. I personally would go for = >> that, but in case others want to keep it I have no problem with that. > > It would make more sense to me to delete it but either solution would = > be an improvement I think. > > Thanks, > Alissa > >> >> Regards, >> >> Christer >> >> > > _______________________________________________ > 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 --=_MailMate_6D57CB39-84FE-42FA-B289-889766E78F83_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">That looks good to me. Please submit a new revision when y= ou are ready.

Thanks!

Ben.

On 2 Feb 2017, at 6:49, Christer Holmberg wrote:


Regards,

Christer

From: Christer Holmberg <christer.holmberg@ericsson.c= om>
Date: Thursday 2 February 2017 at= 13:43
To: Roman Shpount <roman@telurix.com>
Cc: "alissa@cooperw.in" <alissa@cooperw.in>, Flemming Andreasen <fandreas@cisco.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org= >, "dra= ft-ietf-mmusic-4572-update@ietf.org" <draft-ietf-mmusic-4572-update@ietf.org= >, "iesg@ietf.org" <iesg@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Alissa Coop= er's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT)
= Resent-From: <alias-bounces@ietf.org>
Resent-To: Christer Holmberg <= christer.holmberg@erics= son.com>, Jonathan Lennox <jonathan@vidyo.com>
Resent-Date: Thursday 2 February = 2017 at 13:43

Hi,

Ok, it seems like there is stronger preference for removing the text= , and nobody has objected.

So, I will remove the text in the next version of the document.

Regards,

Christer

From: Roman Shpount <roman@telurix.com>
Date: Wednesday 1 February 2017 a= t 22:34
To: Christer Holmberg <christer.holmberg@ericsson.com= >
Cc: "alissa@cooperw.in" <alissa@cooperw.in>, Flemming Andreasen <fandreas@cisco.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org= >, "dra= ft-ietf-mmusic-4572-update@ietf.org" <draft-ietf-mmusic-4572-update@ietf.org= >, "iesg@ietf.org" <iesg@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Alissa Coop= er's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT)
=

I am for removing the text. 

_______= ______
Roman Shpount

On Wed, Feb 1, 2017 at 3:18 PM, Christer Holmb= erg <c= hrister.holmberg@ericsson.com> wrote:
Does anyone object to deleting the text? Martin? Ekr? Roman? Cullen?

Regards,

Christer

-----Original Message-----
From: Alissa Cooper [mailto:alissa@c= ooperw.in]
Sent: 01 February 2017 22:15
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: IESG <iesg@ietf.org>; draft-ietf-mmusic-4572-update@ietf.org; Flemming Andreasen <<= a href=3D"mailto:fandreas@cisco.com">fandreas@cisco.com>; mmusic-chairs@ietf.org; mmusic@ietf.org
Subject: Re: Alissa Cooper's No Objection on draft-ietf-mmusic-4572-updat= e-12: (with COMMENT)


> On Feb 1, 2017, at 3:04 PM, Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:
>
> Hi Alissa,
>
> Thank you for your review! See below.
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>> Section 5.1 says:
>>
>> "An endpoint MAY, in addition to its more preferred hash fu= nction,
>> also verify that each certificate used matches fingerprints
>> calculated using other hash functions.  Unless there is a m= atching
>> fingerprint for each tested hash function, the endpoint MUST NOT=
>> establish the TLS connection."
>>
>> This seems a little weird to me. It's up to the endpoint to deci= de
>> whether to check for errors, and then if it does find an error i= t
>> can't setup the connection, whereas if it just hadn't checked it= would be able to setup the connection. I think it would help to explain = why an endpoint would be motivated to check multiple fingerprints.
>
> I think the only use-case that came up was a situation where the rec= eiver is not sure which hash function is the "strongest", and t= herefor checks multiple. However, it was also realized that with the mult= iple set of hash functions such situation is very unlikely to occur.
>
> So, I could add the following note:
>
> "NOTE: An endpoint might choose to match each used certificate = against
> fingerprints calculated using multiple hash functions e.g, if the en= dpoint is unsure which hash function is the strongest."
>
> ...or we could simply delete the text. I personally would go for tha= t, but in case others want to keep it I have no problem with that.

It would make more sense to me to delete it but either solution would be = an improvement I think.

Thanks,
Alissa

>
> Regards,
>
> Christer
>
>

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

--=_MailMate_6D57CB39-84FE-42FA-B289-889766E78F83_=-- From nobody Thu Feb 2 12:09:46 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 095141294E6; Thu, 2 Feb 2017 12:09:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148606618203.13969.16563621294955094011.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2017 12:09:42 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-4572-update-13.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 20:09:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Connection-Oriented Media Transport over TLS in SDP Authors : Jonathan Lennox Christer Holmberg Filename : draft-ietf-mmusic-4572-update-13.txt Pages : 17 Date : 2017-02-02 Abstract: This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document obsoletes RFC 4572, by clarifying the usage of multiple fingerprints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-4572-update-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-4572-update-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 nobody Thu Feb 2 12:24:17 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA68129AA0 for ; Thu, 2 Feb 2017 12:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 o6uBtsefuOUl for ; Thu, 2 Feb 2017 12:24:13 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D37C129A96 for ; Thu, 2 Feb 2017 12:24:04 -0800 (PST) X-AuditID: c1b4fb30-13a0498000007085-e0-589395637161 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 9E.43.28805.36593985; Thu, 2 Feb 2017 21:24:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0319.002; Thu, 2 Feb 2017 21:23:04 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer Thread-Index: AQHSbZSn9K1k6WISUEK9WxSL0te/qqE2tQSAgB+TOeA= Date: Thu, 2 Feb 2017 20:23:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFE0DBC@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BFE0DBCESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7h27y1MkRBp83ilpMXf6YxWLGhanM DkweS5b8ZPK4NaUggCmKyyYlNSezLLVI3y6BK+P/vB9MBW3nGCsunl7L3MB45gRjFyMnh4SA iUT3hC+sXYxcHEIC6xglbu5YB+UsYpSY/O8aexcjBwebgIVE9z9tkAYRAVWJv98nM4GEmQXU Ja4uDgIJCwuUSizdBjFTRKBMYvrbJ+wQtpXEs29rWUBsFgEViesP74DFeQV8JZ587GSDWNXE KPFgxgmwIk6BQInHv48xgdiMAmIS30+tAbOZBcQlbj2ZzwRxtIDEkj3nmSFsUYmXj/+xQthK Eotuf4aqz5f41/IRapmgxMmZT1gmMIrMQjJqFpKyWUjKZoG9pimxfpc+RImixJTuh+wQtoZE 65y57MjiCxjZVzGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIExtXBLb8NdjC+fO54iFGAg1GJ h3dD4+QIIdbEsuLK3EOMEhzMSiK8E5uBQrwpiZVVqUX58UWlOanFhxilOViUxHnNVt4PFxJI TyxJzU5NLUgtgskycXBKNTAGBgUuKcvuaoy5m56f07k/VY7hOYOW9Qb/S3E3TSUMJRxtVyQe c1A93uzKVsRWsXBO0ZeIORP0j10Q/Ge5Ta5R4amkWImHzlreWLcj2+1ftnnGhmzuqXWa+Hj6 2uO3TuzIryk9/vngv/wcmZj5n4Ldu9YufinGtHyDoLSt0JHH6a777XrMJZRYijMSDbWYi4oT ASYJeVqnAgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 20:24:15 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BFE0DBCESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkJhc2VkIG9uIHRoZSBmZWVkYmFjaywgbXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBt b3ZlIGZvcndhcmQgd2l0aCBBTFQgIzIuDQoNCk5vdywgYXMgSSBzYWlkIGVhcmxpZXIsIHRoYXQg c3RpbGwgZG9lc27igJl0IHByZXZlbnQgcHJvdG9jb2xzIGZyb20gc3BlY2lmeWluZyBhbiBNSVQg dHJhbnNwb3J0LCB3aGljaCBpcyB1c2VkIGFzIGRlZmF1bHQgY2FuZGlkYXRlIChyZWFkOiBBTFQg IzEpLg0KDQpSZWdhcmRpbmcgZG9jdW1lbnRhdGlvbiwgSSBndWVzcyBpdCB3b3VsZCBhdCBsZWFz dCBoYXZlIGltcGFjdCBvbiBJQ0UtU0RQLiBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciBzb21ldGhp bmcgaXMgbmVlZGVkIGZvciAzMjY0Pw0KDQpDaGFpcnM/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCkZyb206IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6 IDEzIEphbnVhcnkgMjAxNyAyMTowOQ0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W01NVVNJQ10gU0lQLVNEUDogVmVyaWZ5IGRlY2lzaW9uIG1hZGUgaW4gU2VvdWwgcmVnYXJkaW5n IG5vbi1zdXBwb3J0ZWQgdHJhbnNwb3J0IGluIG0tIGxpbmUgb2YgYW5zd2VyDQoNCkFzIEkgaGF2 ZSBtZW50aW9uZWQgYmVmb3JlLCBJIHRoaW5rIEFMVCMxIGlzIGEgYmV0dGVyIG9wdGlvbjogSWYg d2UgcHJvcG9zZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IFVEUCBiYXNlZCBwcm90b2NvbCBmb3Ig ZWFjaCB0cmFuc3BvcnQgZmFtaWx5LCBvbmx5IHVzZSB0aGUgbWFuZGF0b3J5IHRvIGltcGxlbWVu dCBwcm90b2NvbCBmb3IgdGhlIGRlZmF1bHQgY2FuZGlkYXRlLCBhbmQgdGhlIHRyYW5zcG9ydCBt aXNtYXRjaCBwcm9ibGVtIHdpbGwgbmV2ZXIgb2NjdXIuDQoNCkFzIGEgYml0IG9mIGJhY2tncm91 bmQsIHRoaXMgaXNzdWUgYXBwZWFyZWQgYmVjYXVzZSBvZiBUQ1AvQkZDUCwgd2hpY2ggd2FzIGFz c3VtZWQgdG8gYmUgdGhlIGRlZmF1bHQgcHJvdG9jb2wgZm9yIEJGQ1Agd2l0aCBJQ0UuIFNpbmNl IHRoZW4sIEkgdGhpbmsgd2UgaGF2ZSBkZWNpZGVkIHRoYXQgVENQL0JGQ1AgaXMgbm90IGdvaW5n IHRvIGJlIHVzZWQgd2l0aCBJQ0UuIEZvciBhbGwgdGhlIG90aGVyIHByb3RvY29scyB0aGF0IEkg a25vdyAoVURQL0RUTFMvU0NUUCwgVURQL1RMUy9SVFAvU0FWUEYsIFVEUC9EVExTL0JGQ1AsIFJU UC9BVlAsIGV0YykgdGhlcmUgaXMgYSBjbGVhciBwcmVmZXJlbmNlIHRoYXQgVURQIGJhc2VkIHBy b3RvY29sIHNob3VsZCBiZSB1c2VkIGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4gSSBhbHNv IGRvIG5vdCBzZWUgYSB1c2UgY2FzZSB3aGljaCB3aWxsIHJlcXVpcmUgdGhhdCBvbmx5IHRjcCBi YXNlZCBjYW5kaWRhdGVzIHdvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSBvZmZlciBvciB0aGUgYW5z d2VyLiBCZWNhdXNlIG9mIHRoaXMsIEkgdGhpbmsgbWFuZGF0b3J5IHRvIGltcGxlbWVudCB0cmFu c3BvcnQgaXMgYSBiZXR0ZXIgYXBwcm9hY2guDQoNClRoaXMgYWxzbyBoYXZlIGFkZGl0aW9uYWwg YmVuZWZpdHMgb2Y6DQoNCjEuIFByb3ZpZGluZyBtPSBhbmQgYz0gbGluZSBpbmZvcm1hdGlvbiB3 aGljaCB3aWxsIG5vdCBjYXVzZSB0aGUgSUNFIG1pc21hdGNoIHdpdGggb2xkZXIgaW1wbGVtZW50 YXRpb25zDQoyLiBOb3Qgc3VwcGx5aW5nIGFueSBvbiB0aGUgcGF0aCBzaWduYWxpbmcgZGV2aWNl cyB3aXRoIGJvZ3VzIGFkZHJlc3MgaW5mb3JtYXRpb24gcmVxdWlyZWQgaW4gQUxUIzIgYW5zd2Vy DQozLiBJbXByb3ZlcyBnZW5lcmFsIGNoYW5jZXMgb2YgbmVnb3RpYXRpb24gc3VjY2VlZGluZyB3 aXRoIGVuZCBwb2ludHMgbm90IHN1cHBvcnRpbmcgSUNFIGJ5IHBpY2tpbmcgdGhlIHByb3RvY29s IG1vcmUgbGlrZWx5IHRvIHN1Y2NlZWQgKGNoYW5jZSBvZiBUQ1AvUlRQL0FWUCBzdWNjZWVkaW5n LCBmb3IgaW5zdGFuY2UsIGFyZSBtdWNoIGxvd2VyIHRoZW4gUlRQL0FWUCkuDQoNClJlZ2FyZHMs DQoNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24gRnJpLCBKYW4gMTMsIDIwMTcg YXQgNzowMCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpUaGUg c3ViamVjdCBzaGFsbCBiZSBJQ0UtU0RQOiBWZXJpZnkgZGVjaXNpb24gbWFkZeKApg0KDQpGcm9t OiBtbXVzaWMgPG1tdXNpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptbXVzaWMtYm91bmNlc0Bp ZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+Pg0K RGF0ZTogRnJpZGF5IDEzIEphbnVhcnkgMjAxNyBhdCAxMzozMg0KVG86ICJtbXVzaWNAaWV0Zi5v cmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4iIDxtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNp Y0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbTU1VU0lDXSBTSVAtU0RQOiBWZXJpZnkgZGVjaXNpb24g bWFkZSBpbiBTZW91bCByZWdhcmRpbmcgbm9uLXN1cHBvcnRlZCB0cmFuc3BvcnQgaW4gbS0gbGlu ZSBvZiBhbnN3ZXINCg0KSGksDQoNCkluIFNlb3VsIHdlIGRpc2N1c3NlZCBhIG51bWJlciBvZiBp c3N1ZXMgcmVsYXRlZCB0byBJQ0UtU0RQLiBXZSBtYWRlIHNvbWUgZGVjaXNpb25zLCBhbmQgSSBn b3QgYWN0aW9uIHBvaW50cyB0byB2ZXJpZnkgb25lIG9mIHRob3NlIG9uIHRoZSBsaXN0Lg0KDQpU aGUgYXNzb2NpYXRlZCBzbGlkZXMgY2FuIGJlIGZvdW5kIGhlcmU6DQoNCmh0dHBzOi8vd3d3Lmll dGYub3JnL3Byb2NlZWRpbmdzLzk3L3NsaWRlcy9zbGlkZXMtOTctbW11c2ljLWljZS1zaXAtc2Rw LTAwLnBkZg0KDQoNClRoZSBpc3N1ZSAoc2xpZGVzIDQtNikgd2FzIHdoZW4gYW4gYW5zd2VyZXIg cmVjZWl2ZXMgYW4gb2ZmZXIgd2l0aCBhIG0tIGxpbmUgdHJhbnNwb3J0IHRoYXQgaXQgZG9lc27i gJl0IHN1cHBvcnQuIFRoZSBjdXJyZW50IE8vQSBydWxlcyBzYXkgdGhhdCB0aGUgdHJhbnNwb3J0 IGluIHRoZSBhbnN3ZXIgbXVzdCBtYXRjaCB0aGUgdHJhbnNwb3J0IGluIHRoZSBvZmZlci4NCg0K SG93ZXZlciwgaWYgSUNFIGlzIHVzZWQsIHRoZXJlIG1heSBiZSB0cmFuc3BvcnRzIChvZmZlcmVk IHVzaW5nIElDRSBjYW5kaWRhdGVzKSB0aGF0IHRoZSBhbnN3ZXJlciBET0VTIHN1cHBvcnQuDQoN CkJhc2VkIG9uIHRoZSBkaXNjdXNzaW9ucywgdGhlcmUgd2FzIHN0cm9uZyBjb25zZW5zdXMgdG8g Z28gZm9yIEFsdCMyLCB3aGljaCB3YXMgYWxsb3dpbmcgYSB0cmFuc3BvcnQgaW4gdGhlIG0tIGxp bmUgb2YgdGhlIGFuc3dlciBldmVuIGlmIHRoZSBhbnN3ZXJlciBkb2VzbuKAmXQgc3VwcG9ydCBp dCwgYXMgSUNFIGNhbmRpZGF0ZXMgd2lsbCBiZSB1c2VkIHRvIGRldGVybWluZSB0aGUgdHJhbnNw b3J0Lg0KDQpEb2VzIGFueW9uZSBvYmplY3QgdG8gQWx0IzI/DQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5v cmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbW11c2ljDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B4BFE0DBCESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5CYXNlZCBvbiB0aGUgZmVlZGJhY2ssIG15IHN1Z2dlc3Rpb24gd291 bGQgYmUgdG8gbW92ZSBmb3J3YXJkIHdpdGggQUxUICMyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Tm93LCBhcyBJIHNhaWQgZWFybGllciwgdGhhdCBzdGlsbCBkb2Vz buKAmXQgcHJldmVudCBwcm90b2NvbHMgZnJvbSBzcGVjaWZ5aW5nIGFuIE1JVCB0cmFuc3BvcnQs IHdoaWNoIGlzIHVzZWQgYXMgZGVmYXVsdCBjYW5kaWRhdGUgKHJlYWQ6DQogQUxUICMxKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZGluZyBkb2N1bWVudGF0 aW9uLCBJIGd1ZXNzIGl0IHdvdWxkIGF0IGxlYXN0IGhhdmUgaW1wYWN0IG9uIElDRS1TRFAuIFRo ZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHNvbWV0aGluZyBpcyBuZWVkZWQgZm9yIDMyNjQ/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaGFpcnM/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gMTMgSmFudWFyeSAyMDE3IDIxOjA5PGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBI b2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gbW11c2ljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBT SVAtU0RQOiBWZXJpZnkgZGVjaXNpb24gbWFkZSBpbiBTZW91bCByZWdhcmRpbmcgbm9uLXN1cHBv cnRlZCB0cmFuc3BvcnQgaW4gbS0gbGluZSBvZiBhbnN3ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BcyBJIGhhdmUgbWVudGlvbmVkIGJlZm9yZSwgSSB0aGluayBBTFQj MSBpcyBhIGJldHRlciBvcHRpb246IElmIHdlIHByb3Bvc2UgbWFuZGF0b3J5IHRvIGltcGxlbWVu dCBVRFAgYmFzZWQgcHJvdG9jb2wgZm9yIGVhY2ggdHJhbnNwb3J0IGZhbWlseSwgb25seSB1c2Ug dGhlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgcHJvdG9jb2wgZm9yIHRoZSBkZWZhdWx0IGNhbmRp ZGF0ZSwgYW5kIHRoZSB0cmFuc3BvcnQgbWlzbWF0Y2gNCiBwcm9ibGVtIHdpbGwgbmV2ZXIgb2Nj dXIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBhIGJp dCBvZiBiYWNrZ3JvdW5kLCB0aGlzIGlzc3VlIGFwcGVhcmVkIGJlY2F1c2Ugb2YgVENQL0JGQ1As IHdoaWNoIHdhcyBhc3N1bWVkIHRvIGJlIHRoZSBkZWZhdWx0IHByb3RvY29sIGZvciBCRkNQIHdp dGggSUNFLiBTaW5jZSB0aGVuLCBJIHRoaW5rIHdlIGhhdmUgZGVjaWRlZCB0aGF0IFRDUC9CRkNQ IGlzIG5vdCBnb2luZyB0byBiZSB1c2VkIHdpdGggSUNFLiBGb3IgYWxsIHRoZSBvdGhlciBwcm90 b2NvbHMNCiB0aGF0IEkga25vdyAoVURQL0RUTFMvU0NUUCwgVURQL1RMUy9SVFAvU0FWUEYsIFVE UC9EVExTL0JGQ1AsIFJUUC9BVlAsIGV0YykgdGhlcmUgaXMgYSBjbGVhciBwcmVmZXJlbmNlIHRo YXQgVURQIGJhc2VkIHByb3RvY29sIHNob3VsZCBiZSB1c2VkIGZvciBiYWNrd2FyZHMgY29tcGF0 aWJpbGl0eS4gSSBhbHNvIGRvIG5vdCBzZWUgYSB1c2UgY2FzZSB3aGljaCB3aWxsIHJlcXVpcmUg dGhhdCBvbmx5IHRjcCBiYXNlZCBjYW5kaWRhdGVzIHdvdWxkDQogYmUgaW5jbHVkZWQgaW4gdGhl IG9mZmVyIG9yIHRoZSBhbnN3ZXIuIEJlY2F1c2Ugb2YgdGhpcywgSSB0aGluayBtYW5kYXRvcnkg dG8gaW1wbGVtZW50IHRyYW5zcG9ydCBpcyBhIGJldHRlciBhcHByb2FjaC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBhbHNvIGhhdmUg YWRkaXRpb25hbCBiZW5lZml0cyBvZjombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gUHJvdmlkaW5nIG09IGFuZCBjPSBsaW5lIGlu Zm9ybWF0aW9uIHdoaWNoIHdpbGwgbm90IGNhdXNlIHRoZSBJQ0UgbWlzbWF0Y2ggd2l0aCBvbGRl ciBpbXBsZW1lbnRhdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjIuIE5vdCBzdXBwbHlpbmcgYW55IG9uIHRoZSBwYXRoIHNpZ25hbGluZyBk ZXZpY2VzIHdpdGggYm9ndXMgYWRkcmVzcyBpbmZvcm1hdGlvbiByZXF1aXJlZCBpbiBBTFQjMiBh bnN3ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjMuIEltcHJvdmVzIGdlbmVyYWwgY2hhbmNlcyBvZiBuZWdvdGlhdGlvbiBzdWNjZWVkaW5nIHdp dGggZW5kIHBvaW50cyBub3Qgc3VwcG9ydGluZyBJQ0UgYnkgcGlja2luZyB0aGUgcHJvdG9jb2wg bW9yZSBsaWtlbHkgdG8gc3VjY2VlZCAoY2hhbmNlIG9mIFRDUC9SVFAvQVZQIHN1Y2NlZWRpbmcs IGZvciBpbnN0YW5jZSwgYXJlIG11Y2ggbG93ZXIgdGhlbiBSVFAvQVZQKS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy IGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKYW4gMTMsIDIwMTcgYXQg NzowMCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+VGhlIHN1YmplY3Qgc2hhbGwgYmUgSUNFLVNEUDogVmVyaWZ5IGRlY2lzaW9uIG1hZGXi gKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPm1tdXNpYyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1t dXNpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9 Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5j aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5G cmlkYXkgMTMgSmFudWFyeSAyMDE3IGF0IDEzOjMyPGJyPg0KPGI+VG86IDwvYj4mcXVvdDs8YSBo cmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYu b3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltN TVVTSUNdIFNJUC1TRFA6IFZlcmlmeSBkZWNpc2lvbiBtYWRlIGluIFNlb3VsIHJlZ2FyZGluZyBu b24tc3VwcG9ydGVkIHRyYW5zcG9ydCBpbiBtLSBsaW5lIG9mIGFuc3dlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkluIFNlb3VsIHdlIGRp c2N1c3NlZCBhIG51bWJlciBvZiBpc3N1ZXMgcmVsYXRlZCB0byBJQ0UtU0RQLiBXZSBtYWRlIHNv bWUgZGVjaXNpb25zLCBhbmQgSSBnb3QgYWN0aW9uIHBvaW50cyB0byB2ZXJpZnkgb25lIG9mIHRo b3NlIG9uIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgYXNzb2NpYXRlZCBzbGlkZXMgY2FuIGJl IGZvdW5kIGhlcmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3By b2NlZWRpbmdzLzk3L3NsaWRlcy9zbGlkZXMtOTctbW11c2ljLWljZS1zaXAtc2RwLTAwLnBkZiIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3L3NsaWRl cy9zbGlkZXMtOTctbW11c2ljLWljZS1zaXAtc2RwLTAwLnBkZjwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgaXNzdWUgKHNsaWRlcyA0LTYp IHdhcyB3aGVuIGFuIGFuc3dlcmVyIHJlY2VpdmVzIGFuIG9mZmVyIHdpdGggYSBtLSBsaW5lIHRy YW5zcG9ydCB0aGF0IGl0IGRvZXNu4oCZdCBzdXBwb3J0LiBUaGUgY3VycmVudCBPL0EgcnVsZXMg c2F5IHRoYXQgdGhlIHRyYW5zcG9ydCBpbg0KIHRoZSBhbnN3ZXIgbXVzdCBtYXRjaCB0aGUgdHJh bnNwb3J0IGluIHRoZSBvZmZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SG93ZXZlciwgaWYgSUNFIGlzIHVzZWQs IHRoZXJlIG1heSBiZSB0cmFuc3BvcnRzIChvZmZlcmVkIHVzaW5nIElDRSBjYW5kaWRhdGVzKSB0 aGF0IHRoZSBhbnN3ZXJlciBET0VTIHN1cHBvcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkJhc2VkIG9uIHRoZSBk aXNjdXNzaW9ucywgdGhlcmUgd2FzIHN0cm9uZyBjb25zZW5zdXMgdG8gZ28gZm9yIEFsdCMyLCB3 aGljaCB3YXMgYWxsb3dpbmcgYSB0cmFuc3BvcnQgaW4gdGhlIG0tIGxpbmUgb2YgdGhlIGFuc3dl ciBldmVuIGlmIHRoZSBhbnN3ZXJlciBkb2VzbuKAmXQgc3VwcG9ydA0KIGl0LCBhcyBJQ0UgY2Fu ZGlkYXRlcyB3aWxsIGJlIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSB0cmFuc3BvcnQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPkRvZXMgYW55b25lIG9iamVjdCB0byBBbHQjMj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4BFE0DBCESESSMB209erics_-- From nobody Thu Feb 2 14:20:40 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9837F129A39 for ; Thu, 2 Feb 2017 14:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 F0D3sgVudeRr for ; Thu, 2 Feb 2017 14:20:03 -0800 (PST) Received: from smtp106.iad3a.emailsrvr.com (smtp106.iad3a.emailsrvr.com [173.203.187.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E391129A37 for ; Thu, 2 Feb 2017 14:20:03 -0800 (PST) Received: from smtp14.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id BDE902521B; Thu, 2 Feb 2017 17:19:57 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp14.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 09B9925214; Thu, 2 Feb 2017 17:19:56 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 02 Feb 2017 17:19:57 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Thu, 2 Feb 2017 15:19:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Magnus Westerlund , "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 22:20:06 -0000 > On Jan 31, 2017, at 10:43 AM, Jonathan Lennox = wrote: >=20 > In general, this looks good. >=20 > I have one question, however. What should happen if an RTP packet = (without a MID) is received for a stream that has an existing mapping to = an m=3D line, but whose PT is not valid for that m=3D line? >=20 > Should it > 1. Cause the stream=E2=80=99s mapping to be moved to another m=3D = line, if the received PT is in the payload type table for some other m=3D = line? > or=20 > 2. Be an error? Imagine a case where we have two sends call A and B and they each use = one PT that is unique and go to different m lines on receiver C via a = SFU. Initially C get a packet from B with a given SSRC and the PT and = creates a mapping for it. But imagine that A and B had an SSRC collision = which they sort that out and A ends up having the SSRC that B initially = used. If you don't have the PT override the SSRC, the packets are going = to go to the wrong m-line because the PT points at the m-line A is using = but the old SSRC incorrectly points at the m-line B is using.=20 To put this a different way, if the packet has a mid, I think it is very = clear the mid has to override the PT. Same for the PT. The mid is = effectively just an extended PT.=20 I'm not thinking to much about the case where SSRC is signalled in SDP = but ignoring that case for a second, I think the really easy thing to = specify, implement, and understand works is simply a priority order = where roughly=20 1) if you have mid, use that and latch the SSRC 2) if you have a unique pt, use that and latch the SSRC=20 3) if you have a latched SSRC use that=20 If you had signaled SSRC, guess I would insert that as step 1.5 of use = that=20 From nobody Thu Feb 2 14:25:22 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C3212957E; Thu, 2 Feb 2017 14:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyJYTFMcRNEW; Thu, 2 Feb 2017 14:25:15 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3696129A3C; Thu, 2 Feb 2017 14:19:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25030; q=dns/txt; s=iport; t=1486073995; x=1487283595; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LMqyjwby9ejCRfdfajLlDdiinvNN0vXLdQBnErDdCuo=; b=O1kcjkDcuJ/AEsUu4c9T2btgHU2yK+Otbzgi5MrfEuOEpnjCruu3HLc3 cyJWjRYg5reGHXUleGlNRkGhpd9zF2CTaY2IpmAlAqNY5kwd0P84X3B3L mj+XFT5vS+T8k0oo/BGhALn7ojopRZLBtEBVhIz509eui+hjbESNZn8gv c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAQD7r5NY/5xdJa1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMoK2GBCQeDCkaKCJILlTWCDR8LhS5KAhqCPT8YAQIBAQEBAQE?= =?us-ascii?q?BYiiEaQEBAQMBAQEKFxEzBwsFCQICAQYCGAICHwQDAgICGQwLFAEQAgQOBYlpC?= =?us-ascii?q?A6PA51OgiWLLAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFBYEGh0WCaoQlKBeCby6?= =?us-ascii?q?CMQWGWYIshjGFeoYtAYZne4IjgyGEYIF7iXqFDYgoil4BHziBSxUYIxEBhDIdG?= =?us-ascii?q?YFIdYd3gQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,326,1477958400"; d="scan'208";a="207573262" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2017 22:19:54 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v12MJrMr018742 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Feb 2017 22:19:54 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Feb 2017 17:19:53 -0500 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Thu, 2 Feb 2017 17:19:52 -0500 From: "Cullen Jennings (fluffy)" To: Magnus Westerlund Thread-Topic: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSfaJ5sVd9K8JGDU+bnDtTRZpMhQ== Date: Thu, 2 Feb 2017 22:19:52 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> In-Reply-To: <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="utf-8" Content-ID: <9A06325F7675CE4F89E5294AABE4600C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , "mmusic \(E-mail\)" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 22:25:17 -0000 DQpTbyBJIG11Y2ggcHJlZmVyIHRoZSBjdXJyZW50IHRleHQgYW5kIHRoaW5rIHRoZXJlIGFyZSBh IGJ1bmNoIG9mIHByb2JsZW1zIHdpdGggdGhpcyB0ZXh0LiBJZiB3ZSBhY3R1YWxseSBoYWQgZW1h aWxzIGV4cGxhaW5pbmcgd2hhdCBwcm9ibGVtcyBpbiB0aGUgY3VycmVudCB0ZXh0IHRoaXMgd2Fz IHRyeWluZyB0byBmaXgsIHdpdGggaW5kaXZpZHVhbCBQUnMgZm9yIHRob3NlLCB0aGlzIHdvdWxk IGJlIG11Y2ggZWFzaWVyIHRvIHJlc29sdmUgZWFjaCBvZiB0aGVtIGFuZCBnZXQgdGhlbSBmaXhl ZC4NCg0KMSkgd2UgaGF2ZSBiZWVuIHRyeWluZyB0byBhdm9pZCB0aGUgdXNlIG9mICJSVFAgc2Vz c2lvbiIgYXMgaXQgaGFzIGJlZW4gdmVyeSB1bmNsZWFyIHRvIGltcGxlbWVudG9ycyB3aGF0IGl0 IGlzLiBJIHRoaW5rIHRoaXMgd291bGQgYmUgYmV0dGVyIGlmIHdlIGNvdWxkIHJlcGhyYXNlIHRv IG5vdCB1c2UgdGhhdA0KDQoyKSBib3RoIHRoZSBwcm9wb3NlZCBhbmQgY3VycmVudCB0ZXh0IHNl ZW0gbGFja2luZyBpbiBkZWFsaW5nIHdpdGggbXVsdGlwbGUgYnVuZGxlIGdyb3VwcyANCg0KMykg U3RhdHMgYXJlIHR5cGljYWxseSBtYWludGFpbmVkIGJ5IHRoaW5ncyBhZnRlciB0aGUgcGFja2V0 IGlzIHJvdXRlZCAtIG5vdCBiZWZvcmUuIA0KDQo0KSBOZWVkIHRvIGV4cGxhaW4gaG93IHRoZSBT REVTIGluIGNvbXBvdW5kIFJUQ1AgY2F1c2VzIHVwZGF0ZXMgDQoNCjUpIGdpdmVuIHRoaXMgcmVt b3ZlcyB0aGUgb3V0Z29pbmcgU1NSQyB0YWJsZSwgbm90IGNsZWFyIGhvdyBpdCByb3V0ZXMgUlRD UCByZXBvcnRzLiBJIHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUgY2xhcmlmaWVkLiANCg0KNikgSSBk b24ndCB0aGluayBtb3N0IGltcGxlbWVudGVycyBhcmUgZ29pbmcgdG8gaGF2ZSBhIGNsdWUgd2hh dCB0byBkbyBmb3IgdGhlICJUaGlyZCBQYXJ0eSBUYXJnZXRlZCBSZXBvcnRzIG9yIEZlZWRiYWNr IiBzZWN0aW9uDQoNCkkgd2lsbCB0cnkgYW5kIHRha2UgeW91ciBQUiBhbmQgYnJlYWsgaXQgdXAg aW50byBzb21lIGJpdCBzaXplIHBpZWNlcyBzbyB3ZSBjYW4gdHJ5IGFuZCBzZWUgaWYgd2UgY2Fu IGdldCB0aGUgZWFzeSBvbmVzIG91dCBvZiB0aGUgd2F5IGFuZCBmb2N1cyBvbiB0aGUgcGFydHMg dGhhdCBhcmUga2V5IGNoYW5nZXMuIA0KDQoNCg0KPiBPbiBKYW4gMzAsIDIwMTcsIGF0IDY6MTgg QU0sIE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+IHdy b3RlOg0KPiANCj4gSGksDQo+IA0KPiBJIGhhdmUgbm93IGdlbmVyYXRlZCBhIHB1bGwgcmVxdWVz dCBmb3IgdGhpcyB0ZXh0LCB3aXRoIHNvbWUgdmVyeSBtaW5vciBjaGFuZ2VzLg0KPiANCj4gaHR0 cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9qc2VwL3B1bGwvNTM4DQo+IA0KPiBDaGVlcnMNCj4g DQo+IE1hZ251cw0KPiANCj4gRGVuIDIwMTctMDEtMjcga2wuIDE3OjQzLCBza3JldiBNYWdudXMg V2VzdGVybHVuZDoNCj4+IE1NVVNJQyBhbmQgUlRDV0VCLA0KPj4gDQo+PiBIZXJlIGlzIG5vdyBh IG1vcmUgY29tcGxldGUgdGV4dCBwcm9wb3NhbCB0aGF0IGFsc28gY29uc2lkZXJzIHRoZSBSVENQ Lg0KPj4gSXQgYWxzbyBnb2VzIGZ1cnRoZXIgdGhhbiB3aGF0IEFwcGVuZGl4IEIgZGVmaW5lcyBp biBvbmUgYXNwZWN0LCBuYW1lbHkNCj4+IGV4cGxpY2l0bHkgY29uc2lkZXJpbmcgdGhpcmQgcGFy dHkgUlRDUCByZXBvcnRpbmcgYW5kIHdoYXQgdG8gZG8gd2l0aCBpdC4NCj4+IA0KPj4gRmVlZGJh Y2sgaXMgbXVjaCBhcHByZWNpYXRlZC4gSSBwbGFuIHRvIHB1dCB0aGlzIGludG8gYSBQUiB0b3dh cmRzIEpTRVANCj4+IEFQUEVORElYIEIgb24gbW9uZGF5LiBJZiBvbmx5IHRvIGdldCB0aGUgSlNF UCBhdXRob3JzIGF0dGVudGlvbiA7LSkuDQo+PiBIb3dldmVyLCB0aGUgdGV4dCBpcyByZWFsbHkg aW50ZW5kZWQgZm9yIHRoZSBuZXh0IHZlcnNpb24gb2YgQlVORExFLg0KPj4gDQo+PiANCj4+IFgu ICBBc3NvY2lhdGluZyBSVFAvUlRDUCBXaXRoIENvcnJlY3QgU0RQIE1lZGlhIERlc2NyaXB0aW9u DQo+PiANCj4+ICAgQXMgZGVzY3JpYmVkIGluIFtSRkMzNTUwXSwgUlRQIHBhY2tldHMgYXJlIGFz c29jaWF0ZWQgd2l0aCBSVFANCj4+ICAgc3RyZWFtcyBbUkZDNzY1Nl0uICBFYWNoIFJUUCBzdHJl YW0gaXMgaWRlbnRpZmllZCBieSBhbiBTU1JDIHZhbHVlLA0KPj4gICBhbmQgZWFjaCBSVFAgcGFj a2V0IGNhcnJpZXMgYW4gU1NSQyB2YWx1ZSB0aGF0IGlzIHVzZWQgdG8gYXNzb2NpYXRlDQo+PiAg IHRoZSBwYWNrZXQgd2l0aCB0aGUgY29ycmVjdCBSVFAgc3RyZWFtLiAgUlRDUCBwYWNrZXRzIGFs c28gdXNlcyBTU1JDcw0KPj4gICB0byBpZGVudGlmeSBvbiB3aGljaCBSVFAgc3RyZWFtcyBhbnkg cmVwb3J0IG9yIGZlZWRiYWNrIHJlbGF0ZSB0by4NCj4+ICAgVGh1cywgYW4gUlRDUCBwYWNrZXQg d2lsbCBjb21tb25seSBjYXJyeSBtdWx0aXBsZSBTU1JDIHZhbHVlcywgYW5kDQo+PiAgIG1pZ2h0 IHRoZXJlZm9yZSBiZSBwcm92aWRpbmcgZmVlZGJhY2sgb3IgcmVwb3J0IG9uIG11bHRpcGxlIFJU UA0KPj4gICBzdHJlYW1zLg0KPj4gDQo+PiAgIEluIG9yZGVyIHRvIGJlIGFibGUgdG8gcHJvY2Vz cyByZWNlaXZlZCBSVFAvUlRDUCBwYWNrZXRzIGNvcnJlY3RseSBpdA0KPj4gICBtdXN0IGJlIHBv c3NpYmxlIHRvIGFzc29jaWF0ZSBhbiBSVFAgc3RyZWFtIHdpdGggdGhlIGNvcnJlY3QgIm09Ig0K Pj4gICBsaW5lLCBhcyB0aGUgIm09IiBsaW5lIGFuZCBTRFAgYXR0cmlidXRlcyBhc3NvY2lhdGVk IHdpdGggdGhlICJtPSINCj4+ICAgbGluZSBjb250YWluIGluZm9ybWF0aW9uIG5lZWRlZCB0byBw cm9jZXNzIHRoZSBwYWNrZXRzLg0KPj4gDQo+PiAgIEFzIGFsbCBSVFAgc3RyZWFtcyBhc3NvY2lh dGVkIHdpdGggYSBCVU5ETEUgZ3JvdXAgYXJlIHBhcnQgb2YgdGhlDQo+PiAgIHNhbWUgUlRQIHNl c3Npb24gYW5kIHVzaW5nIHRoZSBzYW1lIGFkZHJlc3M6cG9ydCBjb21iaW5hdGlvbiBmb3INCj4+ ICAgc2VuZGluZyBhbmQgcmVjZWl2aW5nIFJUUC9SVENQIHBhY2tldHMsIHRoZSBsb2NhbCBhZGRy ZXNzOnBvcnQNCj4+ICAgY29tYmluYXRpb24gY2Fubm90IGJlIHVzZWQgdG8gYXNzb2NpYXRlIGFu IFJUUCBzdHJlYW0gd2l0aCB0aGUNCj4+ICAgY29ycmVjdCAibT0iIGxpbmUuICBJbiBhZGRpdGlv biwgbXVsdGlwbGUgUlRQIHN0cmVhbXMgbWlnaHQgYmUNCj4+ICAgYXNzb2NpYXRlZCB3aXRoIHRo ZSBzYW1lICJtPSIgbGluZS4NCj4+IA0KPj4gICBBbHNvLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlv biAxMC4xLjEsIHRoZSBzYW1lIHBheWxvYWQgdHlwZSB2YWx1ZQ0KPj4gICBtaWdodCBiZSB1c2Vk IGJ5IG11bHRpcGxlIFJUUCBzdHJlYW1zLCBpbiB3aGljaCBjYXNlIHRoZSBwYXlsb2FkIHR5cGUN Cj4+ICAgdmFsdWUgY2Fubm90IGJlIHVzZWQgdG8gYXNzb2NpYXRlIGFuIFJUUCBzdHJlYW0gd2l0 aCB0aGUgY29ycmVjdCAibT0iDQo+PiAgIGxpbmUuICBIb3dldmVyLCB0aGVyZSBhcmUgY2FzZXMg d2hlcmUgZWFjaCAibT0iIGxpbmUgaGFzIHVuaXF1ZQ0KPj4gICBwYXlsb2FkIHR5cGUgdmFsdWVz LCBhbmQgdGhlbiB0aGUgcGF5bG9hZCB0eXBlIGNvdWxkIHNlcnZlIGFzDQo+PiAgIGluZGljYXRv ciB0byB0aGUgcmVsZXZhbnQgIm09IiBsaW5lIHRoZSBSVFAgc3RyZWFtIGlzIGFzc29jaWF0ZWQN Cj4+ICAgd2l0aC4NCj4+IA0KPj4gICBBbiBvZmZlcmVyIGFuZCBhbnN3ZXJlciBjYW4gaW5mb3Jt IGVhY2ggb3RoZXIgd2hpY2ggU1NSQyB2YWx1ZXMgdGhleQ0KPj4gICB3aWxsIHVzZSBmb3IgYW4g UlRQIHN0cmVhbSBieSB1c2luZyB0aGUgU0RQICdzc3JjJyBhdHRyaWJ1dGUNCj4+ICAgW1JGQzU1 NzZdLiAgSG93ZXZlciwgYW4gb2ZmZXJlciB3aWxsIG5vdCBrbm93IHdoaWNoIFNTUkMgdmFsdWVz IHRoZQ0KPj4gICBhbnN3ZXJlciB3aWxsIHVzZSB1bnRpbCB0aGUgb2ZmZXJlciBoYXMgcmVjZWl2 ZWQgdGhlIGFuc3dlciBwcm92aWRpbmcNCj4+IA0KPj4gDQo+PiANCj4+IE5hbWUgICAgICAgICAg ICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDMxLCAyMDE3ICAgICAgICAgICAgICAgICBbUGFnZSAy XQ0KPj4gDQo+PiBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQWJicmV2aWF0ZWQtVGl0bGUg ICAgICAgICAgICAgICBKYW51YXJ5IDIwMTcNCj4+IA0KPj4gDQo+PiAgIHRoYXQgaW5mb3JtYXRp b24uICBEdWUgdG8gdGhpcywgYmVmb3JlIHRoZSBvZmZlcmVyIGhhcyByZWNlaXZlZCB0aGUNCj4+ ICAgYW5zd2VyLCB0aGUgb2ZmZXJlciB3aWxsIG5vdCBiZSBhYmxlIHRvIGFzc29jaWF0ZSBhbiBS VFAgc3RyZWFtIHdpdGgNCj4+ICAgdGhlIGNvcnJlY3QgIm09IiBsaW5lIHVzaW5nIHRoZSBTU1JD IHZhbHVlIGFzc29jaWF0ZWQgd2l0aCB0aGUgUlRQDQo+PiAgIHN0cmVhbS4gIEluIGFkZGl0aW9u LCB0aGUgb2ZmZXJlciBhbmQgYW5zd2VyZXIgbWF5IHN0YXJ0IHVzaW5nIG5ldw0KPj4gICBTU1JD IHZhbHVlcyBtaWQtc2Vzc2lvbiwgd2l0aG91dCBpbmZvcm1pbmcgZWFjaCBvdGhlciB1c2luZyB0 aGUgU0RQDQo+PiAgICdzc3JjJyBhdHRyaWJ1dGUuDQo+PiANCj4+ICAgSW4gb3JkZXIgZm9yIGFu IG9mZmVyZXIgYW5kIGFuc3dlcmVyIHRvIGFsd2F5cyBiZSBhYmxlIHRvIGFzc29jaWF0ZQ0KPj4g ICBhbiBSVFAgc3RyZWFtIHdpdGggdGhlIGNvcnJlY3QgIm09IiBsaW5lLCB0aGUgb2ZmZXJlciBh bmQgYW5zd2VyZXINCj4+ICAgdXNpbmcgdGhlIEJVTkRMRSBleHRlbnNpb24gTVVTVCBzdXBwb3J0 IHRoZSBtZWNoYW5pc20gZGVmaW5lZCBpbg0KPj4gICBTZWN0aW9uIDE0LCB3aGVyZSB0aGUgb2Zm ZXJlciBhbmQgYW5zd2VyZXIgaW5jbHVkZXMgdGhlDQo+PiAgIGlkZW50aWZpY2F0aW9uLXRhZyAo cHJvdmlkZWQgYnkgdGhlIHJlbW90ZSBwZWVyKSBhc3NvY2lhdGVkIHdpdGggYW4NCj4+ICAgIm09 IiBsaW5lIGluIHRoZSBSVFAgU3RyZWFtcyBhbmQgaW4gUlRDUCBTREVTIHBhY2tldHMgcGFydCBv ZiBhDQo+PiAgIEJVTkRMRSBncm91cC4NCj4+IA0KPj4gICBUaGUgbWFwcGluZyBmcm9tIGFuIFNT UkMgdG8gYW4gaWRlbnRpZmljYXRpb24tdGFnIGlzIGNhcnJpZWQgaW4gUlRDUA0KPj4gICBTREVT IHBhY2tldHMgb3IgaW4gUlRQIGhlYWRlciBleHRlbnNpb25zIChTZWN0aW9uIDE0KS4gIFNpbmNl IGENCj4+ICAgY29tcG91bmQgUlRDUCBwYWNrZXQgY2FuIGNvbnRhaW4gbXVsdGlwbGUgUlRDUCBT REVTIHBhY2tldHMsIGFuZCBlYWNoDQo+PiAgIFJUQ1AgU0RFUyBwYWNrZXQgY2FuIGNvbnRhaW4g bXVsdGlwbGUgY2h1bmtzLCBhbiBSVENQIHBhY2tldCBjYW4NCj4+ICAgY29udGFpbiBzZXZlcmFs IFNTUkMgdG8gaWRlbnRpZmljYXRpb24tdGFnIG1hcHBpbmdzLiAgVGhlIG9mZmVyZXIgYW5kDQo+ PiAgIGFuc3dlcmVyIG1haW50YWluIHRhYmxlcyBtYXBwaW5nIFJUUCBzdHJlYW1zIGlkZW50aWZp ZWQgYnkgU1NSQyB0bw0KPj4gICAibT0iIGxpbmVzIGlkZW50aWZpZWQgYnkgdGhlIGlkZW50aWZp Y2F0aW9uLXRhZy4gIFRoZXNlIHRhYmxlcyBhcmUNCj4+ICAgdXBkYXRlZCBlYWNoIHRpbWUgbmV3 IGluZm9ybWF0aW9uIHRoYXQgYWZmZWN0cyBob3cgcGFja2V0cyBzaG91bGQgYmUNCj4+ICAgcHJv Y2Vzc2VkIGFuZCByb3V0ZWQgYXJlIHJlY2VpdmVkLg0KPj4gDQo+PiAgIFRvIHByZXBhcmUgZm9y IGRlbXVsdGlwbGV4aW5nIFJUUCBzdHJlYW1zIHRvIHRoZSBjb3JyZWN0ICJtPSIgbGluZSwNCj4+ ICAgdGhlIGZvbGxvd2luZyBzdGVwcyBNVVNUIGJlIGZvbGxvd2VkIGZvciBlYWNoIEJVTkRMRSBn cm91cCBiYXNlZCBvbg0KPj4gICB0aGUgU0RQIHNpZ25hbGxpbmcgaW5mb3JtYXRpb24uDQo+PiAN Cj4+ICAgICAgQ29uc3RydWN0IGEgdGFibGUgbWFwcGluZyBNSUQgdG8gIm09IiBsaW5lIGZvciBl YWNoICJtPSIgbGluZSBpbg0KPj4gICAgICB0aGlzIEJVTkRMRSBncm91cC4gIE5vdGUgdGhhdCBh biAibT0iIGxpbmUgbWF5IG9ubHkgaGF2ZSBvbmUgTUlELg0KPj4gDQo+PiAgICAgIENvbnN0cnVj dCBhIHRhYmxlIG1hcHBpbmcgaW5jb21pbmcgUlRQIHN0cmVhbXMgKFNTUkNzKSB0byB0aGVpcg0K Pj4gICAgICAibT0iIGxpbmUgZm9yIGVhY2ggIm09IiBsaW5lIGluIHRoaXMgQlVORExFIGdyb3Vw IGFuZCBmb3IgZWFjaCBSVFANCj4+ICAgICAgc3RyZWFtIGV4cGxpY2l0bHkgc2lnbmFsbGVkIGZv ciByZWNlaXZpbmcgaW4gdGhhdCAibT0iIGxpbmUuDQo+PiANCj4+ICAgICAgQ29uc3RydWN0IGEg dGFibGUgbWFwcGluZyBwYXlsb2FkIHR5cGVzIHRvICJtPSIgbGluZSBmb3IgZWFjaCAibT0iDQo+ PiAgICAgIGxpbmUgaW4gdGhlIEJVTkRMRSBncm91cCBhbmQgZm9yIGVhY2ggcGF5bG9hZCB0eXBl IGNvbmZpZ3VyZWQgZm9yDQo+PiAgICAgIHJlY2VpdmluZyBpbiB0aGF0ICJtPSIgbGluZS4gIElm IGFueSBwYXlsb2FkIHR5cGUgaXMgY29uZmlndXJlZA0KPj4gICAgICBmb3IgcmVjZWl2aW5nIGlu IG1vcmUgdGhhbiBvbmUgIm09IiBsaW5lIGluIHRoZSBCVU5ETEUgZ3JvdXAsIGRvDQo+PiAgICAg IG5vdCBpdCBpbmNsdWRlIGl0IGluIHRoZSB0YWJsZS4NCj4+IA0KPj4gICBOb3RlIHRoYXQgZm9y IGVhY2ggb2YgdGhlc2UgdGFibGVzLCB0aGVyZSBjYW4gb25seSBiZSBvbmUgbWFwcGluZyBmb3IN Cj4+ICAgYW55IGdpdmVuIGtleSAoTUlELCBTU1JDLCBvciBQVCkuICBJbiBvdGhlciB3b3Jkcywg dGhlIHRhYmxlcyBhcmUgbm90DQo+PiAgIG11bHRpbWFwcy4NCj4+IA0KPj4gICBBcyAibT0iIGxp bmVzIGFyZSBhZGRlZCBvciByZW1vdmVkIGZyb20gdGhlIEJVTkRMRSBncm91cHMsIG9yIHRoZWly DQo+PiAgIGNvbmZpZ3VyYXRpb25zIGFyZSBjaGFuZ2VkLCB0aGUgdGFibGVzIGFib3ZlIE1VU1Qg YWxzbyBiZSB1cGRhdGVkLg0KPj4gDQo+PiANCj4+IA0KPj4gTmFtZSAgICAgICAgICAgICAgICAg ICAgICBFeHBpcmVzIEp1bHkgMzEsIDIwMTcgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQo+PiAN Cj4+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBBYmJyZXZpYXRlZC1UaXRsZSAgICAgICAg ICAgICAgIEphbnVhcnkgMjAxNw0KPj4gDQo+PiANCj4+ICAgUmVjZWl2ZWQgUlRQIHBhY2tldHMg dGhhdCBhcmUgc3ludGFjdGljYWxseSBjb3JyZWN0IGFyZSBwcm9jZXNzZWQgYnkNCj4+ICAgdGhl IFJUUC9SVENQIHByb3RvY29sIGltcGxlbWVudGF0aW9uIGZvciBzdGF0aXN0aWNzIGV0Yy4gIEFm dGVyIHRoaXMNCj4+ICAgcHJvY2Vzc2luZyB0aGV5IG5lZWQgdG8gYmUgcm91dGVkIHRvIHRoZSBo aWdoZXIgbGF5ZXIgY29udGV4dA0KPj4gICBhc3NvY2lhdGVkIHdpdGggdGhlICJtPSIgbGluZSB3 aXRoaW4gdGhlIEJVTkRMRSBncm91cC4gIFNvbWV3aGVyZSBpbg0KPj4gICB0aGUgcHJvY2VzcyB3 aGVyZSBhbiByZWNlaXZlZCBSVFAgcGFja2V0IGlzIHByb2Nlc3NlZCB0byBiZSBkZWxpdmVyZWQN Cj4+ICAgdG8gdGhlIGhpZ2hlciBsYXllciBieSBSVFAgdGhlIG1hdGNoaW5nIHN0ZXAgYmVsb3cg TVVTVCBiZSBwZXJmb3JtZWQ6DQo+PiANCj4+ICAgMS4gIFJlY2VwdGlvbiBvZiBhbiBSVFAgcGFj a2V0IGZvciBhbiBSVFAgc3RyZWFtIHRoYXQgaGFzIGFuIGV4aXN0aW5nDQo+PiAgICAgICBtYXBw aW5nIGluIHRoZSBSVFAgc3RyZWFtIHRvIG09IGxpbmUgdGFibGUuICBCZWZvcmUgcHJvY2VlZGlu ZyBpbg0KPj4gICAgICAgZGVsaXZlcmluZyB0aGUgcGFja2V0IHRvIHRoZSBoaWdoZXIgbGF5ZXIg Y29udGV4dCBhY2NvcmRpbmcgdG8NCj4+ICAgICAgIHRoZSBSVFAgc3RyZWFtIHRvICJtPSIgbGlu ZSBtYXBwaW5nIHRhYmxlIHRoZSBmb2xsb3dpbmcgY2hlY2tzDQo+PiAgICAgICBNVVNUIGJlIHBl cmZvcm1lZDoNCj4+IA0KPj4gICAgICAgQS4gIElmIHRoZSBwYWNrZXQgY2FycmllcyBhbiBSVFAg aGVhZGVyIGV4dGVuc2lvbiB3aXRoIGEgU0RFUyBNSUQNCj4+ICAgICAgICAgICB2YWx1ZSB0aGF0 IGlzIG5vdCBpbiB0aGUgdGFibGUgbWFwcGluZyBNSUQgdG8gIm09IiBsaW5lLCB0aGVuDQo+PiAg ICAgICAgICAgZG8gbm90IGRlbGl2ZXIgdGhlIFJUUCBwYWNrZXQgdG8gaGlnaGVyIGxheWVycy4N Cj4+IA0KPj4gICAgICAgQi4gIElmIHRoZSBwYWNrZXQgY2FycmllcyBhbiBSVFAgaGVhZGVyIGV4 dGVuc2lvbiB3aXRoIGEgU0RFUyBNSUQNCj4+ICAgICAgICAgICB2YWx1ZSB0aGF0IGlzIGluIHRo ZSB0YWJsZSBtYXBwaW5nIE1JRCB0byAibT0iIGxpbmUsIGFuZCB0aGUNCj4+ICAgICAgICAgICB2 YWx1ZSBpbmRpY2F0ZXMgYSBkaWZmZXJlbnQgIm09IiBsaW5lIHRoYW4gdGhlIGN1cnJlbnQgUlRQ DQo+PiAgICAgICAgICAgc3RyZWFtIHRvICJtPSIgbGluZSBtYXBwaW5nIHRhYmxlLCB0aGVuIHVw ZGF0ZSB0aGUgUlRQIHN0cmVhbQ0KPj4gICAgICAgICAgIHRvICJtPSIgbGluZSBtYXBwaW5nLg0K Pj4gDQo+PiAgIDIuICBSZWNlcHRpb24gb2YgYW4gUlRQIHBhY2tldCBmb3IgYW4gUlRQIHN0cmVh bSB0aGF0IGhhcyBubyBleGlzdGluZw0KPj4gICAgICAgbWFwcGluZyB0byBhbiBtPSBsaW5lLiAg SW4gdGhpcyBjYXNlIHRoZSBmb2xsb3dpbmcgYWN0aW9ucyBNVVNUDQo+PiAgICAgICBiZSBwZXJm b3JtZWQ6DQo+PiANCj4+ICAgICAgIEEuICBJZiB0aGUgcGFja2V0IGNhcnJpZXMgYW4gUlRQIGhl YWRlciBleHRlbnNpb24gd2l0aCBhIFNERVMgTUlEDQo+PiAgICAgICAgICAgdmFsdWUgdGhhdCBp cyBpbiB0aGUgdGFibGUgbWFwcGluZyBNSUQgdG8gIm09IiBsaW5lLCB0aGVuDQo+PiAgICAgICAg ICAgY3JlYXRlIGFuIGVudHJ5IGluIHRoZSBSVFAgc3RyZWFtIHRvICJtPSIgbGluZSBtYXBwaW5n IHRhYmxlDQo+PiAgICAgICAgICAgZm9yIHRoaXMgUlRQIHN0cmVhbSAoU1NSQykuICBUaGVuIGRl bGl2ZXIgdGhlIFJUUCBwYWNrZXQgdG8NCj4+ICAgICAgICAgICB0aGUgIm09IiBsaW5lIGNvbnRl eHQgb2YgdGhlIGNyZWF0ZWQgbWFwcGluZyBhbmQgc3RvcC4NCj4+IA0KPj4gICAgICAgQi4gIElm IHRoZSBwYWNrZXQgY2FycmllcyBhIFBheWxvYWQgVHlwZSB0aGF0IGlzIGluIHRoZSBwYXlsb2Fk DQo+PiAgICAgICAgICAgdHlwZSB0YWJsZSwgdGhlbiBjcmVhdGUgYW4gZW50cnkgaW4gdGhlIFJU UCBzdHJlYW0gdG8gIm09Ig0KPj4gICAgICAgICAgIGxpbmUgbWFwcGluZyB0YWJsZSBmb3IgdGhp cyBSVFAgc3RyZWFtIChTU1JDKS4gIFRoZW4gZGVsaXZlcg0KPj4gICAgICAgICAgIHRoZSBSVFAg cGFja2V0IHRvIHRoZSAibT0iIGxpbmUgY29udGV4dCBvZiB0aGUgY3JlYXRlZA0KPj4gICAgICAg ICAgIG1hcHBpbmcgYW5kIHN0b3AuDQo+PiANCj4+ICAgICAgIEMuICBPdGhlcndpc2UgZG8gbm90 IGRlbGl2ZXIgdGhlIFJUUCBwYWNrZXQgdG8gaGlnaGVyIGxheWVycy4NCj4+ICAgICAgICAgICBO b3RlLCB0aGlzIGluY2x1ZGVzIHVua25vd24gTUlEIHZhbHVlcy4NCj4+IA0KPj4gICBGb3IgZWFj aCBSVENQIHBhY2tldCByZWNlaXZlZCAoaW5jbHVkaW5nIGVhY2ggUlRDUCBwYWNrZXQgdGhhdCBp cw0KPj4gICBwYXJ0IG9mIGEgY29tcG91bmQgUlRDUCBwYWNrZXQpLCB0aGUgUlRDUCBwYWNrZXQg bmVlZHMgdG8gYmUNCj4+ICAgcHJvY2Vzc2VkIGJ5IHRoZSBSVFAvUlRDUCBpbXBsZW1lbnRhdGlv biBhbmQgcmVsZXZhbnQgaW5mb3JtYXRpb24gYW5kDQo+PiAgIGRhdGEgZnJvbSB0aGUgUlRDUCBw YWNrZXRzIG5lZWRzIHRvIGJlIHJvdXRlZCB0byB0aGUgYXBwcm9wcmlhdGUNCj4+ICAgaGFuZGxl ciBmb3IgdGhlIHJlbGF0ZWQgUlRQIHN0cmVhbXMuICBUaGUgYXBwcm9wcmlhdGUgaGFuZGxlciBp cw0KPj4gICBkZXRlcm1pbmVkIGJ5IHVzaW5nIHRoZSBSVFAgc3RyZWFtIHRvICJtPSIgbGluZSBt YXBwaW5nIHRhYmxlLg0KPj4gDQo+PiANCj4+IA0KPj4gTmFtZSAgICAgICAgICAgICAgICAgICAg ICBFeHBpcmVzIEp1bHkgMzEsIDIwMTcgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQo+PiANCj4+ IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBBYmJyZXZpYXRlZC1UaXRsZSAgICAgICAgICAg ICAgIEphbnVhcnkgMjAxNw0KPj4gDQo+PiANCj4+ICAgT24gcmVjZXB0aW9uIG9mIGFueSBjb21w b3VuZCBSVENQIHBhY2tldCBwcmlvciB0byBkaXNwYXRjaGluZyB0aGUNCj4+ICAgcmVjZWl2ZWQg aW5mb3JtYXRpb24gYW5kIGRhdGEsIGlmIHRoZXJlIGlzIGFuIFJUQ1AgU0RFUyBwYWNrZXQNCj4+ ICAgaW5jbHVkZWQgdGhhdCBTSE9VTEQgYmUgcHJvY2Vzc2VkIGZpcnN0LiAgSWYgdGhhdCBTREVT IHBhY2tldA0KPj4gICBjb250YWlucyBTREVTIE1JRCBlbnRyaWVzLCB0aGlzIGNhbiByZXN1bHRz IGluIHVwZGF0ZXMgYW5kIGFkZGl0aW9ucw0KPj4gICB0byB0aGUgUlRQIHN0cmVhbSB0byAibT0i IGxpbmUgbWFwcGluZyB0YWJsZS4gIFRodXMgZWFjaCBvZiB0aGUgU0RFUw0KPj4gICBNSUQgaXRl bXMgYXJlIHByb2Nlc3NlZCBhbmQgdGhlIGN1cnJlbnQgdGFibGUgZW50cmllcyBhcmUgY2hlY2tl ZCBpZg0KPj4gICB0aGUgY29ycmVzcG9uZGluZyBNSUQgdmFsdWUgbWF0Y2hlcyB0aGUgY3VycmVu dCBSVFAgc3RyZWFtIHRvICJtPSINCj4+ICAgbGluZSBtYXBwaW5nLCBlbHNlIHRoZSBlbnRyeSBp cyB1cGRhdGVkLiAgSWYgdGhlcmUgaXMgbm8gUlRQIHN0cmVhbQ0KPj4gICB0byAibT0iIGxpbmUg dGFibGUgbWFwcGluZyBlbnRyeSBmb3IgdGhlIHJlY2VpdmVkIFNERVMgaXRlbSdzIFNTUkMsDQo+ PiAgIHN1Y2ggYW4gZW50cnkgaXMgY3JlYXRlZC4gIE5vdGUsIHRoYXQgaW4gdGhlIHByb2Nlc3Mg b2YgdXBkYXRpbmcgdGhlDQo+PiAgIHRhYmxlIGVudHJpZXMsIHVwZGF0ZSBmbGFwIHN1cHByZXNz aW9uIGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDQuMi42DQo+PiAgIG9mIFtSRkM3OTQxXSBzaG91 bGQgYmUgY29uc2lkZXJlZC4NCj4+IA0KPj4gICBUaGUgdmFyaW91cyBkaWZmZXJlbnQgUlRDUCBw YWNrZXRzIGFzIHdlbGwgYXMgdGhlaXIgdmFyaW91cyBzdWINCj4+ICAgcGFydHMsIHN1Y2ggYXMg dGhlIHZhcmlvdXMgUlRDUCBGZWVkYmFjayBtZXNzYWdlIHR5cGVzLCByZWxhdGVzIHRvDQo+PiAg IHRoZSBSVFAgc3RyZWFtcyBpbiBhIGNvdXBsZSBvZiBkaWZmZXJlbnQgd2F5cy4gIFRoZSBjdXJy ZW50bHkga25vd24NCj4+ICAgcGF0dGVybnMgYXJlIHRoZSBmb2xsb3dpbmc6DQo+PiANCj4+ICAg UmVwb3J0cyBvbiBvdXRnb2luZyBSVFAgc3RyZWFtczogIEZvciBhbGwgUlRQIHN0cmVhbXMgdGhh dCB0aGlzDQo+PiAgICAgIGVuZHBvaW50IGlzIHRoZSBzb3VyY2Ugb2YsIGl0IGNhbiBleHBlY3Qg dG8gcmVjZWl2ZSByZXBvcnQgYmxvY2tzDQo+PiAgICAgIG9mIHNldmVyYWwgdHlwZXMgaWRlbnRp ZmllZCBhcyByZWxhdGluZyB0byBhbiBvdXRnb2luZyBzdHJlYW0uDQo+PiAgICAgIFRoZSBiYXNp YyBwYXR0ZXJuIGZvciB0aGVzZSBibG9ja3MgYXJlIHRoYXQgdGhlIFJUQ1AgcGFja2V0IGhlYWRl cg0KPj4gICAgICBpZGVudGlmaWVzIHRoZSBzb3VyY2Ugb2YgdGhlIHJlcG9ydHMsIGFzIGlkZW50 aWZpZWQgYnkgYW4gU1NSQywNCj4+ICAgICAgYW5kIGNvbnRhaW5pbmcgb25lIG9yIG1vcmUgcmVw b3J0IGJsb2Nrcywgd2hlcmUgZWFjaCByZXBvcnQgYmxvY2sNCj4+ICAgICAgaWRlbnRpZmllcyB0 aGUgUlRQIHN0cmVhbSwgdXNpbmcgdGhlIFNTUkMsIHRoZSByZXBvcnQgcmVsYXRlcyB0by4NCj4+ ICAgICAgRm9yIHRoaXMgcGF0dGVybiB0aGUgcmVsZXZhbnQgcmVwb3J0IGluZm9ybWF0aW9uIGlz IHByb3ZpZGVkIHRvDQo+PiAgICAgIHRoZSBoaWdoZXIgbGF5ZXIgYXNzb2NpYXRlZCB3aXRoIHRo ZSAibT0iIGxpbmUgdGhlIFJUUCBTdHJlYW0gdG8NCj4+ICAgICAgIm09IiBsaW5lIHRhYmxlIGlk ZW50aWZpZXMuICBUaGUgc291cmNlIFNTUkMgYXMgaWRlbnRpZmllciBvZiB0aGUNCj4+ICAgICAg ZW5kcG9pbnQgdGhhdCB0aGUgcmVwb3J0IG9yaWdpbmF0ZXMgYXJlIHJlbGV2YW50IGZvciBpbnRl cnByZXRpbmcNCj4+ICAgICAgdGhlIGluZm9ybWF0aW9uLCBidXQgbm90IG5lY2Vzc2FyaWx5IGZv ciByb3V0aW5nLiAgRXhhbXBsZSBvZiB0aGlzDQo+PiAgICAgIGlzIHBhdHRlcm4gYXJlOg0KPj4g DQo+PiAgICAgIFNlbmRlciBSZXBvcnQgKFNSKSBhbmQgUmVjZWl2ZXIgUmVwb3J0IChSUikgIFRo ZSBiYXNpYyByZWNlaXZlcg0KPj4gICAgICAgICByZXBvcnQgYmxvY2tzIGZyb20gUkZDMzU1MCBz dGFydCB3aXRoIHRoZSBTU1JDIG9mIHRoZSBSVFANCj4+ICAgICAgICAgc3RyZWFtIHRoZXkgcmVw b3J0IG9uLg0KPj4gDQo+PiAgICAgIEV4dGVuZGVkIFJlcG9ydHMgKFhSKTogIFJGQzM2MTEgaXMg YSBmcmFtZXdvcmsgdGhhdCBlbmFibGVzIGENCj4+ICAgICAgICAgbGFyZ2UgbnVtYmVyIG9mIGRp ZmZlcmVudCByZXBvcnRzLiAgSG93ZXZlciwgYSBsYXJnZSBudW1iZXIgb2YNCj4+ICAgICAgICAg dGhlc2UgcmVwb3J0IGZvcm1hdHMgYXJlIHJlcG9ydGluZyBvbiBzcGVjaWZpYyBSVFAgc3RyZWFt cyBhbmQNCj4+ICAgICAgICAgdGh1cyBlYWNoIGluZGl2aWR1YWwgcmVwb3J0IG9mIHRoZXNlIHR5 cGVzIGNvbnRhaW5zIGEgU1NSQw0KPj4gICAgICAgICBmaWVsZCB0byBpZGVudGlmeSB0aGUgUlRQ IHN0cmVhbS4NCj4+IA0KPj4gICBSVENQIEZlZWRiYWNrIE1lc3NhZ2VzIGZvciBvdXRnb2luZyBS VFAgc3RyZWFtczogIFRoZSBSRkMgNDU4NSBSVENQDQo+PiAgICAgIGZlZWRiYWNrIG1lc3NhZ2Vz IGFsbG93IGZvciBhIG51bWJlciBvZiBkaWZmZXJlbnQgdHlwZSBvZiBmZWVkYmFjaw0KPj4gICAg ICBtZXNzYWdlcy4gIEhvd2V2ZXIsIHRoZSBSVENQIGZlZWRiYWNrIG1lc3NhZ2UgaGVhZGVyIGNv bnRhaW5zIHRoZQ0KPj4gICAgICBTU1JDIGlkZW50aWZ5aW5nIHRoZSBzb3VyY2Ugb2YgdGhlIGZl ZWRiYWNrIG1lc3NhZ2VzIGFzIHdlbGwgYXMNCj4+ICAgICAgdGhlIGFjdHVhbCB0eXBlIG9mIHRo ZSBmZWVkYmFjay4gIFNvbWUgb2YgdGhlIGZlZWRiYWNrIG1lc3NhZ2VzDQo+PiAgICAgIGFsc28g dXNlcyB0aGUgdGFyZ2V0IFNTUkMgZmllbGQgaW4gdGhlIGhlYWRlciB0byBpZGVudGlmeSB3aGlj aA0KPj4gDQo+PiANCj4+IA0KPj4gTmFtZSAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1 bHkgMzEsIDIwMTcgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQo+PiANCj4+IEludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBBYmJyZXZpYXRlZC1UaXRsZSAgICAgICAgICAgICAgIEphbnVhcnkg MjAxNw0KPj4gDQo+PiANCj4+ICAgICAgUlRQIHN0cmVhbSB0aGUgZmVlZGJhY2sgaXMgcmVsYXRl ZCB0by4gIEZvciB0aGVzZSB0eXBlcyBhbGwgdGhlDQo+PiAgICAgIEZDSSBlbnRyaWVzLCBpZiBt dWx0aXBsZSBvbmVzIGFyZSBmb3J3YXJkZWQgdG8gdGhlIGlkZW50aWZpZWQNCj4+ICAgICAgaGFu ZGxlci4gIEV4YW1wbGVzIG9mIHRoaXMgcGF0dGVybiBhcmU6DQo+PiANCj4+ICAgICAgUGljdHVy ZSBMb3NzIEluZGljYXRpb24gKFBMSSk6ICBSRkMgNDU4NSAoUFQ9UFNGQiwgRk1UPTEpLg0KPj4g DQo+PiAgICAgIFNsaWNlIExvc3MgSW5kaWNhdGlvbiAoU0xJKTogIFJGQyA0NTg1IChQVD1QU0ZC LCBGTVQ9MikuDQo+PiANCj4+ICAgICAgUmVmZXJlbmNlIFBpY3R1cmUgU2VsZWN0aW9uIEluZGlj YXRpb24gKFJQU0kpOiAgUkZDIDQ1ODUgKFBUPVBTRkIsDQo+PiAgICAgICAgIEZNVD0zKS4NCj4+ IA0KPj4gICAgICBHZW5lcmljIE5BQ0s6ICBbUkZDNDU4NV0gKFBUPVJUUEZCIGFuZCBGTVQ9MSku DQo+PiANCj4+ICAgICAgT3RoZXIgZmVlZGJhY2sgbWVzc2FnZXMgaW5jbHVkZXMgdGhlIHRhcmdl dCBTU1JDIGluIHRoZSBGZWVkYmFjaw0KPj4gICAgICBDb250cm9sIEluZm9ybWF0aW9uIChGQ0kp LiAgSGVyZSBlYWNoIEZDSSBuZWVkcyB0byBiZSBwcm9jZXNzZWQNCj4+ICAgICAgYW5kIHRoZSBT U1JDIGZpZWxkIGlkZW50aWZpZWQuICBBbmQgdGhlIGluZGl2aWR1YWwgRkNJIGNvbWJpbmVkDQo+ PiAgICAgIHdpdGggdGhlIFJUQ1AgcGFja2V0IGhlYWRlciBjb250ZXh0IG5lZWRzIHRvIGJlIGZv cndhcmRlZCB0byB0aGUNCj4+ICAgICAgaWRlbnRpZmllZCBoYW5kbGVyLiAgRXhhbXBsZSBvZiB0 aGlzIHBhdHRlcm4gYXJlOg0KPj4gDQo+PiAgICAgIEZ1bGwgSW50cmEgUmVxdWVzdCAoRklSKTog IFtSRkM1MTA0XSAoUFQ9UFNGQiwgRk1UPTQpLg0KPj4gDQo+PiAgICAgIFRlbXBvcmFsLVNwYXRp YWwgVHJhZGUtb2ZmIFJlcXVlc3QgKFRTVFIpOiAgW1JGQzUxMDRdIChQVD1QU0ZCLA0KPj4gICAg ICAgICBGTVQ9NSkuDQo+PiANCj4+ICAgICAgVGVtcG9yYWwtU3BhdGlhbCBUcmFkZS1vZmYgTm90 aWZpY2F0aW9uIChUU1ROKTogIFRoaXMgW1JGQzUxMDRdDQo+PiAgICAgICAgIGRlZmluZWQgbWVz c2FnZSAoUFQ9UFNGQiwgRk1UPTUpIGlzIGFjdHVhbGx5IGEgbm90aWZjaWF0aW9uIGluDQo+PiAg ICAgICAgIHJlc3BvbnNlIHRvIGEgVFNUUiB0aGlzIGVuZHBvaW50IHNlbnQgdXNpbmcgdGhlIFNT UkMgdGhlIEZDSQ0KPj4gICAgICAgICBpZGVudGlmaWVzIGFzIHNvdXJjZS4NCj4+IA0KPj4gICAg ICBILjI3MSBWaWRlbyBCYWNrIENoYW5uZWwgTWVzc2FnZSAoVkJDTSk6ICBbUkZDNTEwNF0gKFBU PVBTRkIsDQo+PiAgICAgICAgIEZNVD03KS4NCj4+IA0KPj4gICAgICBMYXllciBSZWZyZXNoIFJl cXVlc3QgKExSUik6ICBbSS1ELmlldGYtYXZ0ZXh0LWxycl0gKFBUPVBTRkIsDQo+PiAgICAgICAg IEZNVD1UQkQpLg0KPj4gDQo+PiAgIERlc2NyaXB0aXZlIG9yIE5vdGlmaWNhdGlvbnMgZm9yIGFu IGluY29taW5nIFJUUCBzdHJlYW06ICBUaGVyZSBleGlzdA0KPj4gICAgICBzb21lIFJUQ1AgcGFj a2V0IHR5cGVzIHRoYXQgcHJvdmlkZXMgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBvcg0KPj4gICAg ICBub3RpZmllcyBhYm91dCBldmVudHMgcmVsYXRlZCB0byB0aGUgUlRQIHN0cmVhbSBpZGVudGlm aWVkLiAgSW4NCj4+ICAgICAgdGhlc2UgY2FzZXMgdGhlIFJUUCBzdHJlYW0gaXMgaWRlbnRpZmll ZCB1c2luZyB0aGUgU1NSQyBmaWVsZA0KPj4gICAgICB2YWx1ZSwgYW5kIHRoZSBpbmZvcm1hdGlv biBpcyBwcm92aWRlZCB0byB0aGUgaGlnaGVyIGxheWVyDQo+PiAgICAgIGFzc29jaWF0ZWQgd2l0 aCB0aGUgIm09IiBsaW5lIGZvciB0aGUgaW5jb21pbmcgUlRQIHN0cmVhbSBhcw0KPj4gICAgICBp ZGVudGlmaWVkIGJ5IHRoZSBjdXJyZW50IFJUUCBzdHJlYW0gdG8gIm09IiBsaW5lIHRhYmxlLiAg Rm9yIHRoaXMNCj4+ICAgICAgdHlwZSBvZiBwYXR0ZXJuIGl0IGlzIGNvbW1vbiB0aGF0IHRoZSBS VENQIHBhY2tldHMgYW5kIGluZm9ybWF0aW9uDQo+PiAgICAgIGlzIHJlcGVhdGVkLCBlaXRoZXIg cGVyaW9kaWNhbGx5IChlLmcuICBTREVTIGl0ZW1zKSwgb3IgZm9yIGENCj4+ICAgICAgZHVyYXRp b24gKGUuZy4gIEJZRSksIHRodXMgc3VwcHJlc3Npb24gb2YgcmVwZXRpdGlvbnMgY2FuIGJlDQo+ PiAgICAgIGNvbnNpZGVyZWQuICBFeGFtcGxlcyBvZiB0aGVzZSBhcmU6DQo+PiANCj4+IA0KPj4g DQo+PiANCj4+IA0KPj4gTmFtZSAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMzEs IDIwMTcgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQo+PiANCj4+IEludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBBYmJyZXZpYXRlZC1UaXRsZSAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNw0K Pj4gDQo+PiANCj4+ICAgICAgU291cmNlIERlc2NyaXB0aW9uIChTREVTKSBSVENQIFBhY2tldDog IFRoZSBiYXNlIFJUUC9SVENQIHByb3RvY29sDQo+PiAgICAgICAgIFtSRkMzNTUwXSBkZWZpbmVz IFNERVMgUlRDUCBwYWNrZXRzIGFzIGEgd2F5IG9mIHByb3ZpZGluZyBwZXINCj4+ICAgICAgICAg c291cmNlIChTU1JDKSBzcGVjaWZpYyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgc291cmNlLiAgQW4g U0RFUw0KPj4gICAgICAgICBwYWNrZXQgY29udGFpbnMgemVybyBvciBtb3JlIGNodW5rcywgd2hl cmUgYSBjaHVuayBjb250YWlucyB0aGUNCj4+ICAgICAgICAgU1NSQyBmb3IgdGhlIHNvdXJjZSBi ZWluZyBkZXNjcmliZWQgYnkgdGhlIG9uZSBvciBtb3JlIGl0ZW1zDQo+PiAgICAgICAgIGluY2x1 ZGVkIGluIHRoZSBjaHVuay4gIEZvcndhcmQgdGhlIFNERVMgaXRlbXMgaW4gZWFjaCBjaHVuayB0 bw0KPj4gICAgICAgICB0aGUgUlRQIHN0cmVhbSdzIGhhbmRsZXIuDQo+PiANCj4+ICAgICAgR29v ZGJ5ZSAoQllFKSBSVENQIFBhY2tldDogIFRoaXMgUlRQL1JUQ1AgcHJvdG9jb2wgW1JGQzM1NTBd DQo+PiAgICAgICAgIG1lY2hhbmlzbSBpbmRpY2F0ZXMgdGhhdCBhIHBhcnRpY3VsYXIgUlRQIHN0 cmVhbSBpcyBsZWF2aW5nIHRoZQ0KPj4gICAgICAgICBSVFAgc2Vzc2lvbi4gIFRodXMsIGEgbW9z dCByZWxldmFudCBldmVudCB0byBpbmZvcm0gdGhlIGhhbmRsZXINCj4+ICAgICAgICAgZm9yIHRo aXMgUlRQIHN0ZWFtIG9mLg0KPj4gDQo+PiAgIFRoaXJkIFBhcnR5IFRhcmdldGVkIFJlcG9ydHMg b3IgRmVlZGJhY2s6ICBUaGVyZSBleGlzdCBzb21lDQo+PiAgICAgIG11bHRpcGFydHkgUlRQIFRv cG9sb2dpZXMgdGhhdCByZXN1bHRzIGluIHRoYXQgYW4gZW5kcG9pbnQNCj4+ICAgICAgcmVjZWl2 ZXMgdGhpcmQgcGFydHkgcmVwb3J0cyAoU1IgW1JGQzM1NTBdLCBSUiBbUkZDMzU1MF0gb3IgWFIN Cj4+ICAgICAgW1JGQzM2MTFdKSBhcyB3ZWxsIGFzIEZlZWRiYWNrIE1lc3NhZ2VzIFtSRkM0NTg1 XSB0aGF0IHJlbGF0ZXMgdG8NCj4+ICAgICAgb3IgdGFyZ2V0cyBhbiBTU1JDIHRoYXQgb3JpZ2lu YXRlcyBmcm9tIGFub3RoZXIgZW5kcG9pbnQsIGFuZA0KPj4gICAgICB3aGVyZSB0aGUgc291cmNl IG9mIHRoZSBSVENQIHBhY2tldCBpcyBhbHNvIGFub3RoZXIgZW5kcG9pbnQuDQo+PiAgICAgIFRo aXMgdHlwZSBvZiBwYWNrZXRzIHNob3VsZCBiZSBmb3J3YXJkZWQgdG8gdGhlIGhpZ2hlciBsYXll cg0KPj4gICAgICBmdW5jdGlvbiBkZWFsaW5nIHdpdGggdGhlIHRoaXJkIHBhcnR5IHJlcG9ydGlu Zy4gIEFuZCBpZiBub25lDQo+PiAgICAgIGV4aXN0IHRoZW4gdGhleSBjYW4gYmUgc3VwcHJlc3Nl ZC4gIEFzIHRoZSB0aGlyZCBwYXJ0eSBoYW5kbGVyIGNhbg0KPj4gICAgICBiZSBmb2N1c2VkIG9u IGRldGVybWluaW5nIHRoZSBjb25kaXRpb25zIGZvciB0aGUgc291cmNlIG9mIHRoZQ0KPj4gICAg ICByZXBvcnRzIGFuZCBmZWVkYmFjaywgb3IgZm9jdXNlZCBvbiBob3cgdGhlIFJUUCBzdHJlYW0g c291cmNlDQo+PiAgICAgIHByb2dyZXNzZXMsIG9yIGJvdGggcmVjb21tZW5kYXRpb25zIGNhbid0 IGJlIG1hZGUuDQo+PiANCj4+ICAgQVBQIFBhY2tldHM6ICBUaGUgUlRDUCBBUFAgUGFja2V0cyBb UkZDMzU1MF0gYXJlIGEgbWVjaGFuaXNtIHRoYXQNCj4+ICAgICAgZW5hYmxlcyBleHBlcmltZW50 YXRpb24uICBUaGUgQVBQIHBhY2tldCBvbmx5IHNwZWNpZmllcyB0aGUgc291cmNlDQo+PiAgICAg IG9mIHRoZSBwYWNrZXQuICBUaHVzIHRoaXMgaW5mb3JtYXRpb24gY2FuIGJlIHJlbGF0ZWQgdG8g YW55IG9mIHRoZQ0KPj4gICAgICAibT0iIGxpbmVzLCB0aHVzIGRlbGl2ZXIgYSBjb3B5IG9mIHRo ZSBwYWNrZXQgdG8gZWFjaCAibT0iIGxpbmUgb3INCj4+ICAgICAgYW4gQVBQIHNwZWNpZmljIGhh bmRsZXIuDQo+PiANCj4gDQo+IA0KPiAtLSANCj4gDQo+IE1hZ251cyBXZXN0ZXJsdW5kDQo+IA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IFNlcnZpY2VzLCBNZWRpYSBhbmQgTmV0d29yayBmZWF0dXJlcywg RXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RYTQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IEVyaWNzc29uIEFC ICAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KPiBGw6Ryw7ZnYXRhbiA2 ICAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPiBTRS0xNjQgODAgU3Rv Y2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= From nobody Thu Feb 2 14:26:18 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EE9129446 for ; Thu, 2 Feb 2017 14:25:39 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oF4uCBPGSDyx for ; Thu, 2 Feb 2017 14:25:38 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A48C1295AC for ; Thu, 2 Feb 2017 14:25:36 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id v77so9093333wmv.0 for ; Thu, 02 Feb 2017 14:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Dur5cq2+qm7oKDL+DeLsAsIjm1melt/31unwFpLMFf8=; b=Hpa26onW1NeEoBjDeumEZWALpCmxebrbLLnHauGhUZgCRoHZ01h7mNrBVSSUuM4bIX i2wZiCVd63zpyM9GmXClZTRB3BCsWlq3Q3GpWyDeP9SHi8tQGYh6+llvJwFFjWCH5O9s 1EzfuQzcVUgAuu7xhk0Z6tUKLfZAuZmKFjERKhGQpzZgMJqGdHJRSTGFWfIxDtjyA+pw 8/qSQnBEkhTRG9oHh9KehJEJpyBs7o6ucwdlnOiBlcAT4ozsYQ5wqB980E4sZl4wDqvf 5mNxmX14Keym4XoEwlWg1aoW2CgyJaCI6YQ4g2gMUBmTgQbuMiiwf/DHwbYHmdH5tunD VV9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Dur5cq2+qm7oKDL+DeLsAsIjm1melt/31unwFpLMFf8=; b=epxIw/Dvur5YESlweIBlPc2rLJ//wM+W5NZ0Y0SL+H0a43v2KvTafHV464sBUOa+wr 23F9WUL/aeaIKhikwCqSKd0UW3JbyLJYGnokkLVceXTj9O4fDw4oI0vLqGvie+HAmtlT sqVOS26mqtMOCCotQ7/Z8L45ZfGbY+OjjqpIM716g35rggUx3spdu6JoDotTlTgguDDz 5QQXtyD4DDYUbW4JQznUjsbc0EPPPlA3Ghnfs79/jDPN51nO4d0TdZDwpDrHwozJyijZ QnDQQ0h80KAdAwiuJbwNcxstIaQDhDHSAWMfKhb9rfngpxVmjDZu+l1Pqww6YVa4+7Po ltqQ== X-Gm-Message-State: AIkVDXIrcxr6dD3kvp8/YtTJMMGTamfvWB5Q1wMkO7kPBgkyA3Y1UwasL2Qvzh5IbFHAuvW+P9Y9cesREt1zug== X-Received: by 10.223.134.104 with SMTP id 37mr9109931wrw.121.1486074334805; Thu, 02 Feb 2017 14:25:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.182.85 with HTTP; Thu, 2 Feb 2017 14:25:14 -0800 (PST) In-Reply-To: <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 2 Feb 2017 23:25:14 +0100 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jonathan Lennox , "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 22:25:40 -0000 2017-02-02 23:19 GMT+01:00 Cullen Jennings : > But imagine that A and B had an SSRC collision Very likely :) --=20 I=C3=B1aki Baz Castillo From nobody Thu Feb 2 19:43:31 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B9E127071; Thu, 2 Feb 2017 19:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0de8FMsJiEBJ; Thu, 2 Feb 2017 19:43:12 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9F7126BF7; Thu, 2 Feb 2017 19:43:12 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id y143so596420pfb.1; Thu, 02 Feb 2017 19:43:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UCIt8LBLa2yaD9zrT15p3PRa9qLLuSz9jb8i1T7jdSg=; b=FNYIWBc/BQgoFMsuZd6XVQxBqafWz0I74bGpbeQX9CqfwZvC+51ClKsWAiOWoVolUn IKWAQAH97xlddFHCM0Jwotj2xkG4GqYtTtckEHDnHteK4L98z0p39qYsyAIau6XRmeCQ H/wy3oT3GWuLPJCUzrmSxiM5rkUaQ9Q1FHXua3QQp3YdOSX6br8chnVEikFonofYV3Z6 UZuhW05pANERpC5g6D55qzwKZvtWA+9iS6WGzPaVvPV05tuXoWj0PygcSu9vPb1gyXFQ gyDAe9Zuomnm5eCq52luPDMh1att+YeDIwSiUWpnjDsSh6lRWl3/6LzDDWCWKw3kWON/ FY+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UCIt8LBLa2yaD9zrT15p3PRa9qLLuSz9jb8i1T7jdSg=; b=HZrUwI4wuARCwjeSd+jCtxV8Z1uJsLHooaVyLVTNFgaFAAngK2FMtcnmZRryub9bJg MDcJdcxAObfhUpfjzx6sWTKPw/YhfK5gQbyBnvqMjgGIaOhRZtWqlv/RDQuAtjedr76Q 1BNe0r6qrTqwyaP13ZovQ6L10u89t7JTifxgdAreHuzJlJuV39ZxnTXKKZm4XmDDNOPW r6JGhLa+DqfscsLEehyM8PMtJvpMQMzDzC9eap9OJZ/SqOH8NRJP4ndPCKPsUHLcGqfW K2/tQ4eb1A9iRylt3qPGMWbdS/gJjcsNgH0IOi65ispSyvb/JP1wbW/9GaNhbEq46zFS x1nA== X-Gm-Message-State: AIkVDXJpUD51rM7MuzCJnl71ZQP3MltRKXEr5H6Bk999Y4EzoW3xvzTnPFRF5uz2As0RDQ== X-Received: by 10.98.212.23 with SMTP id a23mr15423316pfh.18.1486093391775; Thu, 02 Feb 2017 19:43:11 -0800 (PST) Received: from [10.69.52.226] (mobile-166-176-184-127.mycingular.net. [166.176.184.127]) by smtp.gmail.com with ESMTPSA id r8sm62142358pfi.82.2017.02.02.19.43.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 19:43:10 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (14D27) In-Reply-To: <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> Date: Thu, 2 Feb 2017 19:43:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <61E68192-A460-4F6D-BC31-28C459D63756@gmail.com> References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> To: Cullen Jennings Archived-At: Cc: Jonathan Lennox , "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 03:43:13 -0000 Assuming the collision is detected and B sends a BYE then once the SSRC latc= h is removed then A's packets will match on PT, a new SSRC latch is put in p= lace and everything works. > On Feb 2, 2017, at 2:19 PM, Cullen Jennings wrote: >=20 >=20 >> On Jan 31, 2017, at 10:43 AM, Jonathan Lennox wrote:= >>=20 >> In general, this looks good. >>=20 >> I have one question, however. What should happen if an RTP packet (witho= ut a MID) is received for a stream that has an existing mapping to an m=3D l= ine, but whose PT is not valid for that m=3D line? >>=20 >> Should it >> 1. Cause the stream=E2=80=99s mapping to be moved to another m=3D line, i= f the received PT is in the payload type table for some other m=3D line? >> or=20 >> 2. Be an error? >=20 >=20 > Imagine a case where we have two sends call A and B and they each use one P= T that is unique and go to different m lines on receiver C via a SFU. Initi= ally C get a packet from B with a given SSRC and the PT and creates a mappin= g for it. But imagine that A and B had an SSRC collision which they sort tha= t out and A ends up having the SSRC that B initially used. If you don't have= the PT override the SSRC, the packets are going to go to the wrong m-line b= ecause the PT points at the m-line A is using but the old SSRC incorrectly p= oints at the m-line B is using.=20 >=20 > To put this a different way, if the packet has a mid, I think it is very c= lear the mid has to override the PT. Same for the PT. The mid is effectively= just an extended PT.=20 >=20 > I'm not thinking to much about the case where SSRC is signalled in SDP but= ignoring that case for a second, I think the really easy thing to specify, i= mplement, and understand works is simply a priority order where roughly=20 >=20 > 1) if you have mid, use that and latch the SSRC > 2) if you have a unique pt, use that and latch the SSRC=20 > 3) if you have a latched SSRC use that=20 >=20 > If you had signaled SSRC, guess I would insert that as step 1.5 of use tha= t=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Feb 3 02:42:42 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10431127078; Fri, 3 Feb 2017 02:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 isngXanBEGuT; Fri, 3 Feb 2017 02:42:39 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89556129BDA; Fri, 3 Feb 2017 02:42:38 -0800 (PST) X-AuditID: c1b4fb2d-e76b398000007e3d-82-58945e9cd894 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id E1.14.32317.C9E54985; Fri, 3 Feb 2017 11:42:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0319.002; Fri, 3 Feb 2017 11:42:30 +0100 From: Christer Holmberg To: "Cullen Jennings (fluffy)" , Magnus Westerlund Thread-Topic: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSfaJ5jrr91gBvrE2+PKFOpdD0GaFXKnMA Date: Fri, 3 Feb 2017 10:42:30 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <986C7FAA008B9D46BA9ED85C3F95178E@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7ve6cuCkRBn+n6FhMn/WOzWJ+xzo2 i47JbBZTlz9msVj7r53dgdVjyu+NrB5Llvxk8vhy+TNbAHMUl01Kak5mWWqRvl0CV8af7neM Baf7GCuWHZvA3sA4N7uLkZNDQsBEonndFbYuRi4OIYF1jBKXmy5DOYsYJWa+7mDqYuTgYBOw kOj+pw3SICKQLtH+4BEziM0s0MEkcWmFAogtLFAtcWDWXkaImhqJNauvsELYRhJXe46C2SwC KhJ3p61lA7F5BawlNuz9ywKxawWjxM9N05lAEpwCthIfpr4HG8QoICbx/dQaJohl4hK3nsxn grhaQGLJnvPMELaoxMvH/8AWiAroSSx/voYZ5GYJAUWJ5f1yEK16EjemTmGDsK0ler+/hLpf W2LZwtfMEPcISpyc+YRlAqP4LCTbZiFpn4WkfRaS9llI2hcwsq5iFC1OLS7OTTcy1kstykwu Ls7P08tLLdnECIzLg1t+6+5gXP3a8RCjAAejEg/vhsbJEUKsiWXFlbmHGCU4mJVEeAX9pkQI 8aYkVlalFuXHF5XmpBYfYpTmYFES5zVbeT9cSCA9sSQ1OzW1ILUIJsvEwSnVwJi+nI/398Fa mfsJSjkcaWZcG6z6Pm28OO3nkaex15bVLmYNyZxgl+opfS4nap2M647oUyHRey5ESSZ8aRT5 NrPfJnlvDwv/O63nExSW6mrI7v+78ggP/9FOIfnPC4Pkq59rGlg8czomvtsnQlph7fzf95cL SHzZ2WW88d6mV4bsizmv57A/eKbEUpyRaKjFXFScCAAhOCAjxwIAAA== Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , "mmusic \(E-mail\)" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 10:42:42 -0000 Hi, >2) both the proposed and current text seem lacking in dealing with >multiple bundle groups No matter what text we move forward with, I think it shall be explicitly said that the procedures are per IP address:port. So, if you have multiple bundle groups, you will apply the procedures to each group, independent of each other. Regards, Christer > >> On Jan 30, 2017, at 6:18 AM, Magnus Westerlund >> wrote: >>=20 >> Hi, >>=20 >> I have now generated a pull request for this text, with some very minor >>changes. >>=20 >> https://github.com/rtcweb-wg/jsep/pull/538 >>=20 >> Cheers >>=20 >> Magnus >>=20 >> Den 2017-01-27 kl. 17:43, skrev Magnus Westerlund: >>> MMUSIC and RTCWEB, >>>=20 >>> Here is now a more complete text proposal that also considers the RTCP. >>> It also goes further than what Appendix B defines in one aspect, namely >>> explicitly considering third party RTCP reporting and what to do with >>>it. >>>=20 >>> Feedback is much appreciated. I plan to put this into a PR towards JSEP >>> APPENDIX B on monday. If only to get the JSEP authors attention ;-). >>> However, the text is really intended for the next version of BUNDLE. >>>=20 >>>=20 >>> X. Associating RTP/RTCP With Correct SDP Media Description >>>=20 >>> As described in [RFC3550], RTP packets are associated with RTP >>> streams [RFC7656]. Each RTP stream is identified by an SSRC value, >>> and each RTP packet carries an SSRC value that is used to associate >>> the packet with the correct RTP stream. RTCP packets also uses SSRCs >>> to identify on which RTP streams any report or feedback relate to. >>> Thus, an RTCP packet will commonly carry multiple SSRC values, and >>> might therefore be providing feedback or report on multiple RTP >>> streams. >>>=20 >>> In order to be able to process received RTP/RTCP packets correctly it >>> must be possible to associate an RTP stream with the correct "m=3D" >>> line, as the "m=3D" line and SDP attributes associated with the "m=3D= " >>> line contain information needed to process the packets. >>>=20 >>> As all RTP streams associated with a BUNDLE group are part of the >>> same RTP session and using the same address:port combination for >>> sending and receiving RTP/RTCP packets, the local address:port >>> combination cannot be used to associate an RTP stream with the >>> correct "m=3D" line. In addition, multiple RTP streams might be >>> associated with the same "m=3D" line. >>>=20 >>> Also, as described in Section 10.1.1, the same payload type value >>> might be used by multiple RTP streams, in which case the payload type >>> value cannot be used to associate an RTP stream with the correct "m= =3D" >>> line. However, there are cases where each "m=3D" line has unique >>> payload type values, and then the payload type could serve as >>> indicator to the relevant "m=3D" line the RTP stream is associated >>> with. >>>=20 >>> An offerer and answerer can inform each other which SSRC values they >>> will use for an RTP stream by using the SDP 'ssrc' attribute >>> [RFC5576]. However, an offerer will not know which SSRC values the >>> answerer will use until the offerer has received the answer providing >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 [Page >>>2] >>>=20 >>> Internet-Draft Abbreviated-Title January >>>2017 >>>=20 >>>=20 >>> that information. Due to this, before the offerer has received the >>> answer, the offerer will not be able to associate an RTP stream with >>> the correct "m=3D" line using the SSRC value associated with the RTP >>> stream. In addition, the offerer and answerer may start using new >>> SSRC values mid-session, without informing each other using the SDP >>> 'ssrc' attribute. >>>=20 >>> In order for an offerer and answerer to always be able to associate >>> an RTP stream with the correct "m=3D" line, the offerer and answerer >>> using the BUNDLE extension MUST support the mechanism defined in >>> Section 14, where the offerer and answerer includes the >>> identification-tag (provided by the remote peer) associated with an >>> "m=3D" line in the RTP Streams and in RTCP SDES packets part of a >>> BUNDLE group. >>>=20 >>> The mapping from an SSRC to an identification-tag is carried in RTCP >>> SDES packets or in RTP header extensions (Section 14). Since a >>> compound RTCP packet can contain multiple RTCP SDES packets, and each >>> RTCP SDES packet can contain multiple chunks, an RTCP packet can >>> contain several SSRC to identification-tag mappings. The offerer and >>> answerer maintain tables mapping RTP streams identified by SSRC to >>> "m=3D" lines identified by the identification-tag. These tables are >>> updated each time new information that affects how packets should be >>> processed and routed are received. >>>=20 >>> To prepare for demultiplexing RTP streams to the correct "m=3D" line, >>> the following steps MUST be followed for each BUNDLE group based on >>> the SDP signalling information. >>>=20 >>> Construct a table mapping MID to "m=3D" line for each "m=3D" line = in >>> this BUNDLE group. Note that an "m=3D" line may only have one MID= . >>>=20 >>> Construct a table mapping incoming RTP streams (SSRCs) to their >>> "m=3D" line for each "m=3D" line in this BUNDLE group and for each= RTP >>> stream explicitly signalled for receiving in that "m=3D" line. >>>=20 >>> Construct a table mapping payload types to "m=3D" line for each "m= =3D" >>> line in the BUNDLE group and for each payload type configured for >>> receiving in that "m=3D" line. If any payload type is configured >>> for receiving in more than one "m=3D" line in the BUNDLE group, do >>> not it include it in the table. >>>=20 >>> Note that for each of these tables, there can only be one mapping for >>> any given key (MID, SSRC, or PT). In other words, the tables are not >>> multimaps. >>>=20 >>> As "m=3D" lines are added or removed from the BUNDLE groups, or their >>> configurations are changed, the tables above MUST also be updated. >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 [Page >>>3] >>>=20 >>> Internet-Draft Abbreviated-Title January >>>2017 >>>=20 >>>=20 >>> Received RTP packets that are syntactically correct are processed by >>> the RTP/RTCP protocol implementation for statistics etc. After this >>> processing they need to be routed to the higher layer context >>> associated with the "m=3D" line within the BUNDLE group. Somewhere i= n >>> the process where an received RTP packet is processed to be delivered >>> to the higher layer by RTP the matching step below MUST be performed: >>>=20 >>> 1. Reception of an RTP packet for an RTP stream that has an existing >>> mapping in the RTP stream to m=3D line table. Before proceeding = in >>> delivering the packet to the higher layer context according to >>> the RTP stream to "m=3D" line mapping table the following checks >>> MUST be performed: >>>=20 >>> A. If the packet carries an RTP header extension with a SDES MID >>> value that is not in the table mapping MID to "m=3D" line, th= en >>> do not deliver the RTP packet to higher layers. >>>=20 >>> B. If the packet carries an RTP header extension with a SDES MID >>> value that is in the table mapping MID to "m=3D" line, and th= e >>> value indicates a different "m=3D" line than the current RTP >>> stream to "m=3D" line mapping table, then update the RTP stre= am >>> to "m=3D" line mapping. >>>=20 >>> 2. Reception of an RTP packet for an RTP stream that has no existing >>> mapping to an m=3D line. In this case the following actions MUST >>> be performed: >>>=20 >>> A. If the packet carries an RTP header extension with a SDES MID >>> value that is in the table mapping MID to "m=3D" line, then >>> create an entry in the RTP stream to "m=3D" line mapping tabl= e >>> for this RTP stream (SSRC). Then deliver the RTP packet to >>> the "m=3D" line context of the created mapping and stop. >>>=20 >>> B. If the packet carries a Payload Type that is in the payload >>> type table, then create an entry in the RTP stream to "m=3D" >>> line mapping table for this RTP stream (SSRC). Then deliver >>> the RTP packet to the "m=3D" line context of the created >>> mapping and stop. >>>=20 >>> C. Otherwise do not deliver the RTP packet to higher layers. >>> Note, this includes unknown MID values. >>>=20 >>> For each RTCP packet received (including each RTCP packet that is >>> part of a compound RTCP packet), the RTCP packet needs to be >>> processed by the RTP/RTCP implementation and relevant information and >>> data from the RTCP packets needs to be routed to the appropriate >>> handler for the related RTP streams. The appropriate handler is >>> determined by using the RTP stream to "m=3D" line mapping table. >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 [Page >>>4] >>>=20 >>> Internet-Draft Abbreviated-Title January >>>2017 >>>=20 >>>=20 >>> On reception of any compound RTCP packet prior to dispatching the >>> received information and data, if there is an RTCP SDES packet >>> included that SHOULD be processed first. If that SDES packet >>> contains SDES MID entries, this can results in updates and additions >>> to the RTP stream to "m=3D" line mapping table. Thus each of the SDE= S >>> MID items are processed and the current table entries are checked if >>> the corresponding MID value matches the current RTP stream to "m=3D" >>> line mapping, else the entry is updated. If there is no RTP stream >>> to "m=3D" line table mapping entry for the received SDES item's SSRC, >>> such an entry is created. Note, that in the process of updating the >>> table entries, update flap suppression as discussed in Section 4.2.6 >>> of [RFC7941] should be considered. >>>=20 >>> The various different RTCP packets as well as their various sub >>> parts, such as the various RTCP Feedback message types, relates to >>> the RTP streams in a couple of different ways. The currently known >>> patterns are the following: >>>=20 >>> Reports on outgoing RTP streams: For all RTP streams that this >>> endpoint is the source of, it can expect to receive report blocks >>> of several types identified as relating to an outgoing stream. >>> The basic pattern for these blocks are that the RTCP packet header >>> identifies the source of the reports, as identified by an SSRC, >>> and containing one or more report blocks, where each report block >>> identifies the RTP stream, using the SSRC, the report relates to. >>> For this pattern the relevant report information is provided to >>> the higher layer associated with the "m=3D" line the RTP Stream to >>> "m=3D" line table identifies. The source SSRC as identifier of th= e >>> endpoint that the report originates are relevant for interpreting >>> the information, but not necessarily for routing. Example of this >>> is pattern are: >>>=20 >>> Sender Report (SR) and Receiver Report (RR) The basic receiver >>> report blocks from RFC3550 start with the SSRC of the RTP >>> stream they report on. >>>=20 >>> Extended Reports (XR): RFC3611 is a framework that enables a >>> large number of different reports. However, a large number of >>> these report formats are reporting on specific RTP streams and >>> thus each individual report of these types contains a SSRC >>> field to identify the RTP stream. >>>=20 >>> RTCP Feedback Messages for outgoing RTP streams: The RFC 4585 RTCP >>> feedback messages allow for a number of different type of feedback >>> messages. However, the RTCP feedback message header contains the >>> SSRC identifying the source of the feedback messages as well as >>> the actual type of the feedback. Some of the feedback messages >>> also uses the target SSRC field in the header to identify which >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 [Page >>>5] >>>=20 >>> Internet-Draft Abbreviated-Title January >>>2017 >>>=20 >>>=20 >>> RTP stream the feedback is related to. For these types all the >>> FCI entries, if multiple ones are forwarded to the identified >>> handler. Examples of this pattern are: >>>=20 >>> Picture Loss Indication (PLI): RFC 4585 (PT=3DPSFB, FMT=3D1). >>>=20 >>> Slice Loss Indication (SLI): RFC 4585 (PT=3DPSFB, FMT=3D2). >>>=20 >>> Reference Picture Selection Indication (RPSI): RFC 4585 (PT=3DPSF= B, >>> FMT=3D3). >>>=20 >>> Generic NACK: [RFC4585] (PT=3DRTPFB and FMT=3D1). >>>=20 >>> Other feedback messages includes the target SSRC in the Feedback >>> Control Information (FCI). Here each FCI needs to be processed >>> and the SSRC field identified. And the individual FCI combined >>> with the RTCP packet header context needs to be forwarded to the >>> identified handler. Example of this pattern are: >>>=20 >>> Full Intra Request (FIR): [RFC5104] (PT=3DPSFB, FMT=3D4). >>>=20 >>> Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=3DPSFB, >>> FMT=3D5). >>>=20 >>> Temporal-Spatial Trade-off Notification (TSTN): This [RFC5104] >>> defined message (PT=3DPSFB, FMT=3D5) is actually a notifciation= in >>> response to a TSTR this endpoint sent using the SSRC the FCI >>> identifies as source. >>>=20 >>> H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=3DPSFB, >>> FMT=3D7). >>>=20 >>> Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=3DPSFB, >>> FMT=3DTBD). >>>=20 >>> Descriptive or Notifications for an incoming RTP stream: There exist >>> some RTCP packet types that provides additional information or >>> notifies about events related to the RTP stream identified. In >>> these cases the RTP stream is identified using the SSRC field >>> value, and the information is provided to the higher layer >>> associated with the "m=3D" line for the incoming RTP stream as >>> identified by the current RTP stream to "m=3D" line table. For th= is >>> type of pattern it is common that the RTCP packets and information >>> is repeated, either periodically (e.g. SDES items), or for a >>> duration (e.g. BYE), thus suppression of repetitions can be >>> considered. Examples of these are: >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 [Page >>>6] >>>=20 >>> Internet-Draft Abbreviated-Title January >>>2017 >>>=20 >>>=20 >>> Source Description (SDES) RTCP Packet: The base RTP/RTCP protocol >>> [RFC3550] defines SDES RTCP packets as a way of providing per >>> source (SSRC) specific information about the source. An SDES >>> packet contains zero or more chunks, where a chunk contains the >>> SSRC for the source being described by the one or more items >>> included in the chunk. Forward the SDES items in each chunk to >>> the RTP stream's handler. >>>=20 >>> Goodbye (BYE) RTCP Packet: This RTP/RTCP protocol [RFC3550] >>> mechanism indicates that a particular RTP stream is leaving the >>> RTP session. Thus, a most relevant event to inform the handler >>> for this RTP steam of. >>>=20 >>> Third Party Targeted Reports or Feedback: There exist some >>> multiparty RTP Topologies that results in that an endpoint >>> receives third party reports (SR [RFC3550], RR [RFC3550] or XR >>> [RFC3611]) as well as Feedback Messages [RFC4585] that relates to >>> or targets an SSRC that originates from another endpoint, and >>> where the source of the RTCP packet is also another endpoint. >>> This type of packets should be forwarded to the higher layer >>> function dealing with the third party reporting. And if none >>> exist then they can be suppressed. As the third party handler can >>> be focused on determining the conditions for the source of the >>> reports and feedback, or focused on how the RTP stream source >>> progresses, or both recommendations can't be made. >>>=20 >>> APP Packets: The RTCP APP Packets [RFC3550] are a mechanism that >>> enables experimentation. The APP packet only specifies the source >>> of the packet. Thus this information can be related to any of the >>> "m=3D" lines, thus deliver a copy of the packet to each "m=3D" lin= e or >>> an APP specific handler. >>>=20 >>=20 >>=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 nobody Fri Feb 3 05:48:02 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3185129D06 for ; Fri, 3 Feb 2017 05:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.719 X-Spam-Level: X-Spam-Status: No, score=-17.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syfCWVLyw-G1 for ; Fri, 3 Feb 2017 05:47:58 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E09129CF9 for ; Fri, 3 Feb 2017 05:47:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27179; q=dns/txt; s=iport; t=1486129674; x=1487339274; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=S9s+qdFmfu+snJv32SHIt7kFx5mESWYAkCWyXSKuwW8=; b=TreQ6QBdH8aDKyT3aWUn9erSMtscQvwISCP4gcA2d3lmj5DV/rSxb+VE WBwff585w8xi+oZcYr/GPL7T9itZoRTcFdvMCnusLRvA8CEC/umU/WN44 6KxkQtTGQm7bvW7e/iV/IYKp9CS8xmpEGzaS0cvbQnIEcbYtxzK6X5bDb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7CgD8iJRY/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9kYSpfn2qVO4IKAx8BDIUsSgKCW0AXAQIBAQEBAQEBYiiEaQE?= =?us-ascii?q?BAQICAQErQQsQCxEDAQEBASABAgQHJx8JCAYBDAYCAQGJYA0Or2kriwsBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYZLggWCaoRtFoUvBYlvhkmLK5IIgXuFF4MqI4Y?= =?us-ascii?q?jkwohATU6dB0VO4REHRmBZiI1AYkfAQEB?= X-IronPort-AV: E=Sophos;i="5.33,328,1477958400"; d="scan'208,217";a="207223233" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2017 13:47:53 +0000 Received: from [10.98.149.206] (bxb-fandreas-88113.cisco.com [10.98.149.206]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v13DlqXi014028; Fri, 3 Feb 2017 13:47:52 GMT To: Christer Holmberg , Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B4BFE0DBC@ESESSMB209.ericsson.se> From: Flemming Andreasen Message-ID: <84ccd5ba-ae06-f35b-92a1-fe6f79b31dce@cisco.com> Date: Fri, 3 Feb 2017 08:47:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFE0DBC@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------895AE9C17F70A0A8030A606A" Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 13:48:01 -0000 This is a multi-part message in MIME format. --------------895AE9C17F70A0A8030A606A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit We issued a consensus call in the IETF 97 meeting on this which indicated a strong consensus for option 2 as well (see https://www.ietf.org/proceedings/97/minutes/minutes-97-mmusic-00.html). In lieu of that and since we have only seen one person arguing against option 2 here, we suggest moving forward with option 2 as well. If anybody objects to this, please let us know. Thanks Flemming & Bo (as MMUSIC chairs) On 2/2/17 3:23 PM, Christer Holmberg wrote: > > Hi, > > Based on the feedback, my suggestion would be to move forward with ALT #2. > > Now, as I said earlier, that still doesn’t prevent protocols from > specifying an MIT transport, which is used as default candidate (read: > ALT #1). > > Regarding documentation, I guess it would at least have impact on > ICE-SDP. The question is whether something is needed for 3264? > > Chairs? > > Regards, > > Christer > > *From:*Roman Shpount [mailto:roman@telurix.com] > *Sent:* 13 January 2017 21:09 > *To:* Christer Holmberg > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul > regarding non-supported transport in m- line of answer > > As I have mentioned before, I think ALT#1 is a better option: If we > propose mandatory to implement UDP based protocol for each transport > family, only use the mandatory to implement protocol for the default > candidate, and the transport mismatch problem will never occur. > > As a bit of background, this issue appeared because of TCP/BFCP, which > was assumed to be the default protocol for BFCP with ICE. Since then, > I think we have decided that TCP/BFCP is not going to be used with > ICE. For all the other protocols that I know (UDP/DTLS/SCTP, > UDP/TLS/RTP/SAVPF, UDP/DTLS/BFCP, RTP/AVP, etc) there is a clear > preference that UDP based protocol should be used for backwards > compatibility. I also do not see a use case which will require that > only tcp based candidates would be included in the offer or the > answer. Because of this, I think mandatory to implement transport is a > better approach. > > This also have additional benefits of: > > 1. Providing m= and c= line information which will not cause the ICE > mismatch with older implementations > > 2. Not supplying any on the path signaling devices with bogus address > information required in ALT#2 answer > > 3. Improves general chances of negotiation succeeding with end points > not supporting ICE by picking the protocol more likely to succeed > (chance of TCP/RTP/AVP succeeding, for instance, are much lower then > RTP/AVP). > > Regards, > > > _____________ > Roman Shpount > > On Fri, Jan 13, 2017 at 7:00 AM, Christer Holmberg > > wrote: > > The subject shall be ICE-SDP: Verify decision made… > > *From: *mmusic > on behalf of Christer Holmberg > > > *Date: *Friday 13 January 2017 at 13:32 > *To: *"mmusic@ietf.org " > > *Subject: *[MMUSIC] SIP-SDP: Verify decision made in Seoul > regarding non-supported transport in m- line of answer > > Hi, > > In Seoul we discussed a number of issues related to ICE-SDP. We > made some decisions, and I got action points to verify one of > those on the list. > > The associated slides can be found here: > > https://www.ietf.org/proceedings/97/slides/slides-97-mmusic-ice-sip-sdp-00.pdf > > The issue (slides 4-6) was when an answerer receives an offer with > a m- line transport that it doesn’t support. The current O/A rules > say that the transport in the answer must match the transport in > the offer. > > However, if ICE is used, there may be transports (offered using > ICE candidates) that the answerer DOES support. > > Based on the discussions, there was strong consensus to go for > Alt#2, which was allowing a transport in the m- line of the answer > even if the answerer doesn’t support it, as ICE candidates will be > used to determine the transport. > > Does anyone object to Alt#2? > > Regards, > > Christer > > > _______________________________________________ > 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 --------------895AE9C17F70A0A8030A606A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit We issued a consensus call in the IETF 97 meeting on this which indicated a strong consensus for option 2 as well (see https://www.ietf.org/proceedings/97/minutes/minutes-97-mmusic-00.html). In lieu of that and since we have only seen one person arguing against option 2 here, we suggest moving forward with option 2 as well. If anybody objects to this, please let us know.

Thanks

    Flemming & Bo (as MMUSIC chairs)




On 2/2/17 3:23 PM, Christer Holmberg wrote:

Hi,

 

Based on the feedback, my suggestion would be to move forward with ALT #2.

 

Now, as I said earlier, that still doesn’t prevent protocols from specifying an MIT transport, which is used as default candidate (read: ALT #1).

 

Regarding documentation, I guess it would at least have impact on ICE-SDP. The question is whether something is needed for 3264?

 

Chairs?

 

Regards,

 

Christer

 

From: Roman Shpount [mailto:roman@telurix.com]
Sent: 13 January 2017 21:09
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer

 

As I have mentioned before, I think ALT#1 is a better option: If we propose mandatory to implement UDP based protocol for each transport family, only use the mandatory to implement protocol for the default candidate, and the transport mismatch problem will never occur.

 

As a bit of background, this issue appeared because of TCP/BFCP, which was assumed to be the default protocol for BFCP with ICE. Since then, I think we have decided that TCP/BFCP is not going to be used with ICE. For all the other protocols that I know (UDP/DTLS/SCTP, UDP/TLS/RTP/SAVPF, UDP/DTLS/BFCP, RTP/AVP, etc) there is a clear preference that UDP based protocol should be used for backwards compatibility. I also do not see a use case which will require that only tcp based candidates would be included in the offer or the answer. Because of this, I think mandatory to implement transport is a better approach.

 

This also have additional benefits of: 

 

1. Providing m= and c= line information which will not cause the ICE mismatch with older implementations

2. Not supplying any on the path signaling devices with bogus address information required in ALT#2 answer

3. Improves general chances of negotiation succeeding with end points not supporting ICE by picking the protocol more likely to succeed (chance of TCP/RTP/AVP succeeding, for instance, are much lower then RTP/AVP).

 

Regards,


_____________
Roman Shpount

 

On Fri, Jan 13, 2017 at 7:00 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

The subject shall be ICE-SDP: Verify decision made…

 

From: mmusic <mmusic-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
Date: Friday 13 January 2017 at 13:32
To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer

 

Hi,

 

In Seoul we discussed a number of issues related to ICE-SDP. We made some decisions, and I got action points to verify one of those on the list.

 

The associated slides can be found here:

 

 

 

The issue (slides 4-6) was when an answerer receives an offer with a m- line transport that it doesn’t support. The current O/A rules say that the transport in the answer must match the transport in the offer.

 

However, if ICE is used, there may be transports (offered using ICE candidates) that the answerer DOES support.

 

Based on the discussions, there was strong consensus to go for Alt#2, which was allowing a transport in the m- line of the answer even if the answerer doesn’t support it, as ICE candidates will be used to determine the transport.

 

Does anyone object to Alt#2?

 

Regards,

 

Christer

 

 

 

 

 

 

 

 

 

 

 

 


_______________________________________________
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

--------------895AE9C17F70A0A8030A606A-- From nobody Fri Feb 3 05:55:25 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A03129CE6; Fri, 3 Feb 2017 05:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPT8AcEzFts0; Fri, 3 Feb 2017 05:55:21 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F2B1279EB; Fri, 3 Feb 2017 05:55:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3638; q=dns/txt; s=iport; t=1486130121; x=1487339721; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=hWkfEQSmKlzbpUYZyXQa7pxHMaqz38mfe1CSD+b9rgc=; b=LKNE3ewAInegHAuO27f21tKsVS1fU/7AB5mGQM+eq/P5XCsxT9iWsT5X gZDpvjsgS/aIODwVtZnwVJJhQJeN+eDOwH7537FBRuigJn44J5qS5v9td mbCrjKCjOybBP4Vor6RvB7WncSYv9L0gMn5RefMt90ybFvTU6JT6x9Fvp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQBADgipRY/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhKl+DWIoIkgqIEo0pgg0fC4UuSgKCWz8YAQIBAQEBAQEBYii?= =?us-ascii?q?EaQEBAQQBASEVLwcLEAsRAwECAQICJgICIQYoAwUGAQwGAgEBEIlFAwgNDq1Og?= =?us-ascii?q?iWHNw2DcQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFQIIFCIJiglGFAoJAHwW?= =?us-ascii?q?QOIpzOIZohwmEF4F7hReDKoZGiCiCBYhdHziBLh0VO4REHYF/IjWJIAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,328,1477958400"; d="scan'208";a="193803121" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Feb 2017 13:55:20 +0000 Received: from [10.98.149.206] (bxb-fandreas-88113.cisco.com [10.98.149.206]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v13DtJLV008427; Fri, 3 Feb 2017 13:55:19 GMT To: Victor Pascual Avila , Bernard Aboba References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> From: Flemming Andreasen Message-ID: Date: Fri, 3 Feb 2017 08:55:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] Change Alert [Re: Modifying an approved document: MSID] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 13:55:23 -0000 Based on the feedback received, it seems fine to make this change. Thanks -- Flemming (as MMUSIC co-chair) On 1/30/17 8:28 AM, Victor Pascual Avila wrote: > fine with me > > On Fri, Jan 27, 2017 at 7:20 PM, Bernard Aboba wrote: >> I am in favor of the change. >> >> On Thu, Jan 26, 2017 at 5:54 AM, Flemming Andreasen >> wrote: >>> Hi Harald >>> >>> Since the document is not yet in Auth48 and the change is relatively >>> minor, it is possible to update it during Auth48. >>> >>> However, from an MMUSIC chair point of view, I would like to get positive >>> confirmation from some of the stakeholders that this change is indeed >>> desired. Similarly, if anybody has any concerns with the suggested change, >>> please send an e-mail to that effect. >>> >>> Thanks >>> >>> -- Flemming (as MMUSIC co-chair) >>> >>> >>> >>> On 1/23/17 10:18 AM, Harald Alvestrand wrote: >>>> Den 19. jan. 2017 13:31, skrev Harald Alvestrand: >>>>> Ted pointed out to me that I sent this to the wrong group. >>>>> >>>>> Chairs and members, please advise. >>>> My proposed change is here: >>>> >>>> https://github.com/alvestrand/rtcweb-msid/pull/16 >>>> >>>> The filed issue is here: >>>> >>>> https://github.com/alvestrand/rtcweb-msid/issues/15 >>>> >>>> (CCing RTCWEB - please keep discussion, if any, on mmusic) >>>> >>>>> >>>>> -------- Forwarded Message -------- >>>>> Subject: [rtcweb] Modifying an approved document: MSID >>>>> Date: Wed, 18 Jan 2017 23:22:14 +0100 >>>>> From: Harald Alvestrand >>>>> To: rtcweb@ietf.org >>>>> >>>>> >>>>> >>>>> When reviewing the implications of the PeerConnection API change to >>>>> support AddTrack rather than AddStream, I found an issue. >>>>> >>>>> This issue concerns draft-ietf-rtcweb-msid, which is currently in >>>>> REF-WAIT state (I believe). >>>>> >>>>> The issue is that it is possible to add a track without specifying a >>>>> stream. Since the track's ID needs to be carried, we have to send an >>>>> "a=msid" line, but the track's ID is the *second* field on that line, >>>>> with the first being the stream's ID. >>>>> >>>>> This creates a problem. >>>>> >>>>> Suggested fix: Insert two lines in the document: >>>>> >>>>> 1) On SDP generation: >>>>> >>>>> "If there is no stream associated with the track, use the reserved ID >>>>> value '-'" >>>>> >>>>> 2) On SDP parsing >>>>> >>>>> "If the stream ID is the reserved value '-', the track is not associated >>>>> with a stream, and no stream is signalled or created." >>>>> >>>>> If this is OK with the community, I'll issue an updated draft with this >>>>> change. >>>>> >>>>> >>>>> -- >>>>> Surveillance is pervasive. Go Dark. >>>>> >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> . >>>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > From nobody Fri Feb 3 09:08:19 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80F2129490 for ; Fri, 3 Feb 2017 09:08:18 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVICc3sPcdOu for ; Fri, 3 Feb 2017 09:08:16 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D3A9129449 for ; Fri, 3 Feb 2017 09:08:16 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id k15so44564617qtg.3 for ; Fri, 03 Feb 2017 09:08:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z6i03L2OTce4NoP7MEJSkw9ezQnj5sWI744TohKV31Y=; b=ZnN8BSRtxP6o80gCU96FADSPUTOKEBGv2u+0ne/srEyPkPsV5vVvuJiABfZ18AzQ7v sTpwVRN7NAR582oBtyIBuSaCM0BA93ToOGl2tvlAm4R9OmC/SUgs4sNTlI1u5hO2G0JJ kOq6zDsmeSCUqAKLT60uRhXTKoQmBVpHmw009s6fguCYNP13lwHvZKESFl3O7qwh9FIV lBqJ83S9e18weJaeas9OSfn/py0AlRKpSDb4UtK2Jw5nHO2PuuducO6PiygcSm4r12w7 eYbO9M3nAxHMGPltw7f/QMpLBsDUn9dEEcSKWC/1GIvvQGPqdfY2zPvsaS22ez48gRys xWqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z6i03L2OTce4NoP7MEJSkw9ezQnj5sWI744TohKV31Y=; b=uSDlIcM+V53A4/xerMF4mu5mUfwcXNVW/HB1F0Z+DCxDfTPMPsCQH+1VOmlZWvquzx pxUXR1jsdGXNjqfTOYuUwFqA6z5oyk/IFGTXR89InDBOXRMgUF+0GIqkGc3qQOBI4U2A w1LfsIXsdgQmw6l87j4TqLgWIi/S1n8qcEvXywvC4ILpq6SZOsAwrn6ilzoyNsxPFfgz +gIJc52yAv1PDyqoKcvM4CpP3UqOeabzWGvpQ3kejYUyYuT9dpKldL24b0hhNY7A/DS9 7zbqZENEx7mEmJyQyHuZtxgBxZj72H/Js+2NFAWfZiiaU/8rJwg40eFBWl/DEWYOt1A6 naiQ== X-Gm-Message-State: AIkVDXLFZ12RooU+3MiCSJiU2VEWv4H5o1KbVJtmwkYX49KBov8hR8rSDXWCCxItN0bGsA== X-Received: by 10.237.37.71 with SMTP id w7mr13780289qtc.287.1486141695444; Fri, 03 Feb 2017 09:08:15 -0800 (PST) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com. [209.85.220.171]) by smtp.gmail.com with ESMTPSA id t7sm24873488qtb.11.2017.02.03.09.08.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 09:08:15 -0800 (PST) Received: by mail-qk0-f171.google.com with SMTP id s140so4428635qke.0 for ; Fri, 03 Feb 2017 09:08:14 -0800 (PST) X-Received: by 10.55.47.69 with SMTP id v66mr14043616qkh.222.1486141694646; Fri, 03 Feb 2017 09:08:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Fri, 3 Feb 2017 09:08:14 -0800 (PST) In-Reply-To: <84ccd5ba-ae06-f35b-92a1-fe6f79b31dce@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B4BFE0DBC@ESESSMB209.ericsson.se> <84ccd5ba-ae06-f35b-92a1-fe6f79b31dce@cisco.com> From: Roman Shpount Date: Fri, 3 Feb 2017 12:08:14 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Flemming Andreasen Content-Type: multipart/alternative; boundary=001a114f4ec4cba6220547a353b5 Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 17:08:19 -0000 --001a114f4ec4cba6220547a353b5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am fine with this direction, especially since we can make sure that must implement transport is specified for all protocols that support ICE. Please keep in mind that ALT #2 will require removal of ICE mismatch or specifying a fake ICE candidate which matches the transport from m=3D line.= I think ICE mismatch is only removed for JSEP, not ICE-SDP in general. Regards, _____________ Roman Shpount On Fri, Feb 3, 2017 at 8:47 AM, Flemming Andreasen wrote: > We issued a consensus call in the IETF 97 meeting on this which indicated > a strong consensus for option 2 as well (see https://www.ietf.org/ > proceedings/97/minutes/minutes-97-mmusic-00.html). In lieu of that and > since we have only seen one person arguing against option 2 here, we > suggest moving forward with option 2 as well. If anybody objects to this, > please let us know. > > Thanks > > Flemming & Bo (as MMUSIC chairs) > > > > > > On 2/2/17 3:23 PM, Christer Holmberg wrote: > > Hi, > > > > Based on the feedback, my suggestion would be to move forward with ALT #2= . > > > > Now, as I said earlier, that still doesn=E2=80=99t prevent protocols from > specifying an MIT transport, which is used as default candidate (read: AL= T > #1). > > > > Regarding documentation, I guess it would at least have impact on ICE-SDP= . > The question is whether something is needed for 3264? > > > > Chairs? > > > > Regards, > > > > Christer > > > > *From:* Roman Shpount [mailto:roman@telurix.com ] > *Sent:* 13 January 2017 21:09 > *To:* Christer Holmberg > > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding > non-supported transport in m- line of answer > > > > As I have mentioned before, I think ALT#1 is a better option: If we > propose mandatory to implement UDP based protocol for each transport > family, only use the mandatory to implement protocol for the default > candidate, and the transport mismatch problem will never occur. > > > > As a bit of background, this issue appeared because of TCP/BFCP, which wa= s > assumed to be the default protocol for BFCP with ICE. Since then, I think > we have decided that TCP/BFCP is not going to be used with ICE. For all t= he > other protocols that I know (UDP/DTLS/SCTP, UDP/TLS/RTP/SAVPF, > UDP/DTLS/BFCP, RTP/AVP, etc) there is a clear preference that UDP based > protocol should be used for backwards compatibility. I also do not see a > use case which will require that only tcp based candidates would be > included in the offer or the answer. Because of this, I think mandatory t= o > implement transport is a better approach. > > > > This also have additional benefits of: > > > > 1. Providing m=3D and c=3D line information which will not cause the ICE > mismatch with older implementations > > 2. Not supplying any on the path signaling devices with bogus address > information required in ALT#2 answer > > 3. Improves general chances of negotiation succeeding with end points not > supporting ICE by picking the protocol more likely to succeed (chance of > TCP/RTP/AVP succeeding, for instance, are much lower then RTP/AVP). > > > > Regards, > > > _____________ > Roman Shpount > > > > On Fri, Jan 13, 2017 at 7:00 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > The subject shall be ICE-SDP: Verify decision made=E2=80=A6 > > > > *From: *mmusic on behalf of Christer Holmberg < > christer.holmberg@ericsson.com> > *Date: *Friday 13 January 2017 at 13:32 > *To: *"mmusic@ietf.org" > *Subject: *[MMUSIC] SIP-SDP: Verify decision made in Seoul regarding > non-supported transport in m- line of answer > > > > Hi, > > > > In Seoul we discussed a number of issues related to ICE-SDP. We made some > decisions, and I got action points to verify one of those on the list. > > > > The associated slides can be found here: > > > > https://www.ietf.org/proceedings/97/slides/slides- > 97-mmusic-ice-sip-sdp-00.pdf > > > > > > The issue (slides 4-6) was when an answerer receives an offer with a m- > line transport that it doesn=E2=80=99t support. The current O/A rules say= that the > transport in the answer must match the transport in the offer. > > > > However, if ICE is used, there may be transports (offered using ICE > candidates) that the answerer DOES support. > > > > Based on the discussions, there was strong consensus to go for Alt#2, > which was allowing a transport in the m- line of the answer even if the > answerer doesn=E2=80=99t support it, as ICE candidates will be used to de= termine > the transport. > > > > Does anyone object to Alt#2? > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > mmusic mailing listmmusic@ietf.orghttps://www.ietf.org/mailman/listinfo/m= music > > > --001a114f4ec4cba6220547a353b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am fine with this direction, especially since we can mak= e sure that must implement transport is specified for all protocols that su= pport ICE.

Please keep in mind that ALT #2 will require = removal of ICE mismatch or specifying a fake ICE candidate which matches th= e transport from m=3D line. I think ICE mismatch is only removed for JSEP, = not ICE-SDP in general.

Regards,

_____________
Roman Shpount

On Fri, Feb 3, 2017 at 8:47 AM, Flemming And= reasen <fandreas@cisco.com> wrote:
=20 =20 =20
We issued a consensus call in the IETF 97 meeting on this which indicated a strong consensus for option 2 as well (see https://www.ietf.org/proceedings/97/minutes/minutes-97-mm= usic-00.html). In lieu of that and since we have only seen one person arguing against option 2 here, we suggest moving forward with option 2 as well. If anybody objects to this, please let us know.

Thanks

=C2=A0=C2=A0=C2=A0 Flemming & Bo (as MMUSIC chairs)





On 2/2/17 3:23 PM,= Christer Holmberg wrote:
=20 =20 =20

Hi,

=C2=A0

Based on the feedback, my suggestion would be to move forward with ALT #2.

=C2=A0

Now, as I said earlier, that still doesn=E2=80=99t prevent protocols= from specifying an MIT transport, which is used as default candidate (read: ALT #1).

=C2=A0

Regarding documentation, I guess it would at least have impact on ICE-SDP. The question is whether something is needed for 3264?

=C2=A0

Chairs?<= /p>

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

From: Roman Shpount [mailto:roman@telur= ix.com]
Sent: 13 January 2017 21:09
To: Christer Holmberg <christer.h= olmberg@ericsson.com>
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer

=C2=A0

As I have mentioned before, I think ALT#1 is a better option: If we propose mandatory to implement UDP based protocol for each transport family, only use the mandatory to implement protocol for the default candidate, and the transport mismatch problem will never occur.<= /u>

=C2=A0

As a bit of background, this issue appeared because of TCP/BFCP, which was assumed to be the default protocol for BFCP with ICE. Since then, I think we have decided that TCP/BFCP is not going to be used with ICE. For all the other protocols that I know (UDP/DTLS/SCTP, UDP/TLS/RTP/SAVPF, UDP/DTLS/BFCP, RTP/AVP, etc) there is a clear preference that UDP based protocol should be used for backwards compatibility. I also do not see a use case which will require that only tcp based candidates would be included in the offer or the answer. Because of this, I think mandatory to implement transport is a better approach.

=C2=A0

This also have additional benefits of:= =C2=A0

=C2=A0

1. Providing m=3D and c=3D line informat= ion which will not cause the ICE mismatch with older implementations

2. Not supplying any on the path signaling devices with bogus address information required in ALT#2 answer

3. Improves general chances of negotiation succeeding with end points not supporting ICE by picking the protocol more likely to succeed (chance of TCP/RTP/AVP succeeding, for instance, are much lower then RTP/AVP).

=C2=A0

Regards,


_____________
Roman Shpount

=C2=A0

On Fri, Jan 13, 2017 at 7:00 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

The subject shall be ICE-SDP: Verify decision made=E2=80= =A6

=C2=A0<= /span>

From: mmusic <mmusic-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsso= n.com>
Date: Friday 13 January 2017 at 13:32
To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer

=C2=A0<= /u>

Hi,=

=C2=A0=

In Seoul we discussed a number of issues related to ICE-SDP. We made some decisions, and I got action points to verify one of those on the list.

=C2=A0=

The associated slides can be found here:

=C2=A0=

=C2=A0=

=C2=A0=

The issue (slides 4-6) was when an answerer receives an offer with a m- line transport that it doesn=E2=80=99t support. The current = O/A rules say that the transport in the answer must match the transport in the offer.=

=C2=A0=

However, if ICE is used, there may be transports (offered using ICE candidates) that the answerer DOES support.

=C2=A0=

Based on the discussions, there was strong consensus to go for Alt#2, which was allowing a transport in the m- line of the answer even if the answerer doesn=E2=80=99t support it, as ICE candidates will be used to determine the transport.

=C2=A0=

Does anyone object to Alt#2?<= /p>

=C2=A0=

Regards,

=C2=A0=

Christer

=C2=A0=

=C2=A0=

=C2=A0=

=C2=A0=

=C2=A0=

=C2=A0=

=C2=A0=

=C2=A0=

=C2=A0=

=C2=A0=

=C2=A0=

=C2=A0=


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

=C2=A0



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


--001a114f4ec4cba6220547a353b5-- From nobody Fri Feb 3 09:39:23 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26889129487 for ; Fri, 3 Feb 2017 09:39:22 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gZkqHEuJaEn for ; Fri, 3 Feb 2017 09:39:21 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B4D128874 for ; Fri, 3 Feb 2017 09:39:20 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id l19so16107447ywc.2 for ; Fri, 03 Feb 2017 09:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=GlbTWyU2lKpi3CNZS62FK1YkXW7WV6+K0YgfVepf9sw=; b=CcsN7kzD5B+UV/RS0gob/nQWeoJx2CZdNyrZ3PnLJA8qhpaLCHqHmZfG3pLuf37vHE LQpKeb7BLV/LIJFeXLm1tD6cundTgiKAc4RSdSY9ldbOiYFxuDnLW27IAanYXiKLYUUQ 2vf2vzEQNtovhy2pVcUE7JRDD+2I3MkfWpCnbyb/xGWG/rbR6iwH1wOREPrZYEu074Lz 28CIQG93UY8uJFdf8sveJwFd/zv6v1XGY8zr0vXiCGe2ztn/4w+dM0iEVXh67XjFLlr5 t7Xvk5gx6BoewkTeec4IL8dpj6+pmz+nMMiIARBY9utb3RBZKwxUvF+KD7aiXnzWq8ck v71g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GlbTWyU2lKpi3CNZS62FK1YkXW7WV6+K0YgfVepf9sw=; b=iGNDSPJ6/16iarJA+Tx3/ZdfOcaADMZ9trUMZi5fC85LcMZanuN5yeyDCobn62oMJX bf9eEF7Ka6AMiZu0rCDmuOFiEqyGIReQyCGbmukeuXz/fX664AbFd3gjVry1QM89wC7w nx6SXcJD9vDmpAGO/DeNGp2fe1TiMwZwZS7RZksf+1GM166O+kOSvi7cLvi9ZWruK76c GfDW0x/U6qDjFLYe8dg3EG5rOIUxiG5SaIW3qJVrZdhphueR5sXzfR5WTpEx0b6PJ6y1 IVEH2mNw4CFgAKXKt+jCy5omexi0aPpPeSDtD6vWgnxm5gz0HTAVCBcnXr/9+vY97+0q Wj4A== X-Gm-Message-State: AIkVDXIzcXO4xjgy/OI0mT+JjkFhm4w/1OPjjCU59hwVd+HL0H+Mw3dvVVYXxXwHlHLwurXBizeWY5lc+KSd/A== X-Received: by 10.129.108.131 with SMTP id h125mr10034468ywc.71.1486143559951; Fri, 03 Feb 2017 09:39:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Fri, 3 Feb 2017 09:38:39 -0800 (PST) From: Eric Rescorla Date: Fri, 3 Feb 2017 09:38:39 -0800 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary=001a114dcf78fa1ade0547a3c23b Archived-At: Subject: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 17:39:22 -0000 --001a114dcf78fa1ade0547a3c23b Content-Type: text/plain; charset=UTF-8 I have been reading the mux-exclusive document and I'm not sure it says quite what we want. Specifically, S 4.2 says: When an offerer sends the initial offer, if the offerer wants to indicate exclusive RTP/RTCP multiplexing for RTP-based media, the offerer MUST associate an SDP 'rtcp-mux-only' attribute with the associated SDP media description ("m=" line). In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line), the offerer MAY also associate an SDP 'rtcp-mux' attribute with the same SDP media description ("m=" line), following the procedures in [RFC5761]. As I understand this text, the offerer may say the following things: 1. No a=rtcp-mux: No muxing. 2. a=rtcp-mux: I am offering RTCP mux 3. a=rtcp-mux-only + a=rtcp-mux: I will only do RTCP mux 4. a=rtcp-mux-only: I will only do RTCP mux (same as #3). I don't think the last of these is sensible. No current implementation will know what to do with a=rtcp-mux-only w/o a=rtcp-mux, so this will result in interop failures. Thus the MAY in the second graf needs to be a MUST. -Ekr --001a114dcf78fa1ade0547a3c23b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have been reading the mux-exclusive document and I&= #39;m not sure it says
quite what we want. Specifically, S 4.2 sa= ys:

=C2=A0 =C2=A0When an offerer sends the initial= offer, if the offerer wants to
=C2=A0 =C2=A0indicate exclusive R= TP/RTCP multiplexing for RTP-based media, the
=C2=A0 =C2=A0offere= r MUST associate an SDP 'rtcp-mux-only' attribute with the
=C2=A0 =C2=A0associated SDP media description ("m=3D" line).

=C2=A0 =C2=A0In addition, if the offerer associates = an SDP 'rtcp-mux-only'
=C2=A0 =C2=A0attribute with an SDP= media description ("m=3D" line), the offerer MAY
=C2= =A0 =C2=A0also associate an SDP 'rtcp-mux' attribute with the same = SDP media
=C2=A0 =C2=A0description ("m=3D" line), follo= wing the procedures in [RFC5761].

As I understand = this text, the offerer may say the following things:

=C2=A01. No a=3Drtcp-mux: No muxing.
=C2=A02. a=3Drtcp-mux: I = am offering RTCP mux
=C2=A03. a=3Drtcp-mux-only + a=3Drtcp-mux: I= will only do RTCP mux
=C2=A04. a=3Drtcp-mux-only: I will only do= RTCP mux (same as #3).

I don't think the last= of these is sensible. No current implementation
will know what t= o do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will
result= in interop failures. Thus the MAY in the second graf needs to be
a MUST.

-Ekr

--001a114dcf78fa1ade0547a3c23b-- From nobody Fri Feb 3 09:41:51 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D761294B7 for ; Fri, 3 Feb 2017 09:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEPuCt2_3La5 for ; Fri, 3 Feb 2017 09:41:48 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587871294B1 for ; Fri, 3 Feb 2017 09:41:48 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id u68so16244611ywg.0 for ; Fri, 03 Feb 2017 09:41:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=IUdRHvf3C7T7X2llX+rWwOZ6gprU7aWczEIHE1yEPhU=; b=rwun5g73VFbRsGkbUeO0oETU+MNBN/Gxr7PR7GYGApzmFeHOW2Or7SPN97GRlpDEYQ Dy0dbaTaVH9P+D5bU1pwn3jNfqloiPVTcYT83Wh37o1MagNPT0yKvsihdwc+t812cCca W04zIcIp0GvKF/3PhdXk9q3VHhGvYvRWlrkj9/5GMMijrE84P7ijKvUlR5FJ1t3GMMTp O6465vmmhKvxpbbMLKxNYM5HK2MsmGgCmjZDRhf2MIK5JURbDrvvCTGRcrS3A9eIMncc Fw6w8TP6ig11eB/62pBL4JF1KH2cCsyzmC/IolbtpjqFmwatNQjQ/6Jz0YJeilX3uB7q Cfng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=IUdRHvf3C7T7X2llX+rWwOZ6gprU7aWczEIHE1yEPhU=; b=Cc1yNdWE7gwe5zY+lgnxNCJUPP94RKXK8+zIeQzwAamyWjvy9aRo5Gr9tJWKQkXn76 ZOIU01+/8fsa74gHKR9NoIDsxXgJwnywZ2gNrAUnEKKmuhvpsbo9EpVrweH8n86HjPp/ Yl3wOlVoIj7B4ME3xSPYNPMGxk4dQshLpK16+qEMUc+8Fi+5FgtMQfOk4rhHRMPWcxSM K8jUwPbi7ZdF0jTmkarCPgLl9/hbA8tPpGarppE7LN7qFZ9OyLMS14EUYhb7Vxln4z34 hThpgqRPs399rmTQnoTeQY8k8TiSkj+3ZcxL8kDStIkR0lSmD0fOjpndcvAjTk0JuudB MYNg== X-Gm-Message-State: AIkVDXJWfnNOwanUzERA1eaXdDPE5iPBPbuxsDafxGXtW3AaRGPDJ6CQUZT4nujDWwcpFZEQyE+icLVS6kOMoQ== X-Received: by 10.129.92.2 with SMTP id q2mr11412093ywb.87.1486143707568; Fri, 03 Feb 2017 09:41:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Fri, 3 Feb 2017 09:41:06 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 3 Feb 2017 09:41:06 -0800 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary=001a114d6f16c68bb90547a3cb2d Archived-At: Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 17:41:50 -0000 --001a114d6f16c68bb90547a3cb2d Content-Type: text/plain; charset=UTF-8 Following up to myself, I don't think it's sensible for answers to contain a=rtcp-mux-only, because either you accepted mux, in which case all is good, or you rejected it, in which case it was rejected. -Ekr On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla wrote: > I have been reading the mux-exclusive document and I'm not sure it says > quite what we want. Specifically, S 4.2 says: > > When an offerer sends the initial offer, if the offerer wants to > indicate exclusive RTP/RTCP multiplexing for RTP-based media, the > offerer MUST associate an SDP 'rtcp-mux-only' attribute with the > associated SDP media description ("m=" line). > > In addition, if the offerer associates an SDP 'rtcp-mux-only' > attribute with an SDP media description ("m=" line), the offerer MAY > also associate an SDP 'rtcp-mux' attribute with the same SDP media > description ("m=" line), following the procedures in [RFC5761]. > > As I understand this text, the offerer may say the following things: > > 1. No a=rtcp-mux: No muxing. > 2. a=rtcp-mux: I am offering RTCP mux > 3. a=rtcp-mux-only + a=rtcp-mux: I will only do RTCP mux > 4. a=rtcp-mux-only: I will only do RTCP mux (same as #3). > > I don't think the last of these is sensible. No current implementation > will know what to do with a=rtcp-mux-only w/o a=rtcp-mux, so this will > result in interop failures. Thus the MAY in the second graf needs to be > a MUST. > > -Ekr > > --001a114d6f16c68bb90547a3cb2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Following up to myself, I don't think it's sensibl= e for answers to contain a=3Drtcp-mux-only, because either you accepted mux= , in which case all is good, or you rejected it, in which case it was rejec= ted.

-Ekr


On Fri, Feb 3, 2017 at 9:38 AM, Eric = Rescorla <ekr@rtfm.com> wrote:
=
I have been reading the mux-exclusive document and I&= #39;m not sure it says
quite what we want. Specifically, S 4.2 sa= ys:

=C2=A0 =C2=A0When an offerer sends the initial= offer, if the offerer wants to
=C2=A0 =C2=A0indicate exclusive R= TP/RTCP multiplexing for RTP-based media, the
=C2=A0 =C2=A0offere= r MUST associate an SDP 'rtcp-mux-only' attribute with the
=C2=A0 =C2=A0associated SDP media description ("m=3D" line).

=C2=A0 =C2=A0In addition, if the offerer associates = an SDP 'rtcp-mux-only'
=C2=A0 =C2=A0attribute with an SDP= media description ("m=3D" line), the offerer MAY
=C2= =A0 =C2=A0also associate an SDP 'rtcp-mux' attribute with the same = SDP media
=C2=A0 =C2=A0description ("m=3D" line), follo= wing the procedures in [RFC5761].

As I understand = this text, the offerer may say the following things:

=C2=A01. No a=3Drtcp-mux: No muxing.
=C2=A02. a=3Drtcp-mux: I = am offering RTCP mux
=C2=A03. a=3Drtcp-mux-only + a=3Drtcp-mux: I= will only do RTCP mux
=C2=A04. a=3Drtcp-mux-only: I will only do= RTCP mux (same as #3).

I don't think the last= of these is sensible. No current implementation
will know what t= o do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will
result= in interop failures. Thus the MAY in the second graf needs to be
a MUST.

-Ekr


--001a114d6f16c68bb90547a3cb2d-- From nobody Fri Feb 3 10:05:57 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921061294B3 for ; Fri, 3 Feb 2017 10:05:55 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ae5QbTEbYoZ for ; Fri, 3 Feb 2017 10:05:54 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C83B129494 for ; Fri, 3 Feb 2017 10:05:54 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id 11so6164516qkl.3 for ; Fri, 03 Feb 2017 10:05:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=krcIJ0Kkwu9tWDLnjtOu8VsHX+OtcP/QVPAaXRBgNug=; b=pvxJtOtqRYWSLzD85NHxS3fmikGv8OgGX34gI29AkPEhWyZGe+qGfMAQBD1z/f5QBd F3s4bZDqGVDH3uvE4usqfPFFry1rqLIeDMfFrKEMWM2Qb/Iduc7W60tq28PUA/g61J1b XmUoY8emFu1r95hq+9A56fKnBR8iKmsVern1B5oe1iq84eKUpvlWPkyEoZyFq0OsEA7R B7vej3wwfLk4R1zGRk7ikcvZxakDN6iUWQu2/WEYulzGqP4Q4Mr7pwY+MMpb1zaIEZSP pt0u1qJeaE0UCnjtVtSQVKZMVDk1bNcTFj3R9WboEVC6b/woHU2dARQo3kkxk6gUSiEj 9U+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=krcIJ0Kkwu9tWDLnjtOu8VsHX+OtcP/QVPAaXRBgNug=; b=kOa80i+KQdws3AEcy5QVbGPcrIUFUV6ncjxf2hOzy4MxGd47RJRKdO0lfkoahUK3Ra 4+3RxXSB1fzTY3QvUAxEh2C4zq7CG3R+EMj7QG9qX7vOds90vk8ioJx21K1z0UHXvSsP qlnmv7OSBVv0OONrZLGCo1D2oyI4ajlH/PJfEkMLfA2BQoazFnKxYgp1SoZmenP63n+z RBVz00mjV1syZmWm6wBTEILraPN0NNzs2Nx1UlHJ9FkI5IE9XtsFcxNcz02WnrSjkZFp slAbBXc5DVratovsHnpFtRDOvXWQv1lrn2an3E32QMsdD00mkkuiE+xIcYrz3X+Ctfti P02A== X-Gm-Message-State: AMke39mvp0YN36tinezIcKibtBbEmWQGF53mBCEU+euYIUpN5B4q6ivMsG3/XIrrC7HPag== X-Received: by 10.55.69.80 with SMTP id s77mr15105722qka.159.1486145153094; Fri, 03 Feb 2017 10:05:53 -0800 (PST) Received: from mail-qt0-f176.google.com (mail-qt0-f176.google.com. [209.85.216.176]) by smtp.gmail.com with ESMTPSA id d52sm25004036qtc.2.2017.02.03.10.05.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 10:05:52 -0800 (PST) Received: by mail-qt0-f176.google.com with SMTP id w20so42846552qtb.1 for ; Fri, 03 Feb 2017 10:05:52 -0800 (PST) X-Received: by 10.200.52.129 with SMTP id w1mr13703013qtb.43.1486145152385; Fri, 03 Feb 2017 10:05:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Fri, 3 Feb 2017 10:05:51 -0800 (PST) In-Reply-To: References: From: Roman Shpount Date: Fri, 3 Feb 2017 13:05:51 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11479b4ae4f6dd0547a4219b Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 18:05:55 -0000 --001a11479b4ae4f6dd0547a4219b Content-Type: text/plain; charset=UTF-8 In 3, offerer sends rtcp-mux and rtcp-mux-only together. If it gets an answer without either rtcp-mux or rtcp-mux-only, offerer must tear down the connection. In 4, offerer sends rtcp-mux-only. If it gets an answer without rtcp-mux-only, offer must tear down the connection. In general 3 is redundant and was intended to be used during transition while rtcp-mux-only is implemented. Regards, _____________ Roman Shpount On Fri, Feb 3, 2017 at 12:41 PM, Eric Rescorla wrote: > Following up to myself, I don't think it's sensible for answers to contain > a=rtcp-mux-only, because either you accepted mux, in which case all is > good, or you rejected it, in which case it was rejected. > > -Ekr > > > On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla wrote: > >> I have been reading the mux-exclusive document and I'm not sure it says >> quite what we want. Specifically, S 4.2 says: >> >> When an offerer sends the initial offer, if the offerer wants to >> indicate exclusive RTP/RTCP multiplexing for RTP-based media, the >> offerer MUST associate an SDP 'rtcp-mux-only' attribute with the >> associated SDP media description ("m=" line). >> >> In addition, if the offerer associates an SDP 'rtcp-mux-only' >> attribute with an SDP media description ("m=" line), the offerer MAY >> also associate an SDP 'rtcp-mux' attribute with the same SDP media >> description ("m=" line), following the procedures in [RFC5761]. >> >> As I understand this text, the offerer may say the following things: >> >> 1. No a=rtcp-mux: No muxing. >> 2. a=rtcp-mux: I am offering RTCP mux >> 3. a=rtcp-mux-only + a=rtcp-mux: I will only do RTCP mux >> 4. a=rtcp-mux-only: I will only do RTCP mux (same as #3). >> >> I don't think the last of these is sensible. No current implementation >> will know what to do with a=rtcp-mux-only w/o a=rtcp-mux, so this will >> result in interop failures. Thus the MAY in the second graf needs to be >> a MUST. >> >> -Ekr >> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a11479b4ae4f6dd0547a4219b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In 3, offerer sends rtcp-mux and rtcp-mux-only togeth= er. If it gets an answer without either rtcp-mux or rtcp-mux-only, offerer = must tear down the connection.

In 4, offerer sends= rtcp-mux-only. If it gets an answer without rtcp-mux-only, offer must tear= down the connection.

In general 3 is redundant an= d was intended to be used during transition while rtcp-mux-only is implemen= ted.

Regards,

_____________
Roman Shpount

On Fri, Feb 3, 2017 at 12:41 PM, Eric Rescor= la <= ekr@rtfm.com> wrote:
Following up to myself, I don't think it's sensible for = answers to contain a=3Drtcp-mux-only, because either you accepted mux, in w= hich case all is good, or you rejected it, in which case it was rejected.
-Ekr


On = Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>
I have been reading= the mux-exclusive document and I'm not sure it says
quite wh= at we want. Specifically, S 4.2 says:

=C2=A0 =C2= =A0When an offerer sends the initial offer, if the offerer wants to
=C2=A0 =C2=A0indicate exclusive RTP/RTCP multiplexing for RTP-based medi= a, the
=C2=A0 =C2=A0offerer MUST associate an SDP 'rtcp-mux-o= nly' attribute with the
=C2=A0 =C2=A0associated SDP media des= cription ("m=3D" line).

=C2=A0 =C2=A0In = addition, if the offerer associates an SDP 'rtcp-mux-only'
=C2=A0 =C2=A0attribute with an SDP media description ("m=3D" li= ne), the offerer MAY
=C2=A0 =C2=A0also associate an SDP 'rtcp= -mux' attribute with the same SDP media
=C2=A0 =C2=A0descript= ion ("m=3D" line), following the procedures in [RFC5761].

As I understand this text, the offerer may say the follow= ing things:

=C2=A01. No a=3Drtcp-mux: No muxing.
=C2=A02. a=3Drtcp-mux: I am offering RTCP mux
=C2=A03. a= =3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux
=C2=A04.= a=3Drtcp-mux-only: I will only do RTCP mux (same as #3).

I don't think the last of these is sensible. No current impleme= ntation
will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-= mux, so this will
result in interop failures. Thus the MAY in the= second graf needs to be
a MUST.

-Ekr



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

--001a11479b4ae4f6dd0547a4219b-- From nobody Fri Feb 3 12:02:54 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F38129872 for ; Fri, 3 Feb 2017 12:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.719 X-Spam-Level: X-Spam-Status: No, score=-17.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR0f2R-ZXcwT for ; Fri, 3 Feb 2017 12:02:51 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53AAB12951E for ; Fri, 3 Feb 2017 12:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33978; q=dns/txt; s=iport; t=1486152171; x=1487361771; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=ecLh4hGC5APOYWd1rjS4xFbM710oeYDfUV9zIRoYkRQ=; b=U/bLYlI8CUFoTMmIWYOUZZ4FQ5xuM0hDHfsVkFFwAb60ui1vIa1hlDzj lzcIMlbilvIZNGRCW63LSO2E7OGYpnnwdyNdBh2akUzQE3u6q8WMR7BZf /CWN6Ub29uB2rG+X2KJbEV38Tzscp7q5uG+DZGBlbgziTmkvQTGnm3Xlw I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C/AQCR4ZRY/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9kYSpfg1iKCJIMlTuCCgMfAQyFLEoCgl4/GAECAQEBAQEBAWI?= =?us-ascii?q?ohGkBAQECAgEBIUsLEAsRAwEBAQEgAQIEAwICJx8JCAYNBgIBAYlgDQ6uSoIlK?= =?us-ascii?q?4sSAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGS4IFgmqEbRaCUIJfBYlvhkmLK5I?= =?us-ascii?q?IgXuFF4MqI4YjkwofODp0HRU7hAs5HRmBZiI1AYkgAQEB?= X-IronPort-AV: E=Sophos;i="5.33,330,1477958400"; d="scan'208,217";a="204357053" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Feb 2017 20:02:44 +0000 Received: from [10.98.149.206] (bxb-fandreas-88113.cisco.com [10.98.149.206]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v13K2hXE025896; Fri, 3 Feb 2017 20:02:44 GMT To: Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B4BFE0DBC@ESESSMB209.ericsson.se> <84ccd5ba-ae06-f35b-92a1-fe6f79b31dce@cisco.com> From: Flemming Andreasen Message-ID: Date: Fri, 3 Feb 2017 15:02:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------51174D54854955993DCF3656" Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:02:53 -0000 This is a multi-part message in MIME format. --------------51174D54854955993DCF3656 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thx Roman -- Flemming On 2/3/17 12:08 PM, Roman Shpount wrote: > I am fine with this direction, especially since we can make sure that > must implement transport is specified for all protocols that support ICE. > > Please keep in mind that ALT #2 will require removal of ICE mismatch > or specifying a fake ICE candidate which matches the transport from m= > line. I think ICE mismatch is only removed for JSEP, not ICE-SDP in > general. > > Regards, > > _____________ > Roman Shpount > > On Fri, Feb 3, 2017 at 8:47 AM, Flemming Andreasen > wrote: > > We issued a consensus call in the IETF 97 meeting on this which > indicated a strong consensus for option 2 as well (see > https://www.ietf.org/proceedings/97/minutes/minutes-97-mmusic-00.html > ). > In lieu of that and since we have only seen one person arguing > against option 2 here, we suggest moving forward with option 2 as > well. If anybody objects to this, please let us know. > > Thanks > > Flemming & Bo (as MMUSIC chairs) > > > > > > On 2/2/17 3:23 PM, Christer Holmberg wrote: >> >> Hi, >> >> Based on the feedback, my suggestion would be to move forward >> with ALT #2. >> >> Now, as I said earlier, that still doesn’t prevent protocols from >> specifying an MIT transport, which is used as default candidate >> (read: ALT #1). >> >> Regarding documentation, I guess it would at least have impact on >> ICE-SDP. The question is whether something is needed for 3264? >> >> Chairs? >> >> Regards, >> >> Christer >> >> *From:*Roman Shpount [mailto:roman@telurix.com] >> *Sent:* 13 January 2017 21:09 >> *To:* Christer Holmberg >> >> *Cc:* mmusic@ietf.org >> *Subject:* Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul >> regarding non-supported transport in m- line of answer >> >> As I have mentioned before, I think ALT#1 is a better option: If >> we propose mandatory to implement UDP based protocol for each >> transport family, only use the mandatory to implement protocol >> for the default candidate, and the transport mismatch problem >> will never occur. >> >> As a bit of background, this issue appeared because of TCP/BFCP, >> which was assumed to be the default protocol for BFCP with ICE. >> Since then, I think we have decided that TCP/BFCP is not going to >> be used with ICE. For all the other protocols that I know >> (UDP/DTLS/SCTP, UDP/TLS/RTP/SAVPF, UDP/DTLS/BFCP, RTP/AVP, etc) >> there is a clear preference that UDP based protocol should be >> used for backwards compatibility. I also do not see a use case >> which will require that only tcp based candidates would be >> included in the offer or the answer. Because of this, I think >> mandatory to implement transport is a better approach. >> >> This also have additional benefits of: >> >> 1. Providing m= and c= line information which will not cause the >> ICE mismatch with older implementations >> >> 2. Not supplying any on the path signaling devices with bogus >> address information required in ALT#2 answer >> >> 3. Improves general chances of negotiation succeeding with end >> points not supporting ICE by picking the protocol more likely to >> succeed (chance of TCP/RTP/AVP succeeding, for instance, are much >> lower then RTP/AVP). >> >> Regards, >> >> >> _____________ >> Roman Shpount >> >> On Fri, Jan 13, 2017 at 7:00 AM, Christer Holmberg >> > > wrote: >> >> The subject shall be ICE-SDP: Verify decision made… >> >> *From: *mmusic > > on behalf of Christer >> Holmberg > > >> *Date: *Friday 13 January 2017 at 13:32 >> *To: *"mmusic@ietf.org " >> > >> *Subject: *[MMUSIC] SIP-SDP: Verify decision made in Seoul >> regarding non-supported transport in m- line of answer >> >> Hi, >> >> In Seoul we discussed a number of issues related to ICE-SDP. >> We made some decisions, and I got action points to verify one >> of those on the list. >> >> The associated slides can be found here: >> >> https://www.ietf.org/proceedings/97/slides/slides-97-mmusic-ice-sip-sdp-00.pdf >> >> >> The issue (slides 4-6) was when an answerer receives an offer >> with a m- line transport that it doesn’t support. The current >> O/A rules say that the transport in the answer must match the >> transport in the offer. >> >> However, if ICE is used, there may be transports (offered >> using ICE candidates) that the answerer DOES support. >> >> Based on the discussions, there was strong consensus to go >> for Alt#2, which was allowing a transport in the m- line of >> the answer even if the answerer doesn’t support it, as ICE >> candidates will be used to determine the transport. >> >> Does anyone object to Alt#2? >> >> Regards, >> >> Christer >> >> >> _______________________________________________ >> 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 >> > --------------51174D54854955993DCF3656 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thx Roman

-- Flemming

On 2/3/17 12:08 PM, Roman Shpount wrote:
I am fine with this direction, especially since we can make sure that must implement transport is specified for all protocols that support ICE.

Please keep in mind that ALT #2 will require removal of ICE mismatch or specifying a fake ICE candidate which matches the transport from m= line. I think ICE mismatch is only removed for JSEP, not ICE-SDP in general.

Regards,

_____________
Roman Shpount

On Fri, Feb 3, 2017 at 8:47 AM, Flemming Andreasen <fandreas@cisco.com> wrote:
We issued a consensus call in the IETF 97 meeting on this which indicated a strong consensus for option 2 as well (see https://www.ietf.org/proceedings/97/minutes/minutes-97-mmusic-00.html). In lieu of that and since we have only seen one person arguing against option 2 here, we suggest moving forward with option 2 as well. If anybody objects to this, please let us know.

Thanks

    Flemming & Bo (as MMUSIC chairs)





On 2/2/17 3:23 PM, Christer Holmberg wrote:

Hi,

 

Based on the feedback, my suggestion would be to move forward with ALT #2.

 

Now, as I said earlier, that still doesn’t prevent protocols from specifying an MIT transport, which is used as default candidate (read: ALT #1).

 

Regarding documentation, I guess it would at least have impact on ICE-SDP. The question is whether something is needed for 3264?

 

Chairs?

 

Regards,

 

Christer

 

From: Roman Shpount [mailto:roman@telurix.com]
Sent: 13 January 2017 21:09
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer

 

As I have mentioned before, I think ALT#1 is a better option: If we propose mandatory to implement UDP based protocol for each transport family, only use the mandatory to implement protocol for the default candidate, and the transport mismatch problem will never occur.

 

As a bit of background, this issue appeared because of TCP/BFCP, which was assumed to be the default protocol for BFCP with ICE. Since then, I think we have decided that TCP/BFCP is not going to be used with ICE. For all the other protocols that I know (UDP/DTLS/SCTP, UDP/TLS/RTP/SAVPF, UDP/DTLS/BFCP, RTP/AVP, etc) there is a clear preference that UDP based protocol should be used for backwards compatibility. I also do not see a use case which will require that only tcp based candidates would be included in the offer or the answer. Because of this, I think mandatory to implement transport is a better approach.

 

This also have additional benefits of: 

 

1. Providing m= and c= line information which will not cause the ICE mismatch with older implementations

2. Not supplying any on the path signaling devices with bogus address information required in ALT#2 answer

3. Improves general chances of negotiation succeeding with end points not supporting ICE by picking the protocol more likely to succeed (chance of TCP/RTP/AVP succeeding, for instance, are much lower then RTP/AVP).

 

Regards,


_____________
Roman Shpount

 

On Fri, Jan 13, 2017 at 7:00 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

The subject shall be ICE-SDP: Verify decision made…

 

From: mmusic <mmusic-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
Date: Friday 13 January 2017 at 13:32
To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer

 

Hi,

 

In Seoul we discussed a number of issues related to ICE-SDP. We made some decisions, and I got action points to verify one of those on the list.

 

The associated slides can be found here:

 

 

 

The issue (slides 4-6) was when an answerer receives an offer with a m- line transport that it doesn’t support. The current O/A rules say that the transport in the answer must match the transport in the offer.

 

However, if ICE is used, there may be transports (offered using ICE candidates) that the answerer DOES support.

 

Based on the discussions, there was strong consensus to go for Alt#2, which was allowing a transport in the m- line of the answer even if the answerer doesn’t support it, as ICE candidates will be used to determine the transport.

 

Does anyone object to Alt#2?

 

Regards,

 

Christer

 

 

 

 

 

 

 

 

 

 

 

 


_______________________________________________
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
--------------51174D54854955993DCF3656-- From nobody Fri Feb 3 14:08:06 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AA31299CF for ; Fri, 3 Feb 2017 14:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxmAMfGrZyem for ; Fri, 3 Feb 2017 14:08:03 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43CE1299CE for ; Fri, 3 Feb 2017 14:08:02 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id l19so20539641ywc.2 for ; Fri, 03 Feb 2017 14:08:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G8k3ghzQnScbgNju9+AH0GXHyJk+SqsJgXKh4nX+j3k=; b=ExSHELFAuhAyegF7zBO0dFtPd35J8w1F/gix4twoyB9P3niiMVEK+Tv3xyAG7iyRcJ doZ4BBdeAA5j16CFd81j1hdhcWlEwsdErmtTyhAQD1KiKSetxzsLW9UTQ1D7KSa3vbIt mGqEoXnyHyLAqX+XSCno3Xp2u0TS6n9PG6PVPPj2rfyCyqLobAWe4Kg669GNSrVPspcw eYV4DtBUGga/LndBwm5IoiAJyez4lXNnL7NwMNyTnxjOMdtM+Ie6jEJNVMmEbBloa4WA Bsp0+/sy/e1Svg0aoT1IlF6Np6JH+gDo+ayrBbI7ugRV3FaDwClh+Dy9H/3HgFhpQZA3 JhkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G8k3ghzQnScbgNju9+AH0GXHyJk+SqsJgXKh4nX+j3k=; b=G8P8ar8pnulsrjvL7kAWkTNSY9fYvJRAKQk0B2prXP9t54FHutTHmXWkw1IIHArGbg gg2v4GXV+m79iVoR/MANWDC3Ls/xMiU7ohfu2TA+ew2FTSH66ldYoHJJxyNLreA6ZTDA 6THHWeAmOJ0pb4F8VY6z69rW3uE0Ojit8RPWI57NlFKVFpOWGwbXD1DVy5A0SxJq1TBw h2yMsvY0LLiRI6xD2lVxM8vFmELsLhgBhn/YKVxQm8e8tdW7qrrpK8Jhbe6A0raz6jV4 REMnZj2GlvrSbb8McaN+NM44pW1xgQ5caEaxd4eCR2J57YecfSN+og5Tc0+V+k881r4D fuUA== X-Gm-Message-State: AIkVDXK+EMOAsyZvpZDvQDHOoFaYPp9SwHo2Y7ruYgY6HVXCtkEZknJK5cq4YTwXvMrqSzcbvqhaomHd9yiZww== X-Received: by 10.129.125.84 with SMTP id y81mr10542708ywc.120.1486159682029; Fri, 03 Feb 2017 14:08:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Fri, 3 Feb 2017 14:07:21 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 3 Feb 2017 14:07:21 -0800 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=001a114928baed79170547a783fd Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 22:08:05 -0000 --001a114928baed79170547a783fd Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2017 at 10:05 AM, Roman Shpount wrote: > In 3, offerer sends rtcp-mux and rtcp-mux-only together. If it gets an > answer without either rtcp-mux or rtcp-mux-only, offerer must tear down the > connection. > > In 4, offerer sends rtcp-mux-only. If it gets an answer without > rtcp-mux-only, offer must tear down the connection. > > In general 3 is redundant and was intended to be used during transition > while rtcp-mux-only is implemented. > You can only do 4 once there is no chance that there will ever be a peer which would do mux but will not recognize rtcp-mux-only. That seems unlikely to ever occur. -Ekr > Regards, > > _____________ > Roman Shpount > > On Fri, Feb 3, 2017 at 12:41 PM, Eric Rescorla wrote: > >> Following up to myself, I don't think it's sensible for answers to >> contain a=rtcp-mux-only, because either you accepted mux, in which case all >> is good, or you rejected it, in which case it was rejected. >> >> -Ekr >> >> >> On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla wrote: >> >>> I have been reading the mux-exclusive document and I'm not sure it says >>> quite what we want. Specifically, S 4.2 says: >>> >>> When an offerer sends the initial offer, if the offerer wants to >>> indicate exclusive RTP/RTCP multiplexing for RTP-based media, the >>> offerer MUST associate an SDP 'rtcp-mux-only' attribute with the >>> associated SDP media description ("m=" line). >>> >>> In addition, if the offerer associates an SDP 'rtcp-mux-only' >>> attribute with an SDP media description ("m=" line), the offerer MAY >>> also associate an SDP 'rtcp-mux' attribute with the same SDP media >>> description ("m=" line), following the procedures in [RFC5761]. >>> >>> As I understand this text, the offerer may say the following things: >>> >>> 1. No a=rtcp-mux: No muxing. >>> 2. a=rtcp-mux: I am offering RTCP mux >>> 3. a=rtcp-mux-only + a=rtcp-mux: I will only do RTCP mux >>> 4. a=rtcp-mux-only: I will only do RTCP mux (same as #3). >>> >>> I don't think the last of these is sensible. No current implementation >>> will know what to do with a=rtcp-mux-only w/o a=rtcp-mux, so this will >>> result in interop failures. Thus the MAY in the second graf needs to be >>> a MUST. >>> >>> -Ekr >>> >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > --001a114928baed79170547a783fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 3, 2017 at 10:05 AM, Roman Shpount <roman@telurix.com> wrote:
In 3, off= erer sends rtcp-mux and rtcp-mux-only together. If it gets an answer withou= t either rtcp-mux or rtcp-mux-only, offerer must tear down the connection.<= /div>

In 4, offerer sends rtcp-mux-only. If it gets an a= nswer without rtcp-mux-only, offer must tear down the connection.

In general 3 is redundant and was intended to be used durin= g transition while rtcp-mux-only is implemented.

You can only do 4 once there is no chance that there will= ever be a peer which would do mux but will not recognize rtcp-mux-only. Th= at seems unlikely to ever occur.

-Ekr
= =C2=A0
Regards,

__= ___________
Roman Shpount

On Fri, Feb 3, 2017 a= t 12:41 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Follow= ing up to myself, I don't think it's sensible for answers to contai= n a=3Drtcp-mux-only, because either you accepted mux, in which case all is = good, or you rejected it, in which case it was rejected.

-Ekr


On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla <ekr@rtfm= .com> wrote:
I have been reading the mux-exclusive document and I'm not sure= it says
quite what we want. Specifically, S 4.2 says:
=
=C2=A0 =C2=A0When an offerer sends the initial offer, if the= offerer wants to
=C2=A0 =C2=A0indicate exclusive RTP/RTCP multip= lexing for RTP-based media, the
=C2=A0 =C2=A0offerer MUST associa= te an SDP 'rtcp-mux-only' attribute with the
=C2=A0 =C2= =A0associated SDP media description ("m=3D" line).

=
=C2=A0 =C2=A0In addition, if the offerer associates an SDP '= rtcp-mux-only'
=C2=A0 =C2=A0attribute with an SDP media descr= iption ("m=3D" line), the offerer MAY
=C2=A0 =C2=A0also= associate an SDP 'rtcp-mux' attribute with the same SDP media
=C2=A0 =C2=A0description ("m=3D" line), following the proce= dures in [RFC5761].

As I understand this text, the= offerer may say the following things:

=C2=A01. No= a=3Drtcp-mux: No muxing.
=C2=A02. a=3Drtcp-mux: I am offering RT= CP mux
=C2=A03. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do = RTCP mux
=C2=A04. a=3Drtcp-mux-only: I will only do RTCP mux (sam= e as #3).

I don't think the last of these is s= ensible. No current implementation
will know what to do with a=3D= rtcp-mux-only w/o a=3Drtcp-mux, so this will
result in interop fa= ilures. Thus the MAY in the second graf needs to be
a MUST.
=

-Ekr



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


--001a114928baed79170547a783fd-- From nobody Fri Feb 3 15:09:48 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4845129A3B; Fri, 3 Feb 2017 15:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 89z5ByHPAOur; Fri, 3 Feb 2017 15:09:45 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9A7129A38; Fri, 3 Feb 2017 15:09:45 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v13N9icN065745 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 3 Feb 2017 17:09:45 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: draft-ietf-mmusic-4572-update.all@ietf.org, mmusic Date: Fri, 03 Feb 2017 17:09:48 -0600 Message-ID: References: <148606618203.13969.16563621294955094011.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Subject: [MMUSIC] Fwd: I-D Action: draft-ietf-mmusic-4572-update-13.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 23:09:47 -0000 I approved this version. Thanks! Ben. Forwarded message: > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-4572-update-13.txt > Date: Thu, 02 Feb 2017 12:09:42 -0800 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiparty Multimedia Session Control > of the IETF. > > Title : Connection-Oriented Media Transport over TLS > in SDP > Authors : Jonathan Lennox > Christer Holmberg > Filename : draft-ietf-mmusic-4572-update-13.txt > Pages : 17 > Date : 2017-02-02 > > Abstract: > This document specifies how to establish secure connection-oriented > media transport sessions over the Transport Layer Security (TLS) > protocol using the Session Description Protocol (SDP). It defines > the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax > and semantics for an SDP 'fingerprint' attribute that identifies > the > certificate that will be presented for the TLS session. This > mechanism allows media transport over TLS connections to be > established securely, so long as the integrity of session > descriptions is assured. > > This document obsoletes RFC 4572, by clarifying the usage of > multiple > fingerprints. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-4572-update-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-4572-update-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/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Sat Feb 4 03:45:10 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D8D1294D6; Sat, 4 Feb 2017 03:45:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148620870421.2873.15674324934714501519.idtracker@ietfa.amsl.com> Date: Sat, 04 Feb 2017 03:45:04 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-18.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 11:45:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : SDP: Session Description Protocol Authors : Mark Handley Van Jacobson Colin Perkins Ali Begen Filename : draft-ietf-mmusic-rfc4566bis-18.txt Pages : 61 Date : 2017-02-04 Abstract: This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 4 19:23:13 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 814B11294FE; Sat, 4 Feb 2017 19:23:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Carpenter To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148626499152.2778.12224491829240452688.idtracker@ietfa.amsl.com> Date: Sat, 04 Feb 2017 19:23:11 -0800 Archived-At: Cc: draft-ietf-mmusic-sctp-sdp.all@ietf.org, mmusic@ietf.org, brian.e.carpenter@gmail.com Subject: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 03:23:11 -0000 Reviewer: Brian Carpenter Review result: Ready with Nits Gen-ART Last Call review of draft-ietf-mmusic-sctp-sdp-22 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-mmusic-sctp-sdp-22.txt Reviewer: Brian Carpenter Review Date: 2017-02-XX IETF LC End Date: 2017-02-09 IESG Telechat date: Summary: Ready with nits -------- Comments: --------- Two points I noted in the writeup: "There are existing implementations of earlier versions of the document..." Excellent, but I wonder why we don't see Implementation Status sections under RFC 6982 in more Last Call drafts. "IPv6 address examples are not necessary since IP version differences are immaterial to the purpose of the specification." It's just as easy to give an IPv6 example though, and more future proof. Minor issue: (almost a nit) ------------ > 1. Introduction ... > NOTE: Due to the characteristics of TCP, usage of 'TCP/DTLS/SCTP' > will always force ordered and reliable delivery of the SCTP packets, > which limits the usage of the SCTP options. Therefore, it is > RECOMMENDED that TCP is only used in situations where UDP traffic is > blocked. Why would one choose 'TCP/DTLS/SCTP' rather than just 'TCP/TLS'? I don't object to it being specified, but since you don't support multihoming or multiple associations, what is the use case, in a few words? Nits: ----- > 4.4.2. SDP Media Description values > > m= line parameter parameter value(s) > ------------------------------------------------------------------ > : "application" > : "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP" > : UDP port number (for "UDP/DTLS/SCTP") > TCP port number (for ""UDP/DTLS/SCTP") I think the last line should be: TCP port number (for "TCP/DTLS/SCTP") There is some inconsistency in the use of quotation marks: "UDP/DTLS/SCTP" or 'UDP/DTLS/SCTP' From nobody Sun Feb 5 06:14:18 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C4A129434; Sun, 5 Feb 2017 06:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7O-FEONiP2gA; Sun, 5 Feb 2017 06:14:11 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0DB129422; Sun, 5 Feb 2017 06:14:09 -0800 (PST) X-AuditID: c1b4fb30-b99fe70000007389-7f-5897332e64e5 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id E0.C8.29577.E2337985; Sun, 5 Feb 2017 15:14:08 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0319.002; Sun, 5 Feb 2017 15:14:06 +0100 From: Christer Holmberg To: Brian Carpenter , "gen-art@ietf.org" Thread-Topic: Review of draft-ietf-mmusic-sctp-sdp-22 Thread-Index: AQHSf18vg7KvnMe4fUWDAsU2eyafs6Faa6TQ Date: Sun, 5 Feb 2017 14:14:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFE5BE2@ESESSMB209.ericsson.se> References: <148626499152.2778.12224491829240452688.idtracker@ietfa.amsl.com> In-Reply-To: <148626499152.2778.12224491829240452688.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.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbFdVNfAeHqEwdvdvBZtF/cxWWzq38Ri cfXVZxaLqcsfsziweOycdZfdY8mSn0wBTFFcNimpOZllqUX6dglcGb3nnrEVnJCu2Nie1cD4 RqqLkZNDQsBE4vv2TqYuRi4OIYF1jBI3761mhHAWMUr0PFkJ5HBwsAlYSHT/0wZpEBGIkujZ upYZpIZZoIFR4sDJJkaQhDDQpF2HWlggikwlbi5bzgRhG0lc3d3LDmKzCKhI3Hi2lA3E5hXw lZjz/CZYvRCQferPVmYQm1PAT2LB+oVgcUYBMYnvp9aAzWEWEJe49WQ+E8TVAhJL9pxnhrBF JV4+/scKYStJLLr9mQnkZmYBTYn1u/QhWhUlpnQ/ZIdYKyhxcuYTlgmMorOQTJ2F0DELSccs JB0LGFlWMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgTGzcEtvw12ML587niIUYCDUYmH90PM tAgh1sSy4srcQ4wSHMxKIrw7daZHCPGmJFZWpRblxxeV5qQWH2KU5mBREuc1W3k/XEggPbEk NTs1tSC1CCbLxMEp1cBYw5m4e/+h1GPyHJevmt9x2+c+20juWVNIyf3i9Y67zvfc3Ml2If+Y +7XXFYx/UmylH7/hmfNYq/6IN3vFR8fyecuUP7T6h76qEvjEmbwv5suSJ9HXMvdPf9KnffiT bH5743+JW6eEM/t9236F18odkX6azF2r8uCZfOW910wd/7WPf/1b6sirxFKckWioxVxUnAgA hTJSSpcCAAA= Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 14:14:12 -0000 SGkgQnJpYW4sDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXchIFBsZWFzZSBzZWUgaW5saW5lLg0K DQouLi4NCg0KQ29tbWVudHM6DQotLS0tLS0tLS0NCg0KPlR3byBwb2ludHMgSSBub3RlZCBpbiB0 aGUgd3JpdGV1cDoNCj4iVGhlcmUgYXJlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBvZiBlYXJs aWVyIHZlcnNpb25zIG9mIHRoZSBkb2N1bWVudC4uLiINCj4NCj5FeGNlbGxlbnQsIGJ1dCBJIHdv bmRlciB3aHkgd2UgZG9uJ3Qgc2VlIEltcGxlbWVudGF0aW9uIFN0YXR1cyBzZWN0aW9ucyB1bmRl ciBSRkMgNjk4MiBpbiBtb3JlIExhc3QgQ2FsbCBkcmFmdHMuDQoNClBlcmhhcHMgYSB0b3BpYyBm b3IgYW4gSUVURiBjaGFpcnMgbHVuY2ggcHJlc2VudGF0aW9uPw0KDQpJIGhhdmUgdG8gYWRtaXQg dGhhdCBJIGRpZCBub3Qga25vdyBhYm91dCA2OTgyIChub3cgb2Jzb2xldGVkIGJ5IDc5NDIpLiBN eSBzdWdnZXN0aW9uIHdvdWxkIHRvIG5vdCBjb2xsZWN0IHRoYXQgaW5mb3JtYXRpb24gZm9yIHRo aXMgZHJhZnQgYXQgdGhpcyBwb2ludCBvZiB0aW1lLCBhcyBpdCBjb3VsZCB0YWtlIHNvbWUgdGlt ZS4NCg0KPiJJUHY2IGFkZHJlc3MgZXhhbXBsZXMgYXJlIG5vdCBuZWNlc3Nhcnkgc2luY2UgSVAg dmVyc2lvbiBkaWZmZXJlbmNlcyBhcmUgaW1tYXRlcmlhbCB0byB0aGUgcHVycG9zZSBvZiB0aGUg c3BlY2lmaWNhdGlvbi4iDQo+DQo+SXQncyBqdXN0IGFzIGVhc3kgdG8gZ2l2ZSBhbiBJUHY2IGV4 YW1wbGUgdGhvdWdoLCBhbmQgbW9yZSBmdXR1cmUgcHJvb2YuDQoNCkkgY2FuIG1vZGlmeSB0aGUg YWRkcmVzcyBpbiB0aGUgZXhhbXBsZSwgZnJvbSBJUHY0IHRvIHY2Lg0KDQoNCk1pbm9yIGlzc3Vl OiAoYWxtb3N0IGEgbml0KQ0KLS0tLS0tLS0tLS0tDQoNCjEuICBJbnRyb2R1Y3Rpb24NCi4uLg0K Pj4gICBOT1RFOiBEdWUgdG8gdGhlIGNoYXJhY3RlcmlzdGljcyBvZiBUQ1AsIHVzYWdlIG9mICdU Q1AvRFRMUy9TQ1RQJw0KPj4gICB3aWxsIGFsd2F5cyBmb3JjZSBvcmRlcmVkIGFuZCByZWxpYWJs ZSBkZWxpdmVyeSBvZiB0aGUgU0NUUA0KPj4gICBwYWNrZXRzLCB3aGljaCBsaW1pdHMgdGhlIHVz YWdlIG9mIHRoZSBTQ1RQIG9wdGlvbnMuICBUaGVyZWZvcmUsIGl0IGlzDQo+PiAgIFJFQ09NTUVO REVEIHRoYXQgVENQIGlzIG9ubHkgdXNlZCBpbiBzaXR1YXRpb25zIHdoZXJlIFVEUCB0cmFmZmlj DQo+PiAgIGlzIGJsb2NrZWQuDQo+DQo+IFdoeSB3b3VsZCBvbmUgY2hvb3NlICdUQ1AvRFRMUy9T Q1RQJyByYXRoZXIgdGhhbiBqdXN0ICdUQ1AvVExTJz8gSSBkb24ndCBvYmplY3QgdG8gaXQgYmVp bmcgc3BlY2lmaWVkLCBidXQgc2luY2UgeW91IA0KPiBkb24ndCBzdXBwb3J0IG11bHRpaG9taW5n IG9yIG11bHRpcGxlIGFzc29jaWF0aW9ucywgd2hhdCBpcyB0aGUgdXNlIGNhc2UsIGluIGEgZmV3 IHdvcmRzPw0KDQpTQ1RQIHN1cHBvcnRzIG11bHRpcGxlIFNDVFAgc3RyZWFtcyBvdmVyIGEgc2lu Z2xlIGFzc29jaWF0aW9uLCBhbmQgeW91IGNhbiBzdGlsbCB1c2UgdGhhdCB3aXRoICdUQ1AvRFRM Uy9TQ1RQJy4gRS5nLCB0aGUgV2ViUlRDIERhdGEgQ2hhbm5lbCBwcm90b2NvbCB1c2VzIHR3byBz dHJlYW1zIHRvIHJlYWxpemUgYSBkYXRhIGNoYW5uZWwuDQoNCkkgY291bGQgbW9kaWZ5IHRoZSBm aXJzdCBzZW50ZW5jZSBhcyBmb2xsb3dpbmc6DQoNCiAgICAgICAgIk5PVEU6IER1ZSB0byB0aGUg Y2hhcmFjdGVyaXN0aWNzIG9mIFRDUCwgd2hpbGUgbXVsdGlwbGUgU0NUUCBzdHJlYW1zDQogICAg ICAgICBjYW4gc3RpbGwgYmUgdXNlZCwgdXNhZ2Ugb2YgJ1RDUC9EVExTL1NDVFAnIHdpbGwgYWx3 YXlzIGZvcmNlLi4uLiINCg0KTml0czoNCi0tLS0tDQoNCj4+IDQuNC4yLiAgU0RQIE1lZGlhIERl c2NyaXB0aW9uIHZhbHVlcw0KPj4NCj4+ICAgICAgbT0gbGluZSBwYXJhbWV0ZXIgICAgICAgIHBh cmFtZXRlciB2YWx1ZShzKQ0KPj4gICAgIA0KPj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ICAgICAgPG1lZGlhPjog ICAgICAgICAgICAgICAgICJhcHBsaWNhdGlvbiINCj4+ICAgICAgPHByb3RvPjogICAgICAgICAg ICAgICAgICJVRFAvRFRMUy9TQ1RQIiBvciAiVENQL0RUTFMvU0NUUCINCj4+ICAgICAgPHBvcnQ+ OiAgICAgICAgICAgICAgICAgIFVEUCBwb3J0IG51bWJlciAoZm9yICJVRFAvRFRMUy9TQ1RQIikN Cj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRDUCBwb3J0IG51bWJlciAo Zm9yICIiVURQL0RUTFMvU0NUUCIpDQo+DQo+IEkgdGhpbmsgdGhlIGxhc3QgbGluZSBzaG91bGQg YmU6IFRDUCBwb3J0IG51bWJlciAoZm9yICJUQ1AvRFRMUy9TQ1RQIikNCg0KQ29ycmVjdC4gV2ls bCBiZSBmaXhlZC4NCg0KPlRoZXJlIGlzIHNvbWUgaW5jb25zaXN0ZW5jeSBpbiB0aGUgdXNlIG9m IHF1b3RhdGlvbiBtYXJrczogIlVEUC9EVExTL1NDVFAiIG9yICdVRFAvRFRMUy9TQ1RQJw0KDQpJ J2xsIGZpeCB0aGF0LiBJIHdpbGwgdXNlIHNpbmdsZSBxdW90ZXMuDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCg== From nobody Sun Feb 5 11:05:49 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBBA1294B1; Sun, 5 Feb 2017 11:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2fgRpV_Q26l; Sun, 5 Feb 2017 11:05:47 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C1B12944B; Sun, 5 Feb 2017 11:05:47 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id f144so17985519pfa.2; Sun, 05 Feb 2017 11:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=sidxvlWB/QdR1je1FPvMFJt4/ybtvfcjZqvx764GwUQ=; b=pI/do7v3NP0eF4QsB5siE+qu/6MMoq6DVQMVctZd74HQCzxGWnJtJN5zWBTNGCJqzz YpLAbzMGSOEdqjyOKeZMoZCD/z1AJhuzzhdK4zikl8BEweki7Z4gpXeB8wVHmbImVMq0 Aj4DmFbqht6cEt5qkjG8xvUPR7Bn34CEhLbmiuLWphCxRpUe+1EEKnHghF3o1+mlWV1J ywEo+nSYVJSDt+IOEyebRqp0wsCk1hhakzbkQZbvZBBEVqq7W+fhj9kV3yS+hCgB7x8E MbK4F6B8FWS9QjtrP2a62L9y9wwE6yMPkwCmGMruDFZ9zUVFy+pD87B0iI8yO7hYg+w4 Y3+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=sidxvlWB/QdR1je1FPvMFJt4/ybtvfcjZqvx764GwUQ=; b=BVuFZU0WFtRbfemH5DY+HXwTkeUpUhgOUjStcwALzdUt/BgZnMEAUadlaQRJFNxC8y CZ444YI5egY016IoOsF+FI73LkIyiIbRYNlo2WUOz/fXU+d5HPux1kirAfklte3mTLq4 4H1prIOZIaVe5CoOq5LcB8TXwrR2tTtgUS0i9vbsrQoy6228Do02qg2/d08gr8WXX1q/ Nohhe2wgBSflUPdJa/8FYHt95H0A3kKdI3xQL9kmwZ+l6xhgyKxrJAKzkWgR1peDLkvb Wp/90Q+qlHoFy40uX4KJCKzL3yPMRKzQ6KIaSQDx3WeMXuwk1sd12yOwIkWudUQk40WO 6jjQ== X-Gm-Message-State: AIkVDXK5eff2bzPKHVltmKHoQFs1/y8sxxuyAVzUU/Dp1kaM7veYfuNVLTx3x72VGXU95w== X-Received: by 10.98.44.10 with SMTP id s10mr9069408pfs.161.1486321546633; Sun, 05 Feb 2017 11:05:46 -0800 (PST) Received: from ?IPv6:2406:e007:43d3:1:28cc:dc4c:9703:6781? ([2406:e007:43d3:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z77sm82832211pfk.47.2017.02.05.11.05.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Feb 2017 11:05:45 -0800 (PST) To: Christer Holmberg , "gen-art@ietf.org" References: <148626499152.2778.12224491829240452688.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFE5BE2@ESESSMB209.ericsson.se> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 6 Feb 2017 08:05:40 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFE5BE2@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 19:05:48 -0000 Hi Christer, On 06/02/2017 03:14, Christer Holmberg wrote: > Hi Brian, > > Thanks for your review! Please see inline. > > ... > > Comments: > --------- > >> Two points I noted in the writeup: >> "There are existing implementations of earlier versions of the document..." >> >> Excellent, but I wonder why we don't see Implementation Status sections under RFC 6982 in more Last Call drafts. > > Perhaps a topic for an IETF chairs lunch presentation? Or at least a short reminder! > > I have to admit that I did not know about 6982 (now obsoleted by 7942). My suggestion would to not collect that information for this draft at this point of time, as it could take some time. Agreed. >> "IPv6 address examples are not necessary since IP version differences are immaterial to the purpose of the specification." >> >> It's just as easy to give an IPv6 example though, and more future proof. > > I can modify the address in the example, from IPv4 to v6. As you wish. > Minor issue: (almost a nit) > ------------ > > 1. Introduction > ... >>> NOTE: Due to the characteristics of TCP, usage of 'TCP/DTLS/SCTP' >>> will always force ordered and reliable delivery of the SCTP >>> packets, which limits the usage of the SCTP options. Therefore, it is >>> RECOMMENDED that TCP is only used in situations where UDP traffic >>> is blocked. >> >> Why would one choose 'TCP/DTLS/SCTP' rather than just 'TCP/TLS'? I don't object to it being specified, but since you >> don't support multihoming or multiple associations, what is the use case, in a few words? > > SCTP supports multiple SCTP streams over a single association, and you can still use that with 'TCP/DTLS/SCTP'. E.g, the WebRTC Data Channel protocol uses two streams to realize a data channel. OK. (I now remember that I raised essentially the same question when reviewing draft-ietf-clue-datachannel. Actually I'm glad to see SCTP proving useful.) > I could modify the first sentence as following: > > "NOTE: Due to the characteristics of TCP, while multiple SCTP streams > can still be used, usage of 'TCP/DTLS/SCTP' will always force...." OK > > Nits: > ----- > >>> 4.4.2. SDP Media Description values >>> >>> m= line parameter parameter value(s) >>> >>> ------------------------------------------------------------------ >>> : "application" >>> : "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP" >>> : UDP port number (for "UDP/DTLS/SCTP") >>> TCP port number (for ""UDP/DTLS/SCTP") >> >> I think the last line should be: TCP port number (for "TCP/DTLS/SCTP") > > Correct. Will be fixed. > >> There is some inconsistency in the use of quotation marks: "UDP/DTLS/SCTP" or 'UDP/DTLS/SCTP' > > I'll fix that. I will use single quotes. Thanks, Brian From nobody Mon Feb 6 01:16:02 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9B9129CC1; Mon, 6 Feb 2017 01:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 oJ1-5txFrgQt; Mon, 6 Feb 2017 01:15:56 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85B9129CC2; Mon, 6 Feb 2017 01:15:55 -0800 (PST) X-AuditID: c1b4fb2d-fb9fc980000059d1-67-58983ec96827 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id 89.1F.22993.9CE38985; Mon, 6 Feb 2017 10:15:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0319.002; Mon, 6 Feb 2017 10:15:52 +0100 From: Christer Holmberg To: Brian E Carpenter , "gen-art@ietf.org" Thread-Topic: Review of draft-ietf-mmusic-sctp-sdp-22 Thread-Index: AQHSf18vg7KvnMe4fUWDAsU2eyafs6Faa6TQgABKiACAAQ+dAA== Date: Mon, 6 Feb 2017 09:15:50 +0000 Message-ID: References: <148626499152.2778.12224491829240452688.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFE5BE2@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5EBCF2F9A4AA4F4D83A06CA03DA20AED@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7se5JuxkRBrduWFm0XdzHZLGpfxOL xdVXn1kspi5/zOLA4rFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZUzY08FYsFGqYk5rUAPj dpEuRk4OCQETicWtZ9m6GLk4hATWMUq86N3HCOEsYpS4emgRSxcjBwebgIVE9z9tkAYRgRiJ nS+6mEBqmAUaGCUOnGxiBEkIA02a0v6aEaLIVOLmsuVMELaTxMv+NmYQm0VARaKvfRmYzStg LTHp+GcWiGVHGCV6L5wEa+YUsJU41HUZzGYUEJP4fmoN2CBmAXGJW0/mM0GcLSCxZM95Zghb VOLl43+sILaogJ7E8udroOJKEj82XGKB6NWTuDF1ChvIM8xAi8//koYIa0ssW/ga6h5BiZMz n7BMYBSfhWTbLCTdsxC6ZyHpnoWkewEj6ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwAg8 uOW37g7G1a8dDzEKcDAq8fB+sJ0eIcSaWFZcmXuIUYKDWUmEN9ByRoQQb0piZVVqUX58UWlO avEhRmkOFiVxXrOV98OFBNITS1KzU1MLUotgskwcnFINjOvSVy2b8PL6em7hmsjmF1IsDX1X 2QTWbzDbJx74/sxpI+522XV9RmnP15w1XJU76f5U/58KP19EPXN+s3al1bHY06brndM2q86o n32qvPmOZp7dzClut39mOq7YLMCkYfjOc962qz6dMVNu/JDWenFvffZJzbkSncGJ7tc0u8y7 nA0+mMlpliixFGckGmoxFxUnAgBG3FYOvAIAAA== Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 09:15:58 -0000 Hi, I=B9ve created a pull request with the changes based on Brian=B9s comments. https://github.com/cdh4u/draft-sctp-sdp/pull/10 Regards, Christer On 05/02/17 21:05, "Brian E Carpenter" wrote: >Hi Christer, >On 06/02/2017 03:14, Christer Holmberg wrote: >> Hi Brian, >>=20 >> Thanks for your review! Please see inline. >>=20 >> ... >>=20 >> Comments: >> --------- >>=20 >>> Two points I noted in the writeup: >>> "There are existing implementations of earlier versions of the >>>document..." >>> >>> Excellent, but I wonder why we don't see Implementation Status >>>sections under RFC 6982 in more Last Call drafts. >>=20 >> Perhaps a topic for an IETF chairs lunch presentation? > >Or at least a short reminder! > >>=20 >> I have to admit that I did not know about 6982 (now obsoleted by 7942). >>My suggestion would to not collect that information for this draft at >>this point of time, as it could take some time. > >Agreed. > >>> "IPv6 address examples are not necessary since IP version differences >>>are immaterial to the purpose of the specification." >>> >>> It's just as easy to give an IPv6 example though, and more future >>>proof. >>=20 >> I can modify the address in the example, from IPv4 to v6. > >As you wish. > >> Minor issue: (almost a nit) >> ------------ >>=20 >> 1. Introduction >> ... >>>> NOTE: Due to the characteristics of TCP, usage of 'TCP/DTLS/SCTP' >>>> will always force ordered and reliable delivery of the SCTP >>>> packets, which limits the usage of the SCTP options. Therefore, it >>>>is >>>> RECOMMENDED that TCP is only used in situations where UDP traffic >>>> is blocked. >>> >>> Why would one choose 'TCP/DTLS/SCTP' rather than just 'TCP/TLS'? I >>>don't object to it being specified, but since you >>> don't support multihoming or multiple associations, what is the use >>>case, in a few words? >>=20 >> SCTP supports multiple SCTP streams over a single association, and you >>can still use that with 'TCP/DTLS/SCTP'. E.g, the WebRTC Data Channel >>protocol uses two streams to realize a data channel. > >OK. > >(I now remember that I raised essentially the same question when reviewing >draft-ietf-clue-datachannel. Actually I'm glad to see SCTP proving >useful.) > >> I could modify the first sentence as following: >>=20 >> "NOTE: Due to the characteristics of TCP, while multiple SCTP >>streams >> can still be used, usage of 'TCP/DTLS/SCTP' will always >>force...." > >OK > >>=20 >> Nits: >> ----- >>=20 >>>> 4.4.2. SDP Media Description values >>>> >>>> m=3D line parameter parameter value(s) >>>> =20 >>>> ------------------------------------------------------------------ >>>> : "application" >>>> : "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP" >>>> : UDP port number (for "UDP/DTLS/SCTP") >>>> TCP port number (for ""UDP/DTLS/SCTP") >>> >>> I think the last line should be: TCP port number (for "TCP/DTLS/SCTP") >>=20 >> Correct. Will be fixed. >>=20 >>> There is some inconsistency in the use of quotation marks: >>>"UDP/DTLS/SCTP" or 'UDP/DTLS/SCTP' >>=20 >> I'll fix that. I will use single quotes. > >Thanks, > Brian From nobody Mon Feb 6 04:49:01 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CED1129D3A for ; Mon, 6 Feb 2017 04:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7FH7K1YE7Fdc for ; Mon, 6 Feb 2017 04:48:58 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C47D129D4F for ; Mon, 6 Feb 2017 04:48:57 -0800 (PST) X-AuditID: c1b4fb25-5ba3c980000036c9-63-589870b85782 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 77.0C.14025.8B078985; Mon, 6 Feb 2017 13:48:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0319.002; Mon, 6 Feb 2017 13:48:33 +0100 From: Christer Holmberg To: Eric Rescorla , mmusic WG Thread-Topic: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux Thread-Index: AQHSfkR3UhfsVBhEwUWv5/2Z0yKCVaFXfBcAgASHPoA= Date: Mon, 6 Feb 2017 12:48:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D4BE3D3217805christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2K7me6OghkRBtP6BCxWvD7HbjF1+WMW ByaPJUt+MnlMftzGHMAUxWWTkpqTWZZapG+XwJVx/+MxloJXmhXHpjWxNzD+Vupi5OSQEDCR WPDpAXMXIxeHkMA6RomLc3ayQjiLGCWezNrO1MXIwcEmYCHR/U8bpEFEwFaip/cII4gtLGAj ce/Ea1aY+NPth5lBykUErCTWzhQACbMIqEjsbvrCDGLzClhLvDt+D2rXdEaJvrYTLCAJToFA ibkvJoPNZBQQk/h+ag0TiM0sIC5x68l8JohDBSSW7DnPDGGLSrx8/A9sr6iAnsTy52ug4ooS V6cvh+pNkHjfc58JYrGgxMmZT1gmMIrMQjJ2FpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznw GKrXWqK/7zsjspoFjByrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQLj7eCW36o7GC+/cTzE KMDBqMTD+8F2eoQQa2JZcWXuIUYJDmYlEV6h3BkRQrwpiZVVqUX58UWlOanFhxilOViUxHnN Vt4PFxJITyxJzU5NLUgtgskycXBKNTBOOv1M/FuGhqJG88zQN4q3dkmwH1fPc9zG9bgjZQ6v 4J4EjZ6lR+J1cudITHGVCYmW/Pir9dOcgN4jeo8X/7IrdN619qrMbLuTyhu+8RuruZ9YXcrl tqjkr0lWxKml+x+u47651fS/+96FW2oabi6J/TNj65/be9nm2W2rqFB9t55B6SD7Fq6/SizF GYmGWsxFxYkAm0qiYLMCAAA= Archived-At: Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 12:48:59 -0000 --_000_D4BE3D3217805christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >Following up to myself, I don't think it's sensible for answers to contain= a=3Drtcp-mux-only, because either you accepted mux, in which case all is g= ood, or you rejected it, in which case it was rejected. While I agree that a=3Drtcp-mux would be enough in the Answer as far as ind= icating mux is concerned, including a=3Drtcp-mux-only in the Answer does in= dicate that the Answerer supports the mux-exclusive mechanism. Regards, Christer On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla > wrote: I have been reading the mux-exclusive document and I'm not sure it says quite what we want. Specifically, S 4.2 says: When an offerer sends the initial offer, if the offerer wants to indicate exclusive RTP/RTCP multiplexing for RTP-based media, the offerer MUST associate an SDP 'rtcp-mux-only' attribute with the associated SDP media description ("m=3D" line). In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=3D" line), the offerer MAY also associate an SDP 'rtcp-mux' attribute with the same SDP media description ("m=3D" line), following the procedures in [RFC5761]. As I understand this text, the offerer may say the following things: 1. No a=3Drtcp-mux: No muxing. 2. a=3Drtcp-mux: I am offering RTCP mux 3. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux 4. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3). I don't think the last of these is sensible. No current implementation will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will result in interop failures. Thus the MAY in the second graf needs to be a MUST. -Ekr --_000_D4BE3D3217805christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

>Following up to myself, I don't think it's sensible fo= r answers to contain a=3Drtcp-mux-only, because either you accepted mux, in= which case all is good, or you rejected it, in which case it was rejected.

While I agree that a=3Drtcp-mux would be enough in the Answer as far a= s indicating mux is concerned, including a=3Drtcp-mux-only in the Answer do= es indicate that the Answerer supports the mux-exclusive mechanism.

Regards,

Christer



On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla <ekr@rtfm.com><= /span> wrote:
I have been reading the mux-exclusive document and I'm not sure it say= s
quite what we want. Specifically, S 4.2 says:

   When an offerer sends the initial offer, if the offerer w= ants to
   indicate exclusive RTP/RTCP multiplexing for RTP-based me= dia, the
   offerer MUST associate an SDP 'rtcp-mux-only' attribute w= ith the
   associated SDP media description ("m=3D" line).=

   In addition, if the offerer associates an SDP 'rtcp-mux-o= nly'
   attribute with an SDP media description ("m=3D"= line), the offerer MAY
   also associate an SDP 'rtcp-mux' attribute with the same = SDP media
   description ("m=3D" line), following the proced= ures in [RFC5761].

As I understand this text, the offerer may say the following things:

 1. No a=3Drtcp-mux: No muxing.
 2. a=3Drtcp-mux: I am offering RTCP mux
 3. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux=
 4. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3).

I don't think the last of these is sensible. No current implementation=
will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this = will
result in interop failures. Thus the MAY in the second graf needs to b= e
a MUST.

-Ekr


 --_000_D4BE3D3217805christerholmbergericssoncom_-- From nobody Mon Feb 6 05:08:24 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B2D1294C3 for ; Mon, 6 Feb 2017 05:08:22 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-sw6sspf6ra for ; Mon, 6 Feb 2017 05:08:21 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6FC31293E0 for ; Mon, 6 Feb 2017 05:08:21 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id u68so48183147ywg.0 for ; Mon, 06 Feb 2017 05:08:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z8WehyGhId4FVFI23ValbN52vTXZd0CSCumTCE3eNBE=; b=a5MuiKnG5/ImeDjg0bKcztJYcpzY7D4/j2uMZpTGx5z+/jPQ+7eo5iUKQYOIKvXi/y ZHGzwpBbSg+0l49fDv0tz/PyavB2/4fYS0FjCHH5hn/Afc6+Zts9OWH0L5T63E+lZinq 8O1pTDXlHQ1NILk6BfpO9RnsgEdyromE63FoNRSNUfbPWX5HIs9VOU1gMLxkFGvoAcw5 IO5scJLO7NgI2P67tFrIVv0k0svZb3LRqmSUe3pVj/qo908ZPjFQ4um0soE/ZcZQdONg olvr8xh3FfsMRpfXTzUE/t3jC1jf2Vs8jib3In0zgU1wtbnB4xIdWaHKzd3kOnFOSd/i YBMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z8WehyGhId4FVFI23ValbN52vTXZd0CSCumTCE3eNBE=; b=MRzFzLh2LvzWyvsrBeaTJApXRydG60VQBUa3Uf1pHP2r9VF6HJV3ZYBhFibPGRyYLo grNToGtVNcXmH/bcvew2ELU9A5QnEpbPiw/mWZz4sQJxQf1tBY7M3H5I875u4Mr8LEUD bKUFNy2pC7aaFBzVfqnvllTag6sN0aCuyxs5225U9HaFa852/TJw/Yi6/RtONGOKZf9E FSnE59vZiJu+42PTsYyA2JtC/yJv9D+XZqzUfRRYH7piNeuaBNSQFvvwm1eTk8RtXn4W uNmWKPbiKG3Bo0Xp6uETvsdME0Ha5Y28FrhRkJVMZ8U3B+imjlEE9PQ4BosARf4y1wSm eRKA== X-Gm-Message-State: AIkVDXK/sJQiKRPkXSvpRJWuj1KRJaYsUYz49FCW2SR51JSyhV/PNLYlX1EvrS5y3hEG/T4oITfxoNpEbCduFw== X-Received: by 10.129.108.131 with SMTP id h125mr6743082ywc.71.1486386500904; Mon, 06 Feb 2017 05:08:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Mon, 6 Feb 2017 05:07:40 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 6 Feb 2017 05:07:40 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114dcf7862daa80547dc53db Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 13:08:22 -0000 --001a114dcf7862daa80547dc53db Content-Type: text/plain; charset=UTF-8 On Mon, Feb 6, 2017 at 4:48 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >Following up to myself, I don't think it's sensible for answers to > contain a=rtcp-mux-only, because either you accepted mux, in which case all > is good, or you rejected it, in which case it was rejected. > > While I agree that a=rtcp-mux would be enough in the Answer as far as > indicating mux is concerned, including a=rtcp-mux-only in the Answer does > indicate that the Answerer supports the mux-exclusive mechanism. > I don't see how that's really that useful -Ekr > > Regards, > > Christer > > > > On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla wrote: > >> I have been reading the mux-exclusive document and I'm not sure it says >> quite what we want. Specifically, S 4.2 says: >> >> When an offerer sends the initial offer, if the offerer wants to >> indicate exclusive RTP/RTCP multiplexing for RTP-based media, the >> offerer MUST associate an SDP 'rtcp-mux-only' attribute with the >> associated SDP media description ("m=" line). >> >> In addition, if the offerer associates an SDP 'rtcp-mux-only' >> attribute with an SDP media description ("m=" line), the offerer MAY >> also associate an SDP 'rtcp-mux' attribute with the same SDP media >> description ("m=" line), following the procedures in [RFC5761]. >> >> As I understand this text, the offerer may say the following things: >> >> 1. No a=rtcp-mux: No muxing. >> 2. a=rtcp-mux: I am offering RTCP mux >> 3. a=rtcp-mux-only + a=rtcp-mux: I will only do RTCP mux >> 4. a=rtcp-mux-only: I will only do RTCP mux (same as #3). >> >> I don't think the last of these is sensible. No current implementation >> will know what to do with a=rtcp-mux-only w/o a=rtcp-mux, so this will >> result in interop failures. Thus the MAY in the second graf needs to be >> a MUST. >> >> -Ekr >> >> > --001a114dcf7862daa80547dc53db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 6, 2017 at 4:48 AM, Christer Holmberg <= ;christ= er.holmberg@ericsson.com> wrote:
Hi,

>Following up to myself, I don't think it's sen= sible for answers to contain a=3Drtcp-mux-only, because either you accepted= mux, in which case all is good, or you rejected it, in which case it was r= ejected.

While I agree that a=3Drtcp-mux would be enough in the Answer a= s far as indicating mux is concerned, including a=3Drtcp-mux-only in the An= swer does indicate that the Answerer supports the mux-exclusive mechanism.<= /div>

I don't see how that's = really that useful

-Ekr
=C2=A0

Regards,

Christer



On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla <ekr@rtfm.com><= /span> wrote:
I have been reading the mux-exclusive document and I'm not sure it= says
quite what we want. Specifically, S 4.2 says:

=C2=A0 =C2=A0When an offerer sends the initial offer, if the offerer w= ants to
=C2=A0 =C2=A0indicate exclusive RTP/RTCP multiplexing for RTP-based me= dia, the
=C2=A0 =C2=A0offerer MUST associate an SDP 'rtcp-mux-only' att= ribute with the
=C2=A0 =C2=A0associated SDP media description ("m=3D" line).=

=C2=A0 =C2=A0In addition, if the offerer associates an SDP 'rtcp-m= ux-only'
=C2=A0 =C2=A0attribute with an SDP media description ("m=3D"= line), the offerer MAY
=C2=A0 =C2=A0also associate an SDP 'rtcp-mux' attribute with t= he same SDP media
=C2=A0 =C2=A0description ("m=3D" line), following the proced= ures in [RFC5761].

As I understand this text, the offerer may say the following things:

=C2=A01. No a=3Drtcp-mux: No muxing.
=C2=A02. a=3Drtcp-mux: I am offering RTCP mux
=C2=A03. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux
=C2=A04. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3).

I don't think the last of these is sensible. No current implementa= tion
will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this = will
result in interop failures. Thus the MAY in the second graf needs to b= e
a MUST.

-Ekr

--001a114dcf7862daa80547dc53db-- From nobody Mon Feb 6 05:58:07 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70226129D91 for ; Mon, 6 Feb 2017 05:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 K-VGgc0d_7za for ; Mon, 6 Feb 2017 05:58:02 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A1B129D94 for ; Mon, 6 Feb 2017 05:58:01 -0800 (PST) X-AuditID: c1b4fb25-1dfff700000036c9-2c-589880e631b4 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id DF.7C.14025.6E088985; Mon, 6 Feb 2017 14:58:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0319.002; Mon, 6 Feb 2017 14:57:58 +0100 From: Christer Holmberg To: Eric Rescorla Thread-Topic: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux Thread-Index: AQHSfkR3UhfsVBhEwUWv5/2Z0yKCVaFXfBcAgASHPoD//+NbAIAAMCIA Date: Mon, 6 Feb 2017 13:57:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <995440EC0271AB4387921401757F0EA5@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2J7iO6LhhkRBnMOKFiseH2O3WLq8scs DkweS5b8ZPKY/LiNOYApissmJTUnsyy1SN8ugSujpbORqWAnX8WDWduZGxgXcXcxcnBICJhI fP9v3cXIySEksI5R4uJCAQh7EaPEr+eKICVsAhYS3f+0QcIiAgoSv/6cYAGxmQXkJS4sWcME YgsL2EjcO/GaFaLGVuLp9sPMELabxNbO3ywgY1gEVCTm/TAHCfMKWEt8/TyJrYuRC2jTBCaJ kzcesYEkOAUCJeZeWAFmMwqISXw/BTGfWUBc4taT+WC2hICAxJI955khbFGJl4//ge0VFdCT WP58DVRcUeLjq32MEL06Egt2f2IDuYEZaPGNuSkQYW2JZQtfM0PcIyhxcuYTlgmM4rOQbJuF pHsWQvcsJN2zkHQvYGRdxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYZQe3/FbdwXj5jeMh RgEORiUe3g+20yOEWBPLiitzDzFKcDArifAKVM+IEOJNSaysSi3Kjy8qzUktPsQozcGiJM5r tvJ+uJBAemJJanZqakFqEUyWiYNTqoGx8YCxTL++bTXbwX1lj+2PNDc/8/33VWFZutlOP4+6 20cjipU9bh1iqljC/MUwh+1Py7r1GkmrbuzIXOD1N4ZnzV+pxl6rl+r2d/Ly95VUs790PT79 +hKzCKtnv5ZeezeRQSeQzaZ7ZhiPp4Rq/dLVzyW7Ys+/VDB7s+y4sSwvb9zBytYV04OUWIoz Eg21mIuKEwHezUOurgIAAA== Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 13:58:04 -0000 Hi, >>> Following up to myself, I don't think it's sensible for answers to >>>contain a=3Drtcp-mux-only, because either you accepted mux, in which cas= e >>>all is good, or you rejected it, in which case it was rejected. >> >> While I agree that a=3Drtcp-mux would be enough in the Answer as far as >>indicating mux is concerned, including a=3Drtcp-mux-only in the Answer >>does indicate that the Answerer supports the mux-exclusive mechanism. > > I don't see how that's really that useful But what harm does it cause? Regards, Christer On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla wrote: I have been reading the mux-exclusive document and I'm not sure it says quite what we want. Specifically, S 4.2 says: When an offerer sends the initial offer, if the offerer wants to indicate exclusive RTP/RTCP multiplexing for RTP-based media, the offerer MUST associate an SDP 'rtcp-mux-only' attribute with the associated SDP media description ("m=3D" line). In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=3D" line), the offerer MAY also associate an SDP 'rtcp-mux' attribute with the same SDP media description ("m=3D" line), following the procedures in [RFC5761]. As I understand this text, the offerer may say the following things: 1. No a=3Drtcp-mux: No muxing. 2. a=3Drtcp-mux: I am offering RTCP mux 3. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux 4. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3). I don't think the last of these is sensible. No current implementation will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will result in interop failures. Thus the MAY in the second graf needs to be a MUST. -Ekr From nobody Mon Feb 6 06:33:26 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D238D129DDC for ; Mon, 6 Feb 2017 06:33:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAQRWNVXdtWP for ; Mon, 6 Feb 2017 06:33:24 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A828129DDD for ; Mon, 6 Feb 2017 06:33:24 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id v200so49333781ywc.3 for ; Mon, 06 Feb 2017 06:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sawjZ4oserXND/ncp65N8cdwCtefGUkyqYGIyxMmje8=; b=fGVCj1dVdC5dy1Ax4MWhRXhG2I/0jMhfhWJlVIOCXK16QjQ+ANVHfI5xIR1Tua1IXF Fqt3A21MKrc+ouhPq48MWeiFxrQTtItLfuFMh7fDuDWsvOwSRAbdyBmGtgk9pISohnAg CTkWZ4bHRaIIIFek2Th47TPYkUjhrz5QD9DSpQ+G9Q1QnQhJwUFHF9vgMJ5h0sOIIEFm f4fyRGLQ1oSsNv34WoWv4G+uK7Hh1abCuNh7agXf2eQplNaDGLGTvFsUVyE+J9uKPVEO OBqXn8rIQNwuRcomcUsxXRopgSvBl6Y5AIfVj4NcQCKBVD42LNMkKLMWXuUWqWPN4j+H wCDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sawjZ4oserXND/ncp65N8cdwCtefGUkyqYGIyxMmje8=; b=Dw4CgRHKYWsNZU+HkGFzTFLIfluwMbi23sBSG0wbpG4mqU+O0fPuVwFU8A3ftMGIzi RH/RFxqsgHRae7uvr5izHxruF6klLWCWUg1bTiwZVDylUaoWWeIzco3MKLnvGkJA/PsE sMBp0D1YALB5ROnUj2rS/OMDCIbESPL+hXVq0XCxNt2rlNaQ6Y9dD7018w/nV+dOwzGl G5Fd9RQauTIQpKI1QvO2h0EMdOFj/PUTAU+CqrJYtn5GHHYEWuuJUFhOYoomFxr6KgDt oqzv/+CdIOfMBkEMPKOQnbGCUHy6kXMVFcWaT13Xiu1I8YKUnxgHdvaLLS0hMg+TAkX+ iv3w== X-Gm-Message-State: AMke39ny0/eGbte6Cgm/Ul15ngijFBGWDVL7faDBa7AGJLj0/ZbXZ8X8aJ/z9qipNLqyOOQQapTBhebOkEHm1w== X-Received: by 10.129.162.130 with SMTP id z124mr7951581ywg.276.1486391603585; Mon, 06 Feb 2017 06:33:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Mon, 6 Feb 2017 06:32:43 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 6 Feb 2017 06:32:43 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c12929287a2320547dd8364 Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 14:33:26 -0000 --94eb2c12929287a2320547dd8364 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>> Following up to myself, I don't think it's sensible for answers to > >>>contain a=rtcp-mux-only, because either you accepted mux, in which case > >>>all is good, or you rejected it, in which case it was rejected. > >> > >> While I agree that a=rtcp-mux would be enough in the Answer as far as > >>indicating mux is concerned, including a=rtcp-mux-only in the Answer > >>does indicate that the Answerer supports the mux-exclusive mechanism. > > > > I don't see how that's really that useful > > But what harm does it cause? > I don't think that's the standard here. We should only send indicators in SDP when they do something useful. -Ekr > Regards, > > Christer > > > > > On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla > wrote: > > I have been reading the mux-exclusive document and I'm not sure it says > quite what we want. Specifically, S 4.2 says: > > When an offerer sends the initial offer, if the offerer wants to > indicate exclusive RTP/RTCP multiplexing for RTP-based media, the > offerer MUST associate an SDP 'rtcp-mux-only' attribute with the > associated SDP media description ("m=" line). > > In addition, if the offerer associates an SDP 'rtcp-mux-only' > attribute with an SDP media description ("m=" line), the offerer MAY > also associate an SDP 'rtcp-mux' attribute with the same SDP media > description ("m=" line), following the procedures in [RFC5761]. > > As I understand this text, the offerer may say the following things: > > 1. No a=rtcp-mux: No muxing. > 2. a=rtcp-mux: I am offering RTCP mux > 3. a=rtcp-mux-only + a=rtcp-mux: I will only do RTCP mux > 4. a=rtcp-mux-only: I will only do RTCP mux (same as #3). > > I don't think the last of these is sensible. No current implementation > will know what to do with a=rtcp-mux-only w/o a=rtcp-mux, so this will > result in interop failures. Thus the MAY in the second graf needs to be > a MUST. > > -Ekr > > > > > > > > > > > > > > > > --94eb2c12929287a2320547dd8364 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg <= ;christ= er.holmberg@ericsson.com> wrote:
Hi,

>>> Following up to myself, I don't think it's sensible fo= r answers to
>>>contain a=3Drtcp-mux-only, because either you accepted mux, in = which case
>>>all is good, or you rejected it, in which case it was rejected.=
>>
>> While I agree that a=3Drtcp-mux would be enough in the Answer as f= ar as
>>indicating mux is concerned, including a=3Drtcp-mux-only in the Ans= wer
>>does indicate that the Answerer supports the mux-exclusive mechanis= m.
>
> I don't see how that's really that useful

But what harm does it cause?

I d= on't think that's the standard here. We should only send indicators= in SDP when they
do something useful.

-= Ekr


Regards,

Christer




On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla
<ekr@rtfm.com> wrote:

I have been reading the mux-exclusive document and I'm not sure it says=
quite what we want. Specifically, S 4.2 says:

=C2=A0 =C2=A0When an offerer sends the initial offer, if the offerer wants = to
=C2=A0 =C2=A0indicate exclusive RTP/RTCP multiplexing for RTP-based media, = the
=C2=A0 =C2=A0offerer MUST associate an SDP 'rtcp-mux-only' attribut= e with the
=C2=A0 =C2=A0associated SDP media description ("m=3D" line).

=C2=A0 =C2=A0In addition, if the offerer associates an SDP 'rtcp-mux-on= ly'
=C2=A0 =C2=A0attribute with an SDP media description ("m=3D" line= ), the offerer MAY
=C2=A0 =C2=A0also associate an SDP 'rtcp-mux' attribute with the sa= me SDP media
=C2=A0 =C2=A0description ("m=3D" line), following the procedures = in [RFC5761].

As I understand this text, the offerer may say the following things:

=C2=A01. No a=3Drtcp-mux: No muxing.
=C2=A02. a=3Drtcp-mux: I am offering RTCP mux
=C2=A03. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux
=C2=A04. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3).

I don't think the last of these is sensible. No current implementation<= br> will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will<= br> result in interop failures. Thus the MAY in the second graf needs to be
a MUST.

-Ekr
















--94eb2c12929287a2320547dd8364-- From nobody Mon Feb 6 09:01:57 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C09E5128AB0; Mon, 6 Feb 2017 09:01:55 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148640051578.18861.16064034898103189942.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2017 09:01:55 -0800 Archived-At: Cc: ben@nostrum.com, mmusic@ietf.org, mmusic-chairs@ietf.org, Flemming Andreasen , The IESG , draft-ietf-mmusic-4572-update@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] Protocol Action: 'Connection-Oriented Media Transport over TLS in SDP' to Proposed Standard (draft-ietf-mmusic-4572-update-13.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 17:01:56 -0000 The IESG has approved the following document: - 'Connection-Oriented Media Transport over TLS in SDP' (draft-ietf-mmusic-4572-update-13.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ Technical Summary The document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document obsoletes RFC 4572 but remains backwards compatible with older implementations. The changes from RFC 4572 are that it clarifies that multiple 'fingerprint' attributes can be used to carry fingerprints, calculated using different hash functions, associated with a given certificate, and to carry fingerprints associated with multiple certificates. The fingerprint matching procedure, when multiple fingerprints are provided, are also clarified. The document also updates the preferred cipher suite with a stronger cipher suite, and removes the requirement to use the same hash function for calculating a certificate fingerprint and certificate signature. Working Group Summary The document was adopted as a WG document in April 2016 and hence has progressed fairly quickly. WG adoption was based on strong consensus and a clear need; the document has subsequently seen good WG discussion. The document started out as an update to RFC 4572, but was more recently changed to obsolete RFC 4572 after some concerns were raised. The resulting document has solid consensus in the WG. Document Quality There are various implementations of the existing RFC 4572. The new specification is needed for RTCWeb and hence several vendors are expected to implement it. There were many individuals providing valuable input, however Martin Thomson and Roman Shpount in particular deserve special mention. Personnel Flemming Andreasen is the Document Shepherd and Ben Campbell is the Responsible AD. From nobody Tue Feb 7 00:55:58 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BE3128E18 for ; Tue, 7 Feb 2017 00:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ClRglMBntDm6 for ; Tue, 7 Feb 2017 00:55:52 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0862A12949F for ; Tue, 7 Feb 2017 00:55:51 -0800 (PST) X-AuditID: c1b4fb30-b99fe70000007389-26-58998b953314 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 34.69.29577.59B89985; Tue, 7 Feb 2017 09:55:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Tue, 7 Feb 2017 09:55:49 +0100 From: Christer Holmberg To: Eric Rescorla Thread-Topic: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux Thread-Index: AQHSfkR3UhfsVBhEwUWv5/2Z0yKCVaFXfBcAgASHPoD//+NbAIAAMCIA///nooCAAVZKgA== Date: Tue, 7 Feb 2017 08:55:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D4BF5838178E0christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2K7k+607pkRBlvu8liseH2O3WLq8scs DkweS5b8ZPKY/LiNOYApissmJTUnsyy1SN8ugSvj++sjjAVNDhX/jq1mbWC8YNrFyMkhIWAi 0fGgl7GLkYtDSGAdo8Tae9+hnEWMEpe6L7F1MXJwsAlYSHT/0wZpEBFQkPj15wQLiM0sIC9x YckaJhBbWMBG4t6J16wQNbYST7cfZgZpFREIkzg7PxMkzCKgIrFw9WZGEJtXwFrixt+VUKs6 mSUm9jQzgtRzCgRKTLqYDVLDKCAm8f0UxHhmAXGJW0/mM0HcLCCxZM95ZghbVOLl439ga0UF 9CSWP18DFVeUaH/awAjRmyDxYcMNdoi9ghInZz5hmcAoOgvJ2FlIymYhKYOI60gs2P2JDcLW lli28DUzjH3mwGOoXmuJV7evMCOrWcDIsYpRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMAoP bvltsIPx5XPHQ4wCHIxKPLwF/TMihFgTy4orcw8xSnAwK4nwGrbPjBDiTUmsrEotyo8vKs1J LT7EKM3BoiTOa7byfriQQHpiSWp2ampBahFMlomDU6qBMWRVC7epq1c6i5vrH+FtivOrj/31 1iquvpfgGv5/kaS7w2n3Oy4vNvUX3ft4lyH//rczWWp25b8LFK8LFJYxzGBammQxyVnU8WTV XLvlpZd33Ra0W2WmqjjN83+oSpYPb3u7j/oht7iGHfPW57FXBe2/seul7iZtjTtZSy46bbks nVPzwbNSiaU4I9FQi7moOBEAsPo9O74CAAA= Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 08:55:57 -0000 --_000_D4BF5838178E0christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We had a long discussion about this, with many different opinions, and it w= ould take some time to go through the archive and check everything. But, on= e opinion was that it IS useful to send the attribute, as it indicates supp= ort of the mechanism. Regards, Christer From: Eric Rescorla > Date: Monday 6 February 2017 at 16:32 To: Christer Holmberg > Cc: "mmusic@ietf.org" > Subject: Re: [MMUSIC] Sending a=3Drtcp-mux-only w/o a=3Drtcp-mux On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg > wrote: Hi, >>> Following up to myself, I don't think it's sensible for answers to >>>contain a=3Drtcp-mux-only, because either you accepted mux, in which cas= e >>>all is good, or you rejected it, in which case it was rejected. >> >> While I agree that a=3Drtcp-mux would be enough in the Answer as far as >>indicating mux is concerned, including a=3Drtcp-mux-only in the Answer >>does indicate that the Answerer supports the mux-exclusive mechanism. > > I don't see how that's really that useful But what harm does it cause? I don't think that's the standard here. We should only send indicators in S= DP when they do something useful. -Ekr Regards, Christer On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla > wrote: I have been reading the mux-exclusive document and I'm not sure it says quite what we want. Specifically, S 4.2 says: When an offerer sends the initial offer, if the offerer wants to indicate exclusive RTP/RTCP multiplexing for RTP-based media, the offerer MUST associate an SDP 'rtcp-mux-only' attribute with the associated SDP media description ("m=3D" line). In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=3D" line), the offerer MAY also associate an SDP 'rtcp-mux' attribute with the same SDP media description ("m=3D" line), following the procedures in [RFC5761]. As I understand this text, the offerer may say the following things: 1. No a=3Drtcp-mux: No muxing. 2. a=3Drtcp-mux: I am offering RTCP mux 3. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux 4. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3). I don't think the last of these is sensible. No current implementation will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will result in interop failures. Thus the MAY in the second graf needs to be a MUST. -Ekr --_000_D4BF5838178E0christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

We had a long discussion about this, with many different opinions, and= it would take some time to go through the archive and check everything. Bu= t, one opinion was that it IS useful to send the attribute, as it indicates= support of the mechanism.

Regards,

Christer

From: Eric Rescorla <ekr@rtfm.com>
Date: Monday 6 February 2017 at 16:= 32
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: Re: [MMUSIC] Sending a=3Dr= tcp-mux-only w/o a=3Drtcp-mux



On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmber= g <chr= ister.holmberg@ericsson.com> wrote:
Hi,

>>> Following up to myself, I don't think it's sensible for answer= s to
>>>contain a=3Drtcp-mux-only, because either you accepted mux, in = which case
>>>all is good, or you rejected it, in which case it was rejected.=
>>
>> While I agree that a=3Drtcp-mux would be enough in the Answer as f= ar as
>>indicating mux is concerned, including a=3Drtcp-mux-only in the Ans= wer
>>does indicate that the Answerer supports the mux-exclusive mechanis= m.
>
> I don't see how that's really that useful

But what harm does it cause?

I don't think that's the standard here. We should only send indicators= in SDP when they
do something useful.

-Ekr


Regards,

Christer




On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla
<ekr@rtfm.com> wrote:

I have been reading the mux-exclusive document and I'm not sure it says
quite what we want. Specifically, S 4.2 says:

   When an offerer sends the initial offer, if the offerer wants = to
   indicate exclusive RTP/RTCP multiplexing for RTP-based media, = the
   offerer MUST associate an SDP 'rtcp-mux-only' attribute with t= he
   associated SDP media description ("m=3D" line).

   In addition, if the offerer associates an SDP 'rtcp-mux-only'<= br>    attribute with an SDP media description ("m=3D" line= ), the offerer MAY
   also associate an SDP 'rtcp-mux' attribute with the same SDP m= edia
   description ("m=3D" line), following the procedures = in [RFC5761].

As I understand this text, the offerer may say the following things:

 1. No a=3Drtcp-mux: No muxing.
 2. a=3Drtcp-mux: I am offering RTCP mux
 3. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux
 4. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3).

I don't think the last of these is sensible. No current implementation
will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will<= br> result in interop failures. Thus the MAY in the second graf needs to be
a MUST.

-Ekr
















 --_000_D4BF5838178E0christerholmbergericssoncom_-- From nobody Tue Feb 7 04:23:49 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6AC129B91 for ; Tue, 7 Feb 2017 04:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FSDA7iQRJzQ for ; Tue, 7 Feb 2017 04:23:46 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66DA9129B92 for ; Tue, 7 Feb 2017 04:23:46 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id u68so65772262ywg.0 for ; Tue, 07 Feb 2017 04:23:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nY/r1zBxuSsvoXpEu9wPlzMfIhgyAZwlm1whiknknxo=; b=YIMVbNCl6q7PERiZchHSOgliHvf5xMmzk8CS1ZyI4ZhiEF3bGzOndrTYrO9rDWl4ve L3vSZSXIcwoTa5p6bUg7YL7R81Jt9DdZIhmAXoAR5kwYGpc7pX6RLXq1FLh8hivkp0Ih NpuI3EjqNUAc9+oJwIX2a9XXuNnbO5UDny/IFJz/Yhpxb+UAg1yzWyq1Drp1YXTNJs60 b1itFJSA3JQ4K6nGKLmaviPx0uF7PjAHvoNqU9fpmx3Wb717mLR4TBX9PiliWlxJlKnu pROKJqnvXfjk6q57KJrbikOtoht7WQbuA5r3XTZSK+s9YS3T5p91Q4LJZJYV47Iy77al r5rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nY/r1zBxuSsvoXpEu9wPlzMfIhgyAZwlm1whiknknxo=; b=j9NO1CEKUspO7qgoJ9UL720Vsz0wWX5WWlxeeKigrIRw8f8cjP579vorCrMQp8NYBE X5p1UR3xfcCGnlyuLwUUuhR7/BvVQfiRTY7JZ9d0FnBNahuBmlOGDSG8rpfVdzCGGdvR +e4Yry+gvsW+fa3xXz4IgM/ZOUE75CrH8mLfNPR/MPF2va3sKZ6LOFbksSYJbGYslrY6 KM+5LUgGd988ufpJJTX3FMm7bYZsM56ibiwj6LK3tCraE2VQpdquUeb1JclCI1UnuLrf m+gKBQrylq5adbS0zEUereCKdwiu49CYEKKoDwh/OmqwfNzRtfuM3a+x9PkvTaUAMVRf B47g== X-Gm-Message-State: AMke39mtAiVW5Alvv6hDHeBJPdthyX51LtUKCw78A5X0anO06DxIWZobc7+dBS+oroM7Nj2Go1ZyKyqcExiazQ== X-Received: by 10.129.162.151 with SMTP id z145mr10612221ywg.337.1486470225659; Tue, 07 Feb 2017 04:23:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Tue, 7 Feb 2017 04:23:05 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 7 Feb 2017 04:23:05 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c11555ec537830547efd1ed Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 12:23:49 -0000 --94eb2c11555ec537830547efd1ed Content-Type: text/plain; charset=UTF-8 On Tue, Feb 7, 2017 at 12:55 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > We had a long discussion about this, with many different opinions, and it > would take some time to go through the archive and check everything. But, > one opinion was that it IS useful to send the attribute, as it indicates > support of the mechanism. > What does the other side do with that? Is there any precedent for this in SDP? -Ekr > > Regards, > > Christer > > From: Eric Rescorla > Date: Monday 6 February 2017 at 16:32 > To: Christer Holmberg > Cc: "mmusic@ietf.org" > Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux > > > > On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >>> Following up to myself, I don't think it's sensible for answers to >> >>>contain a=rtcp-mux-only, because either you accepted mux, in which case >> >>>all is good, or you rejected it, in which case it was rejected. >> >> >> >> While I agree that a=rtcp-mux would be enough in the Answer as far as >> >>indicating mux is concerned, including a=rtcp-mux-only in the Answer >> >>does indicate that the Answerer supports the mux-exclusive mechanism. >> > >> > I don't see how that's really that useful >> >> But what harm does it cause? >> > > I don't think that's the standard here. We should only send indicators in > SDP when they > do something useful. > > -Ekr > > >> Regards, >> >> Christer >> >> >> >> >> On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla >> wrote: >> >> I have been reading the mux-exclusive document and I'm not sure it says >> quite what we want. Specifically, S 4.2 says: >> >> When an offerer sends the initial offer, if the offerer wants to >> indicate exclusive RTP/RTCP multiplexing for RTP-based media, the >> offerer MUST associate an SDP 'rtcp-mux-only' attribute with the >> associated SDP media description ("m=" line). >> >> In addition, if the offerer associates an SDP 'rtcp-mux-only' >> attribute with an SDP media description ("m=" line), the offerer MAY >> also associate an SDP 'rtcp-mux' attribute with the same SDP media >> description ("m=" line), following the procedures in [RFC5761]. >> >> As I understand this text, the offerer may say the following things: >> >> 1. No a=rtcp-mux: No muxing. >> 2. a=rtcp-mux: I am offering RTCP mux >> 3. a=rtcp-mux-only + a=rtcp-mux: I will only do RTCP mux >> 4. a=rtcp-mux-only: I will only do RTCP mux (same as #3). >> >> I don't think the last of these is sensible. No current implementation >> will know what to do with a=rtcp-mux-only w/o a=rtcp-mux, so this will >> result in interop failures. Thus the MAY in the second graf needs to be >> a MUST. >> >> -Ekr >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > --94eb2c11555ec537830547efd1ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 7, 2017 at 12:55 AM, Christer Holmberg <christer.holm= berg@ericsson.com> wrote:
Hi,

We had a long discussion about this, with many different opinions, and= it would take some time to go through the archive and check everything. Bu= t, one opinion was that it IS useful to send the attribute, as it indicates= support of the mechanism.

What= does the other side do with that? Is there any precedent for this in SDP?<= /div>

-Ekr
=C2=A0

Regards,

Christer

From: Eric Rescorla <ekr@rtfm.com>
Date: Monday 6 February 2017 at 16:= 32
To: Christer Holmberg <christer.holmb= erg@ericsson.com>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Sending a=3Dr= tcp-mux-only w/o a=3Drtcp-mux



On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmber= g <chr= ister.holmberg@ericsson.com> wrote:
Hi,

>>> Following up to myself, I don't think it's sensible fo= r answers to
>>>contain a=3Drtcp-mux-only, because either you accepted mux, in = which case
>>>all is good, or you rejected it, in which case it was rejected.=
>>
>> While I agree that a=3Drtcp-mux would be enough in the Answer as f= ar as
>>indicating mux is concerned, including a=3Drtcp-mux-only in the Ans= wer
>>does indicate that the Answerer supports the mux-exclusive mechanis= m.
>
> I don't see how that's really that useful

But what harm does it cause?

I don't think that's the standard here. We should only send in= dicators in SDP when they
do something useful.

-Ekr


Regards,

Christer




On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla
<ekr@rtfm.com> = wrote:

I have been reading the mux-exclusive document and I'm not sure it says=
quite what we want. Specifically, S 4.2 says:

=C2=A0 =C2=A0When an offerer sends the initial offer, if the offerer wants = to
=C2=A0 =C2=A0indicate exclusive RTP/RTCP multiplexing for RTP-based media, = the
=C2=A0 =C2=A0offerer MUST associate an SDP 'rtcp-mux-only' attribut= e with the
=C2=A0 =C2=A0associated SDP media description ("m=3D" line).

=C2=A0 =C2=A0In addition, if the offerer associates an SDP 'rtcp-mux-on= ly'
=C2=A0 =C2=A0attribute with an SDP media description ("m=3D" line= ), the offerer MAY
=C2=A0 =C2=A0also associate an SDP 'rtcp-mux' attribute with the sa= me SDP media
=C2=A0 =C2=A0description ("m=3D" line), following the procedures = in [RFC5761].

As I understand this text, the offerer may say the following things:

=C2=A01. No a=3Drtcp-mux: No muxing.
=C2=A02. a=3Drtcp-mux: I am offering RTCP mux
=C2=A03. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux
=C2=A04. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3).

I don't think the last of these is sensible. No current implementation<= br> will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will<= br> result in interop failures. Thus the MAY in the second graf needs to be
a MUST.

-Ekr

--94eb2c11555ec537830547efd1ed-- From nobody Tue Feb 7 05:19:05 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4EF129BC7; Tue, 7 Feb 2017 05:19:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148647354417.16225.12818815152240150205.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2017 05:19:04 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msid-16.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 13:19:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : WebRTC MediaStream Identification in the Session Description Protocol Author : Harald Alvestrand Filename : draft-ietf-mmusic-msid-16.txt Pages : 18 Date : 2017-02-07 Abstract: This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-msid-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 7 05:19:48 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C73129426; Tue, 7 Feb 2017 05:19:45 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 0PudR1CgJIaF; Tue, 7 Feb 2017 05:19:43 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA02129BC9; Tue, 7 Feb 2017 05:19:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id DF9717C54A9; Tue, 7 Feb 2017 14:19:40 +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 Wab-TBhn8S4Q; Tue, 7 Feb 2017 14:19:39 +0100 (CET) Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 5F1137C5427; Tue, 7 Feb 2017 14:19:39 +0100 (CET) To: Flemming Andreasen , Victor Pascual Avila , Bernard Aboba References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> From: Harald Alvestrand Message-ID: Date: Tue, 7 Feb 2017 14:19:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] Change Alert [Re: Modifying an approved document: MSID] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 13:19:45 -0000 Den 03. feb. 2017 14:55, skrev Flemming Andreasen: > Based on the feedback received, it seems fine to make this change. Thank you; I've submitted -16 with this change. > > Thanks > > -- Flemming (as MMUSIC co-chair) > > On 1/30/17 8:28 AM, Victor Pascual Avila wrote: >> fine with me >> >> On Fri, Jan 27, 2017 at 7:20 PM, Bernard Aboba >> wrote: >>> I am in favor of the change. >>> >>> On Thu, Jan 26, 2017 at 5:54 AM, Flemming Andreasen >>> wrote: >>>> Hi Harald >>>> >>>> Since the document is not yet in Auth48 and the change is relatively >>>> minor, it is possible to update it during Auth48. >>>> >>>> However, from an MMUSIC chair point of view, I would like to get >>>> positive >>>> confirmation from some of the stakeholders that this change is indeed >>>> desired. Similarly, if anybody has any concerns with the suggested >>>> change, >>>> please send an e-mail to that effect. >>>> >>>> Thanks >>>> >>>> -- Flemming (as MMUSIC co-chair) >>>> >>>> >>>> >>>> On 1/23/17 10:18 AM, Harald Alvestrand wrote: >>>>> Den 19. jan. 2017 13:31, skrev Harald Alvestrand: >>>>>> Ted pointed out to me that I sent this to the wrong group. >>>>>> >>>>>> Chairs and members, please advise. >>>>> My proposed change is here: >>>>> >>>>> https://github.com/alvestrand/rtcweb-msid/pull/16 >>>>> >>>>> The filed issue is here: >>>>> >>>>> https://github.com/alvestrand/rtcweb-msid/issues/15 >>>>> >>>>> (CCing RTCWEB - please keep discussion, if any, on mmusic) >>>>> >>>>>> >>>>>> -------- Forwarded Message -------- >>>>>> Subject: [rtcweb] Modifying an approved document: MSID >>>>>> Date: Wed, 18 Jan 2017 23:22:14 +0100 >>>>>> From: Harald Alvestrand >>>>>> To: rtcweb@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> When reviewing the implications of the PeerConnection API change to >>>>>> support AddTrack rather than AddStream, I found an issue. >>>>>> >>>>>> This issue concerns draft-ietf-rtcweb-msid, which is currently in >>>>>> REF-WAIT state (I believe). >>>>>> >>>>>> The issue is that it is possible to add a track without specifying a >>>>>> stream. Since the track's ID needs to be carried, we have to send an >>>>>> "a=msid" line, but the track's ID is the *second* field on that line, >>>>>> with the first being the stream's ID. >>>>>> >>>>>> This creates a problem. >>>>>> >>>>>> Suggested fix: Insert two lines in the document: >>>>>> >>>>>> 1) On SDP generation: >>>>>> >>>>>> "If there is no stream associated with the track, use the reserved ID >>>>>> value '-'" >>>>>> >>>>>> 2) On SDP parsing >>>>>> >>>>>> "If the stream ID is the reserved value '-', the track is not >>>>>> associated >>>>>> with a stream, and no stream is signalled or created." >>>>>> >>>>>> If this is OK with the community, I'll issue an updated draft with >>>>>> this >>>>>> change. >>>>>> >>>>>> >>>>>> -- >>>>>> Surveillance is pervasive. Go Dark. >>>>>> >>>>>> _______________________________________________ >>>>>> rtcweb mailing list >>>>>> rtcweb@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> . >>>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> > From nobody Tue Feb 7 09:40:24 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F9D129E06 for ; Tue, 7 Feb 2017 09:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 i3DrFUQnqsFq for ; Tue, 7 Feb 2017 09:40:21 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BBD8129592 for ; Tue, 7 Feb 2017 09:40:21 -0800 (PST) X-AuditID: c1b4fb25-8948398000006c88-e9-589a06834fc8 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id E9.2D.27784.3860A985; Tue, 7 Feb 2017 18:40:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0319.002; Tue, 7 Feb 2017 18:40:18 +0100 From: Christer Holmberg To: Eric Rescorla Thread-Topic: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux Thread-Index: AQHSfkR3UhfsVBhEwUWv5/2Z0yKCVaFXfBcAgASHPoD//+NbAIAAMCIA///nooCAAVZKgIAAF9KAgABohoA= Date: Tue, 7 Feb 2017 17:40:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFEF197@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2J7uG4z26wIgw+zLSxWvD7HbjF1+WMW ByaPJUt+MnlMftzGHMAUxWWTkpqTWZZapG+XwJVxbed+9oJP8hUvHxxiamDskO9i5OSQEDCR +P3+EwuILSSwjlHi+HdZCHsRo0TbHYUuRg4ONgELie5/2iBhEQEFiV9/ToCVMwvIS1xYsoYJ xBYWsJFYd3oZM0SNrcTT7YeZQVpFBJIkHjxSAwmzCKhIrN6znxEkzCvgK7FvHWcXIxfQoiYW iWN9v8FaOQUCJfZ9uwU2klFATOL7KYjxzALiEreezGeCuFhAYsme88wQtqjEy8f/WCFsJYnG JU9YQeYzC2hKrN+lD9GqKDGl+yE7iM0rIChxcuYTlgmMorOQTJ2F0DELSccsJB0LGFlWMYoW pxYn5aYbGeulFmUmFxfn5+nlpZZsYgRGx8Etv1V3MF5+43iIUYCDUYmHt6B/RoQQa2JZcWXu IUYJDmYlEd5ZH2dGCPGmJFZWpRblxxeV5qQWH2KU5mBREuc1W3k/XEggPbEkNTs1tSC1CCbL xMEp1cDoyM833fH3qZ03t19lezdRJOjHC67K3Zr//S4q+InPLtoVU153dHK7J5f9Kf4UW1+m pR08R6bURMupKB394fzF4g/LzYR6bx+2PRJ/Z8Z3fVPZ1ifK6TB51bKE0F1q/+8rHcrmlJu0 jI3NcNKsRUnN31s++RYsdFjqc3WreASvn0PgrtcGre+UWIozEg21mIuKEwGXNrQ2igIAAA== Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:40:24 -0000 SGksDQoNCj4+IFdlIGhhZCBhIGxvbmcgZGlzY3Vzc2lvbiBhYm91dCB0aGlzLCB3aXRoIG1hbnkg ZGlmZmVyZW50IG9waW5pb25zLCBhbmQgaXQgd291bGQgdGFrZSBzb21lIHRpbWUgdG8gDQo+PiBn byB0aHJvdWdoIHRoZSBhcmNoaXZlIGFuZCBjaGVjayBldmVyeXRoaW5nLiBCdXQsIG9uZSBvcGlu aW9uIHdhcyB0aGF0IGl0IElTIHVzZWZ1bCB0byBzZW5kIHRoZSANCj4+IGF0dHJpYnV0ZSwgYXMg aXQgaW5kaWNhdGVzIHN1cHBvcnQgb2YgdGhlIG1lY2hhbmlzbS4NCj4NCj4gV2hhdCBkb2VzIHRo ZSBvdGhlciBzaWRlIGRvIHdpdGggdGhhdD8gDQoNCldlbGwsIGl0IGtub3dzIHRoYXQgaXQgZG9l c24ndCBoYXZlIHRvIGluY2x1ZGUgYT1ydGNwLW11eCB0aGUgbmV4dCB0aW1lIGl0IHdhbnRzIHRv IGRvIG11eC1vbmx5Lg0KDQpPYnZpb3VzbHksIGFzIHlvdSBzdWdnZXN0ZWQgaW4geW91ciBvcmln aW5hbCBlLW1haWwsIGlmIHdlIHdvdWxkbid0IGFsbG93IGE9cnRjcC1tdXgtb25seSB3aXRob3V0 IGE9cnRjcC1tdXggKGFsdCAjNCkgaW4gYW4gb2ZmZXIgdG8gYmVnaW4gd2l0aCwgaXQgZG9lc24n dCBtYXR0ZXIuDQoNCj4gSXMgdGhlcmUgYW55IHByZWNlZGVudCBmb3IgdGhpcyBpbiBTRFA/DQoN Ck5vdCBhbnl0aGluZyBJIGNhbiB0aGluayBvZi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K DQpGcm9tOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+DQpEYXRlOiBNb25kYXkgNiBGZWJy dWFyeSAyMDE3IGF0IDE2OjMyDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbT4NCkNjOiAibW11c2ljQGlldGYub3JnIiA8bW11c2ljQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIFNlbmRpbmcgYT1ydGNwLW11eC1vbmx5IHcvbyBhPXJ0 Y3AtbXV4DQoNCg0KDQpPbiBNb24sIEZlYiA2LCAyMDE3IGF0IDU6NTcgQU0sIENocmlzdGVyIEhv bG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KSGksDQoNCj4+ PiBGb2xsb3dpbmcgdXAgdG8gbXlzZWxmLCBJIGRvbid0IHRoaW5rIGl0J3Mgc2Vuc2libGUgZm9y IGFuc3dlcnMgdG8NCj4+PmNvbnRhaW4gYT1ydGNwLW11eC1vbmx5LCBiZWNhdXNlIGVpdGhlciB5 b3UgYWNjZXB0ZWQgbXV4LCBpbiB3aGljaCBjYXNlDQo+Pj5hbGwgaXMgZ29vZCwgb3IgeW91IHJl amVjdGVkIGl0LCBpbiB3aGljaCBjYXNlIGl0IHdhcyByZWplY3RlZC4NCj4+DQo+PiBXaGlsZSBJ IGFncmVlIHRoYXQgYT1ydGNwLW11eCB3b3VsZCBiZSBlbm91Z2ggaW4gdGhlIEFuc3dlciBhcyBm YXIgYXMNCj4+aW5kaWNhdGluZyBtdXggaXMgY29uY2VybmVkLCBpbmNsdWRpbmcgYT1ydGNwLW11 eC1vbmx5IGluIHRoZSBBbnN3ZXINCj4+ZG9lcyBpbmRpY2F0ZSB0aGF0IHRoZSBBbnN3ZXJlciBz dXBwb3J0cyB0aGUgbXV4LWV4Y2x1c2l2ZSBtZWNoYW5pc20uDQo+DQo+IEkgZG9uJ3Qgc2VlIGhv dyB0aGF0J3MgcmVhbGx5IHRoYXQgdXNlZnVsDQoNCkJ1dCB3aGF0IGhhcm0gZG9lcyBpdCBjYXVz ZT8NCg0KSSBkb24ndCB0aGluayB0aGF0J3MgdGhlIHN0YW5kYXJkIGhlcmUuIFdlIHNob3VsZCBv bmx5IHNlbmQgaW5kaWNhdG9ycyBpbiBTRFAgd2hlbiB0aGV5DQpkbyBzb21ldGhpbmcgdXNlZnVs Lg0KDQotRWtyDQoNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KT24gRnJpLCBGZWIg MywgMjAxNyBhdCA5OjM4IEFNLCBFcmljIFJlc2NvcmxhDQo8ZWtyQHJ0Zm0uY29tPiB3cm90ZToN Cg0KSSBoYXZlIGJlZW4gcmVhZGluZyB0aGUgbXV4LWV4Y2x1c2l2ZSBkb2N1bWVudCBhbmQgSSdt IG5vdCBzdXJlIGl0IHNheXMNCnF1aXRlIHdoYXQgd2Ugd2FudC4gU3BlY2lmaWNhbGx5LCBTIDQu MiBzYXlzOg0KDQrCoCDCoFdoZW4gYW4gb2ZmZXJlciBzZW5kcyB0aGUgaW5pdGlhbCBvZmZlciwg aWYgdGhlIG9mZmVyZXIgd2FudHMgdG8NCsKgIMKgaW5kaWNhdGUgZXhjbHVzaXZlIFJUUC9SVENQ IG11bHRpcGxleGluZyBmb3IgUlRQLWJhc2VkIG1lZGlhLCB0aGUNCsKgIMKgb2ZmZXJlciBNVVNU IGFzc29jaWF0ZSBhbiBTRFAgJ3J0Y3AtbXV4LW9ubHknIGF0dHJpYnV0ZSB3aXRoIHRoZQ0KwqAg wqBhc3NvY2lhdGVkIFNEUCBtZWRpYSBkZXNjcmlwdGlvbiAoIm09IiBsaW5lKS4NCg0KwqAgwqBJ biBhZGRpdGlvbiwgaWYgdGhlIG9mZmVyZXIgYXNzb2NpYXRlcyBhbiBTRFAgJ3J0Y3AtbXV4LW9u bHknDQrCoCDCoGF0dHJpYnV0ZSB3aXRoIGFuIFNEUCBtZWRpYSBkZXNjcmlwdGlvbiAoIm09IiBs aW5lKSwgdGhlIG9mZmVyZXIgTUFZDQrCoCDCoGFsc28gYXNzb2NpYXRlIGFuIFNEUCAncnRjcC1t dXgnIGF0dHJpYnV0ZSB3aXRoIHRoZSBzYW1lIFNEUCBtZWRpYQ0KwqAgwqBkZXNjcmlwdGlvbiAo Im09IiBsaW5lKSwgZm9sbG93aW5nIHRoZSBwcm9jZWR1cmVzIGluIFtSRkM1NzYxXS4NCg0KQXMg SSB1bmRlcnN0YW5kIHRoaXMgdGV4dCwgdGhlIG9mZmVyZXIgbWF5IHNheSB0aGUgZm9sbG93aW5n IHRoaW5nczoNCg0KwqAxLiBObyBhPXJ0Y3AtbXV4OiBObyBtdXhpbmcuDQrCoDIuIGE9cnRjcC1t dXg6IEkgYW0gb2ZmZXJpbmcgUlRDUCBtdXgNCsKgMy4gYT1ydGNwLW11eC1vbmx5ICsgYT1ydGNw LW11eDogSSB3aWxsIG9ubHkgZG8gUlRDUCBtdXgNCsKgNC4gYT1ydGNwLW11eC1vbmx5OiBJIHdp bGwgb25seSBkbyBSVENQIG11eCAoc2FtZSBhcyAjMykuDQoNCkkgZG9uJ3QgdGhpbmsgdGhlIGxh c3Qgb2YgdGhlc2UgaXMgc2Vuc2libGUuIE5vIGN1cnJlbnQgaW1wbGVtZW50YXRpb24NCndpbGwg a25vdyB3aGF0IHRvIGRvIHdpdGggYT1ydGNwLW11eC1vbmx5IHcvbyBhPXJ0Y3AtbXV4LCBzbyB0 aGlzIHdpbGwNCnJlc3VsdCBpbiBpbnRlcm9wIGZhaWx1cmVzLiBUaHVzIHRoZSBNQVkgaW4gdGhl IHNlY29uZCBncmFmIG5lZWRzIHRvIGJlDQphIE1VU1QuDQoNCi1Fa3INCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0K From nobody Tue Feb 7 12:34:30 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515EC129ECA for ; Tue, 7 Feb 2017 12:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agLItaCxmJyv for ; Tue, 7 Feb 2017 12:34:27 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64EE2129EC6 for ; Tue, 7 Feb 2017 12:34:27 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id u68so74144068ywg.0 for ; Tue, 07 Feb 2017 12:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hXtbI75bttIu8uyiqmUCyE0jwGawEshIbcQz7jre2CE=; b=1iT1+16fcjyU5nvuzVXAR7+kuKZUZF3D7AnDgWKsTksJAPE8Spa8/P4rsejC8WGJem edFM8Vcpzj9GwDObuCp6Fe3I49EBNnnVtdn1hIhGHlYSKRquoheIqit+shFhJM0//JcS t1BktdPGRWw59R3nTYtt5O1PRixmyAGJL07spPbGHzsPhWvRpRHgzNP3fI65olzHfxKt l1qyLuh2tWziNLpXrp9dqTjrjVDv/60KfMBZKLePgyrAxgylq+DBaF5FlQsIiWC20ftv xB8K4NumI3Kpy6FD59IfhdvYlBnbzkX9YoI8piC2KOxDONuZ00uJ9vyHUjCeFo36b0wX 1DSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hXtbI75bttIu8uyiqmUCyE0jwGawEshIbcQz7jre2CE=; b=tm0W1fEHVS8LJYZ3lYMITHuCGLflrW8P6DhzrsbyAPDjVW4aqDfNCY1IGqggjswoZm 8uFwf2jCqeHVCyfw6txZvBrpnXNcwBu3h/69jAZOH6cquCmEAXAWk6tfppii5xVYEicU 9Tlc4g+ibIkGD4F751Ro+8A2zSVSwCpCMW/FELUIu57LeIXxCBR01HI19xyOvFea1aGQ +NIEYkvbAF3aqBi9LI2qKP+TdRaaMNxQnGy64t3Q8BIAF5fH/ytBSNwfBaRJMCE/+ibA lKhtnTDjmX7vjMXIpyv2+4JPCxo/987jXiQkrmCXMU5EDUoq9R4oc9tWaWLPP2BXQYjh vjxg== X-Gm-Message-State: AIkVDXLDbaqwlTOH6aUBPeEbAqiOHcoxH9VQmEOaKcan0sQH84ENZ3uPhfviScc13p4k18o4fD9Lb22HPzEyyg== X-Received: by 10.129.92.2 with SMTP id q2mr12822090ywb.87.1486499666708; Tue, 07 Feb 2017 12:34:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Tue, 7 Feb 2017 12:33:46 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFEF197@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BFEF197@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Tue, 7 Feb 2017 12:33:46 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114d6f169800880547f6acfb Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 20:34:29 -0000 --001a114d6f169800880547f6acfb Content-Type: text/plain; charset=UTF-8 On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >> We had a long discussion about this, with many different opinions, and > it would take some time to > >> go through the archive and check everything. But, one opinion was that > it IS useful to send the > >> attribute, as it indicates support of the mechanism. > > > > What does the other side do with that? > > Well, it knows that it doesn't have to include a=rtcp-mux the next time it > wants to do mux-only. > > Obviously, as you suggested in your original e-mail, if we wouldn't allow > a=rtcp-mux-only without a=rtcp-mux (alt #4) in an offer to begin with, it > doesn't matter. > Yeah, I don't think this is a plausible option. At this point it would be great to hear from anyone who thinks that we should allow a=rtcp-mux-only without a=rtcp-mux.... -Ekr > > > Is there any precedent for this in SDP? > > Not anything I can think of. > > Regards, > > Christer > > > From: Eric Rescorla > Date: Monday 6 February 2017 at 16:32 > To: Christer Holmberg > Cc: "mmusic@ietf.org" > Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux > > > > On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > Hi, > > >>> Following up to myself, I don't think it's sensible for answers to > >>>contain a=rtcp-mux-only, because either you accepted mux, in which case > >>>all is good, or you rejected it, in which case it was rejected. > >> > >> While I agree that a=rtcp-mux would be enough in the Answer as far as > >>indicating mux is concerned, including a=rtcp-mux-only in the Answer > >>does indicate that the Answerer supports the mux-exclusive mechanism. > > > > I don't see how that's really that useful > > But what harm does it cause? > > I don't think that's the standard here. We should only send indicators in > SDP when they > do something useful. > > -Ekr > > > Regards, > > Christer > > > > > On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla > wrote: > > I have been reading the mux-exclusive document and I'm not sure it says > quite what we want. Specifically, S 4.2 says: > > When an offerer sends the initial offer, if the offerer wants to > indicate exclusive RTP/RTCP multiplexing for RTP-based media, the > offerer MUST associate an SDP 'rtcp-mux-only' attribute with the > associated SDP media description ("m=" line). > > In addition, if the offerer associates an SDP 'rtcp-mux-only' > attribute with an SDP media description ("m=" line), the offerer MAY > also associate an SDP 'rtcp-mux' attribute with the same SDP media > description ("m=" line), following the procedures in [RFC5761]. > > As I understand this text, the offerer may say the following things: > > 1. No a=rtcp-mux: No muxing. > 2. a=rtcp-mux: I am offering RTCP mux > 3. a=rtcp-mux-only + a=rtcp-mux: I will only do RTCP mux > 4. a=rtcp-mux-only: I will only do RTCP mux (same as #3). > > I don't think the last of these is sensible. No current implementation > will know what to do with a=rtcp-mux-only w/o a=rtcp-mux, so this will > result in interop failures. Thus the MAY in the second graf needs to be > a MUST. > > -Ekr > > > > > > > > > > > > > > > > > --001a114d6f169800880547f6acfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg <= ;christ= er.holmberg@ericsson.com> wrote:
Hi,

>> We had a long discussion about this, with many different opinions,= and it would take some time to
>> go through the archive and check everything. But, one opinion was = that it IS useful to send the
>> attribute, as it indicates support of the mechanism.
>
> What does the other side do with that?

Well, it knows that it doesn't have to include a=3Drtcp-mux the = next time it wants to do mux-only.

Obviously, as you suggested in your original e-mail, if we wouldn't all= ow a=3Drtcp-mux-only without a=3Drtcp-mux (alt #4) in an offer to begin wit= h, it doesn't matter.

Yeah, I don&#= 39;t think this is a plausible option.

At this poi= nt it would be great to hear from anyone who thinks that we should allow
a=3Drtcp-mux-only without a=3Drtcp-mux....

-Ekr
=C2=A0

> Is there any precedent for this in SDP?

Not anything I can think of.

Regards,

Christer


From: Eric Rescorla <ekr@rtfm.com>= ;
Date: Monday 6 February 2017 at 16:32
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: Re: [MMUSIC] Sending a=3Drtcp-mux-only w/o a=3Drtcp-mux



On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg <christer.holmberg@ericsson.com> wr= ote:
Hi,

>>> Following up to myself, I don't think it's sensible fo= r answers to
>>>contain a=3Drtcp-mux-only, because either you accepted mux, in = which case
>>>all is good, or you rejected it, in which case it was rejected.=
>>
>> While I agree that a=3Drtcp-mux would be enough in the Answer as f= ar as
>>indicating mux is concerned, including a=3Drtcp-mux-only in the Ans= wer
>>does indicate that the Answerer supports the mux-exclusive mechanis= m.
>
> I don't see how that's really that useful

But what harm does it cause?

I don't think that's the standard here. We should only send indicat= ors in SDP when they
do something useful.

-Ekr


Regards,

Christer




On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla
<ekr@rtfm.com> wrote:

I have been reading the mux-exclusive document and I'm not sure it says=
quite what we want. Specifically, S 4.2 says:

=C2=A0 =C2=A0When an offerer sends the initial offer, if the offerer wants = to
=C2=A0 =C2=A0indicate exclusive RTP/RTCP multiplexing for RTP-based media, = the
=C2=A0 =C2=A0offerer MUST associate an SDP 'rtcp-mux-only' attribut= e with the
=C2=A0 =C2=A0associated SDP media description ("m=3D" line).

=C2=A0 =C2=A0In addition, if the offerer associates an SDP 'rtcp-mux-on= ly'
=C2=A0 =C2=A0attribute with an SDP media description ("m=3D" line= ), the offerer MAY
=C2=A0 =C2=A0also associate an SDP 'rtcp-mux' attribute with the sa= me SDP media
=C2=A0 =C2=A0description ("m=3D" line), following the procedures = in [RFC5761].

As I understand this text, the offerer may say the following things:

=C2=A01. No a=3Drtcp-mux: No muxing.
=C2=A02. a=3Drtcp-mux: I am offering RTCP mux
=C2=A03. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux
=C2=A04. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3).

I don't think the last of these is sensible. No current implementation<= br> will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will<= br> result in interop failures. Thus the MAY in the second graf needs to be
a MUST.

-Ekr

















--001a114d6f169800880547f6acfb-- From nobody Tue Feb 7 12:38:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0BB129ECE for ; Tue, 7 Feb 2017 12:38:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAZxxpt5-aAz for ; Tue, 7 Feb 2017 12:38:43 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4089F129EC7 for ; Tue, 7 Feb 2017 12:38:43 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id u25so100867213qki.2 for ; Tue, 07 Feb 2017 12:38:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w4dxqM6xqetICNIad9PXxPR1/8VMQyQjpO22je+trsA=; b=XXGGDxWjc2LX75RmmNAMavxb9SSE2mKPQDc1vT6WOUz3sw8BmRfKfAD6P2mEVf6CRK mLqHomnyYZ9ioX0lzeXeQcbcbpn3xqMV9DELoShaBmYmyVI6q9JM+QgKstri1yYtA7pA 8PyvgP8BAoopvBVw2obcCgjYoRDkwN67J4YlP+cBhLAeSfUXOdcAD40gyJBDrkB+YhdY aC5uA6T5I99WXjwPyiUsFkoMerLz4JiTnCmy885c16DkHMFe4h/r2LmvehkwOVyV8P2W FHXdmk1geG2mM+dq37qbQznokncUvJS/Fp7YdWzFnj2sWd5GsP3pzFfJR15usVlC2oiR ilBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w4dxqM6xqetICNIad9PXxPR1/8VMQyQjpO22je+trsA=; b=P7buqACnTL2k0dw4JUxQAgQEQJeax5lTll6vT/7NJ2V+Ms5erqN3iYDNUAMc8UM6mg uY/OfpllORd7BYLJxmM1VdJMrf8TWvOA0uSIJmCtry1WuspY8yt2d3ueL6B+IHcRJn5/ 5afJAlGwFLd1r41E9cWLhRqqfq93daTP+Q0yXhI5PV8kbH3FVBNvYKUEUtNVSEVhiU8I kMl6I0ZrNuf8SXb21O1RpdGkYjJz2VJzlrUtNN57CBjAmjDMXDZ3ilUidSy8G31nmXic dyIubdITJs9mIz2XKYHd/8bQHfiX+bEc10hPV7sfKmYQ9gHmiKN2mj9+6ZeDMZNi8qnC sLLg== X-Gm-Message-State: AMke39k9DhEtfVgSCgR5pHtjXI4WSzgk9SMOmfk+lEkvXTpUjHrFWBPBF2sxraGSwqNhSA== X-Received: by 10.55.190.199 with SMTP id o190mr15970677qkf.292.1486499922228; Tue, 07 Feb 2017 12:38:42 -0800 (PST) Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com. [209.85.216.179]) by smtp.gmail.com with ESMTPSA id 140sm4311134qkj.19.2017.02.07.12.38.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 12:38:41 -0800 (PST) Received: by mail-qt0-f179.google.com with SMTP id k15so146702586qtg.3 for ; Tue, 07 Feb 2017 12:38:41 -0800 (PST) X-Received: by 10.200.52.129 with SMTP id w1mr15334219qtb.43.1486499921458; Tue, 07 Feb 2017 12:38:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Tue, 7 Feb 2017 12:38:40 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BFEF197@ESESSMB209.ericsson.se> From: Roman Shpount Date: Tue, 7 Feb 2017 15:38:40 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11479b4ac716f40547f6bb46 Archived-At: Cc: mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 20:38:45 -0000 --001a11479b4ac716f40547f6bb46 Content-Type: text/plain; charset=UTF-8 I want to be able to send rtcp-mux-only. I see plenty of scenarios where my solution communicates exclusively with Web browsers. Once they implement rtcp-mux-only, given the rate with which browsers are updated, I would like, at some point, stop using rtcp-mux instead of inserting legacy flag indefinitely. Regards, _____________ Roman Shpount On Tue, Feb 7, 2017 at 3:33 PM, Eric Rescorla wrote: > > > On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> We had a long discussion about this, with many different opinions, and >> it would take some time to >> >> go through the archive and check everything. But, one opinion was that >> it IS useful to send the >> >> attribute, as it indicates support of the mechanism. >> > >> > What does the other side do with that? >> >> Well, it knows that it doesn't have to include a=rtcp-mux the next time >> it wants to do mux-only. >> >> Obviously, as you suggested in your original e-mail, if we wouldn't allow >> a=rtcp-mux-only without a=rtcp-mux (alt #4) in an offer to begin with, it >> doesn't matter. >> > > Yeah, I don't think this is a plausible option. > > At this point it would be great to hear from anyone who thinks that we > should allow > a=rtcp-mux-only without a=rtcp-mux.... > > -Ekr > > >> >> > Is there any precedent for this in SDP? >> >> Not anything I can think of. >> >> Regards, >> >> Christer >> >> >> From: Eric Rescorla >> Date: Monday 6 February 2017 at 16:32 >> To: Christer Holmberg >> Cc: "mmusic@ietf.org" >> Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux >> >> >> >> On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> Hi, >> >> >>> Following up to myself, I don't think it's sensible for answers to >> >>>contain a=rtcp-mux-only, because either you accepted mux, in which case >> >>>all is good, or you rejected it, in which case it was rejected. >> >> >> >> While I agree that a=rtcp-mux would be enough in the Answer as far as >> >>indicating mux is concerned, including a=rtcp-mux-only in the Answer >> >>does indicate that the Answerer supports the mux-exclusive mechanism. >> > >> > I don't see how that's really that useful >> >> But what harm does it cause? >> >> I don't think that's the standard here. We should only send indicators in >> SDP when they >> do something useful. >> >> -Ekr >> >> >> Regards, >> >> Christer >> >> >> >> >> On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla >> wrote: >> >> I have been reading the mux-exclusive document and I'm not sure it says >> quite what we want. Specifically, S 4.2 says: >> >> When an offerer sends the initial offer, if the offerer wants to >> indicate exclusive RTP/RTCP multiplexing for RTP-based media, the >> offerer MUST associate an SDP 'rtcp-mux-only' attribute with the >> associated SDP media description ("m=" line). >> >> In addition, if the offerer associates an SDP 'rtcp-mux-only' >> attribute with an SDP media description ("m=" line), the offerer MAY >> also associate an SDP 'rtcp-mux' attribute with the same SDP media >> description ("m=" line), following the procedures in [RFC5761]. >> >> As I understand this text, the offerer may say the following things: >> >> 1. No a=rtcp-mux: No muxing. >> 2. a=rtcp-mux: I am offering RTCP mux >> 3. a=rtcp-mux-only + a=rtcp-mux: I will only do RTCP mux >> 4. a=rtcp-mux-only: I will only do RTCP mux (same as #3). >> >> I don't think the last of these is sensible. No current implementation >> will know what to do with a=rtcp-mux-only w/o a=rtcp-mux, so this will >> result in interop failures. Thus the MAY in the second graf needs to be >> a MUST. >> >> -Ekr >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a11479b4ac716f40547f6bb46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I want to be able to send rtcp-mux-only. I see plenty of s= cenarios where my solution communicates exclusively with Web browsers. Once= they implement rtcp-mux-only, given the rate with which browsers are updat= ed, I would like, at some point, stop using rtcp-mux instead of inserting l= egacy flag indefinitely.

Regards,
= _____________
Roman Shpount

On Tue, Feb 7, 2017 at 3:33 PM, Eric Rescorl= a <e= kr@rtfm.com> wrote:


On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Hi,

>> We had a long discussion about this, with many different opinions,= and it would take some time to
>> go through the archive and check everything. But, one opinion was = that it IS useful to send the
>> attribute, as it indicates support of the mechanism.
>
> What does the other side do with that?

Well, it knows that it doesn't have to i= nclude a=3Drtcp-mux the next time it wants to do mux-only.

Obviously, as you suggested in your original e-mail, if we wouldn't all= ow a=3Drtcp-mux-only without a=3Drtcp-mux (alt #4) in an offer to begin wit= h, it doesn't matter.

Yeah, = I don't think this is a plausible option.

At t= his point it would be great to hear from anyone who thinks that we should a= llow
a=3Drtcp-mux-only without a=3Drtcp-mux....

-Ekr
=C2=A0

> Is there any precedent for this in SDP?

Not anything I can think of.

Regards,

Christer


From: Eric Rescorla <e= kr@rtfm.com>
Date: Monday 6 February 2017 at 16:32
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "mmusic@ietf.= org" <mmus= ic@ietf.org>
Subject: Re: [MMUSIC] Sending a=3Drtcp-mux-only w/o a=3Drtcp-mux



On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
Hi,

>>> Following up to myself, I don't think it's sensible fo= r answers to
>>>contain a=3Drtcp-mux-only, because either you accepted mux, in = which case
>>>all is good, or you rejected it, in which case it was rejected.=
>>
>> While I agree that a=3Drtcp-mux would be enough in the Answer as f= ar as
>>indicating mux is concerned, including a=3Drtcp-mux-only in the Ans= wer
>>does indicate that the Answerer supports the mux-exclusive mechanis= m.
>
> I don't see how that's really that useful

But what harm does it cause?

I don't think that's the standard here. We should only send indicat= ors in SDP when they
do something useful.

-Ekr


Regards,

Christer




On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla
<ekr@rtfm.com> = wrote:

I have been reading the mux-exclusive document and I'm not sure it says=
quite what we want. Specifically, S 4.2 says:

=C2=A0 =C2=A0When an offerer sends the initial offer, if the offerer wants = to
=C2=A0 =C2=A0indicate exclusive RTP/RTCP multiplexing for RTP-based media, = the
=C2=A0 =C2=A0offerer MUST associate an SDP 'rtcp-mux-only' attribut= e with the
=C2=A0 =C2=A0associated SDP media description ("m=3D" line).

=C2=A0 =C2=A0In addition, if the offerer associates an SDP 'rtcp-mux-on= ly'
=C2=A0 =C2=A0attribute with an SDP media description ("m=3D" line= ), the offerer MAY
=C2=A0 =C2=A0also associate an SDP 'rtcp-mux' attribute with the sa= me SDP media
=C2=A0 =C2=A0description ("m=3D" line), following the procedures = in [RFC5761].

As I understand this text, the offerer may say the following things:

=C2=A01. No a=3Drtcp-mux: No muxing.
=C2=A02. a=3Drtcp-mux: I am offering RTCP mux
=C2=A03. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux
=C2=A04. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3).

I don't think the last of these is sensible. No current implementation<= br> will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will<= br> result in interop failures. Thus the MAY in the second graf needs to be
a MUST.

-Ekr


















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

--001a11479b4ac716f40547f6bb46-- From nobody Tue Feb 7 15:53:34 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F7012968A for ; Tue, 7 Feb 2017 15:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L51vhKKAIFDZ for ; Tue, 7 Feb 2017 15:53:29 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27401294DD for ; Tue, 7 Feb 2017 15:53:29 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id l19so76751736ywc.2 for ; Tue, 07 Feb 2017 15:53:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l+IT6cvlaKNgb//23x5mSIMwXOoa1Sm9DBwrpz+TWjM=; b=wM8432gXRY3XeCpFReOFcem8/yzn6aF+nzeN3kRl2qMLRSktzwDntISOnkZiR7wN/o jlKV9eQf2i3ZHs/WjOYEsjjBelhBMzY1IhlYIBhiY/hilPqqq6glNRdvSPqmRrtqOfQN t0B81pFFoxZySAtdfxQ81VUFY+UtJewxB4BvFOvchFODeOW0lugZ69BSENl3EajuLj/S seaZankt0IApldqEdBZB3mRStJRQjB+yyGX1ZPhGu+LgzWlqzmDBUF+AWKCJYRTxLY5z BztZ40QQmF3HGi2xaaO2QkJVmswhSdmQSLku0skTdJcoQ1Hq0l56TXdbqZlu3BOdEO1c rIqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l+IT6cvlaKNgb//23x5mSIMwXOoa1Sm9DBwrpz+TWjM=; b=kuGgFCphq6o+Kxb+yKohN9cGRMH4upLrKqkN7g4M6lR13g7fXCMsn4K/+hLgTsVwDF ngOwnPfLBBsz7o0qEQsC9W73D494qi32eA+yl4kb7/yknNTiCJ0U4QMlS2kW6q+erNt5 MQ99ULLzc54nIWqtuz6jwe40+ZdUdhonuGxQ58x0MQYJyELXufCsSz9dnKQuXEAVesP4 2JTovTQzuO7m+dMnIVS2iG86TcZgieBhrz5jUnxsHce55rKS4Uifqbkks+L5qxIrYKwo AUHCopW32/hUJmgQ5XkAgG++YBF07pY6NT5qJTz3dBCOjJqljAXJDPT/Q5950Ab0Tqvv uvtQ== X-Gm-Message-State: AIkVDXIagEyGOTrPzmfxvvidGC4RcoB0NZWsJK6iqSlY+93khYFdAi1CATlnpyGWJlF8dH0j3YPbZZHUjh658g== X-Received: by 10.129.137.129 with SMTP id z123mr13917103ywf.327.1486511608981; Tue, 07 Feb 2017 15:53:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Tue, 7 Feb 2017 15:52:48 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BFEF197@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Tue, 7 Feb 2017 15:52:48 -0800 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=94eb2c06bf38689ca00547f974f6 Archived-At: Cc: mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 23:53:32 -0000 --94eb2c06bf38689ca00547f974f6 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 7, 2017 at 12:38 PM, Roman Shpount wrote: > I want to be able to send rtcp-mux-only. I see plenty of scenarios where > my solution communicates exclusively with Web browsers. Once they implement > rtcp-mux-only, given the rate with which browsers are updated, I would > like, at some point, stop using rtcp-mux instead of inserting legacy flag > indefinitely. > What resource are you conserving here? It's not exactly consuming a lot of space in the SDP. -Ekr Regards, > _____________ > Roman Shpount > > On Tue, Feb 7, 2017 at 3:33 PM, Eric Rescorla wrote: > >> >> >> On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Hi, >>> >>> >> We had a long discussion about this, with many different opinions, >>> and it would take some time to >>> >> go through the archive and check everything. But, one opinion was >>> that it IS useful to send the >>> >> attribute, as it indicates support of the mechanism. >>> > >>> > What does the other side do with that? >>> >>> Well, it knows that it doesn't have to include a=rtcp-mux the next time >>> it wants to do mux-only. >>> >>> Obviously, as you suggested in your original e-mail, if we wouldn't >>> allow a=rtcp-mux-only without a=rtcp-mux (alt #4) in an offer to begin >>> with, it doesn't matter. >>> >> >> Yeah, I don't think this is a plausible option. >> >> At this point it would be great to hear from anyone who thinks that we >> should allow >> a=rtcp-mux-only without a=rtcp-mux.... >> >> -Ekr >> >> >>> >>> > Is there any precedent for this in SDP? >>> >>> Not anything I can think of. >>> >>> Regards, >>> >>> Christer >>> >>> >>> From: Eric Rescorla >>> Date: Monday 6 February 2017 at 16:32 >>> To: Christer Holmberg >>> Cc: "mmusic@ietf.org" >>> Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux >>> >>> >>> >>> On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> Hi, >>> >>> >>> Following up to myself, I don't think it's sensible for answers to >>> >>>contain a=rtcp-mux-only, because either you accepted mux, in which >>> case >>> >>>all is good, or you rejected it, in which case it was rejected. >>> >> >>> >> While I agree that a=rtcp-mux would be enough in the Answer as far as >>> >>indicating mux is concerned, including a=rtcp-mux-only in the Answer >>> >>does indicate that the Answerer supports the mux-exclusive mechanism. >>> > >>> > I don't see how that's really that useful >>> >>> But what harm does it cause? >>> >>> I don't think that's the standard here. We should only send indicators >>> in SDP when they >>> do something useful. >>> >>> -Ekr >>> >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla >>> wrote: >>> >>> I have been reading the mux-exclusive document and I'm not sure it says >>> quite what we want. Specifically, S 4.2 says: >>> >>> When an offerer sends the initial offer, if the offerer wants to >>> indicate exclusive RTP/RTCP multiplexing for RTP-based media, the >>> offerer MUST associate an SDP 'rtcp-mux-only' attribute with the >>> associated SDP media description ("m=" line). >>> >>> In addition, if the offerer associates an SDP 'rtcp-mux-only' >>> attribute with an SDP media description ("m=" line), the offerer MAY >>> also associate an SDP 'rtcp-mux' attribute with the same SDP media >>> description ("m=" line), following the procedures in [RFC5761]. >>> >>> As I understand this text, the offerer may say the following things: >>> >>> 1. No a=rtcp-mux: No muxing. >>> 2. a=rtcp-mux: I am offering RTCP mux >>> 3. a=rtcp-mux-only + a=rtcp-mux: I will only do RTCP mux >>> 4. a=rtcp-mux-only: I will only do RTCP mux (same as #3). >>> >>> I don't think the last of these is sensible. No current implementation >>> will know what to do with a=rtcp-mux-only w/o a=rtcp-mux, so this will >>> result in interop failures. Thus the MAY in the second graf needs to be >>> a MUST. >>> >>> -Ekr >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > --94eb2c06bf38689ca00547f974f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 7, 2017 at 12:38 PM, Roman Shpount <roman@telurix.com> wrote:
I want to be a= ble to send rtcp-mux-only. I see plenty of scenarios where my solution comm= unicates exclusively with Web browsers. Once they implement rtcp-mux-only, = given the rate with which browsers are updated, I would like, at some point= , stop using rtcp-mux instead of inserting legacy flag indefinitely.
<= /blockquote>

What resource are you conserving here? It&#= 39;s not exactly consuming a lot of space in the SDP.

<= div>-Ekr



Regards,
_____________<= br>Roman Shpount

On Tue, Feb 7, 2017 a= t 3:33 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Feb 7,= 2017 at 9:40 AM, Christer Holmberg <christer.holmberg@ericss= on.com> wrote:
= Hi,

>> We had a long discussion about this, with many different opinions,= and it would take some time to
>> go through the archive and check everything. But, one opinion was = that it IS useful to send the
>> attribute, as it indicates support of the mechanism.
>
> What does the other side do with that?

Well, it knows that it doesn't have to include a=3D= rtcp-mux the next time it wants to do mux-only.

Obviously, as you suggested in your original e-mail, if we wouldn't all= ow a=3Drtcp-mux-only without a=3Drtcp-mux (alt #4) in an offer to begin wit= h, it doesn't matter.

Yeah, = I don't think this is a plausible option.

At t= his point it would be great to hear from anyone who thinks that we should a= llow
a=3Drtcp-mux-only without a=3Drtcp-mux....

-Ekr
=C2=A0

> Is there any precedent for this in SDP?

Not anything I can think of.

Regards,

Christer


From: Eric Rescorla <e= kr@rtfm.com>
Date: Monday 6 February 2017 at 16:32
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "mmusic@ietf.= org" <mmus= ic@ietf.org>
Subject: Re: [MMUSIC] Sending a=3Drtcp-mux-only w/o a=3Drtcp-mux



On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
Hi,

>>> Following up to myself, I don't think it's sensible fo= r answers to
>>>contain a=3Drtcp-mux-only, because either you accepted mux, in = which case
>>>all is good, or you rejected it, in which case it was rejected.=
>>
>> While I agree that a=3Drtcp-mux would be enough in the Answer as f= ar as
>>indicating mux is concerned, including a=3Drtcp-mux-only in the Ans= wer
>>does indicate that the Answerer supports the mux-exclusive mechanis= m.
>
> I don't see how that's really that useful

But what harm does it cause?

I don't think that's the standard here. We should only send indicat= ors in SDP when they
do something useful.

-Ekr


Regards,

Christer




On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla
<ekr@rtfm.com> = wrote:

I have been reading the mux-exclusive document and I'm not sure it says=
quite what we want. Specifically, S 4.2 says:

=C2=A0 =C2=A0When an offerer sends the initial offer, if the offerer wants = to
=C2=A0 =C2=A0indicate exclusive RTP/RTCP multiplexing for RTP-based media, = the
=C2=A0 =C2=A0offerer MUST associate an SDP 'rtcp-mux-only' attribut= e with the
=C2=A0 =C2=A0associated SDP media description ("m=3D" line).

=C2=A0 =C2=A0In addition, if the offerer associates an SDP 'rtcp-mux-on= ly'
=C2=A0 =C2=A0attribute with an SDP media description ("m=3D" line= ), the offerer MAY
=C2=A0 =C2=A0also associate an SDP 'rtcp-mux' attribute with the sa= me SDP media
=C2=A0 =C2=A0description ("m=3D" line), following the procedures = in [RFC5761].

As I understand this text, the offerer may say the following things:

=C2=A01. No a=3Drtcp-mux: No muxing.
=C2=A02. a=3Drtcp-mux: I am offering RTCP mux
=C2=A03. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux
=C2=A04. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3).

I don't think the last of these is sensible. No current implementation<= br> will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will<= br> result in interop failures. Thus the MAY in the second graf needs to be
a MUST.

-Ekr


















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


--94eb2c06bf38689ca00547f974f6-- From nobody Tue Feb 7 16:27:04 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCA41296EE for ; Tue, 7 Feb 2017 16:27:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2T3E_hmPLBG for ; Tue, 7 Feb 2017 16:27:01 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC66E1296D2 for ; Tue, 7 Feb 2017 16:27:00 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id x49so151040757qtc.2 for ; Tue, 07 Feb 2017 16:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YrXIQE1UyYjOAZrx9vxozdKypchUvSJWy3BT8Q6Ww5I=; b=MkN6MMiD9BGgfM6E4c6hoC/2SqIsswKHDcWSE5ed/jXo1DrLfig+3PxTXSfW4StQDh WSED2JyOj2hLL40gdBBiIMA/qBS/cxbSKNdl63HxYkIxCCRyXHoVouya+7qjViQl0ILZ 9fNayACxvEdZf6KQQ0segCz9FbIx8R5/a31yNufMw9dn+9Fw7nmaH2G4/53ukVjgU1MD TXT05umE7pNbKX23IKqdoTSLAJQyXemfyztvvHWBLJJmyu1Enu0iMsC3N5hEadPFsj9+ mI64WCkR0ptPiDqFgiekpdVjXxI+RRzolBscdijr9ijbqJmXNrry3Oer+35BnPYD+I/x gZXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YrXIQE1UyYjOAZrx9vxozdKypchUvSJWy3BT8Q6Ww5I=; b=TQBnu3xcKR/P5zeH6QZ9GUcZ/G7+sa3NJ8w4em82MEkBCI3V0rf3iy6Uo3ZhZxV1vD CW46X8FUJOEJJXgmdDOqpEjLRzXBRQZF06WtiEhY1ABiJOkR5zXx/p/LM7+aScwNcvrv wcsw1qeqXYaTYY6+5OzZyR3VtemJ+w99IAQxmnqV7qkgvdgFLRuDuwojAH9S0zgVLtoE rk77H2+47WLdj10/B3k9U19RAjaZP6vtq1TS0Fsa5SYxO+yDMDfpQ60erBK3lPngiao0 eL+D58wg6fB8cDw3iiK1mCUgWb/R4R0d/d9I7l0zrZnj/zrBLk1OeK/rEUZzlH9g//nx HWmw== X-Gm-Message-State: AMke39mWMBPTWVkj3tsO+oL2bdg1ZiJwMsCIw+r6eOrdrOyPI/b3cfsNF99B+5Ti3VQDVA== X-Received: by 10.200.0.213 with SMTP id d21mr16477525qtg.44.1486513619646; Tue, 07 Feb 2017 16:26:59 -0800 (PST) Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com. [209.85.216.180]) by smtp.gmail.com with ESMTPSA id t7sm4781385qtb.11.2017.02.07.16.26.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 16:26:59 -0800 (PST) Received: by mail-qt0-f180.google.com with SMTP id w20so146211319qtb.1 for ; Tue, 07 Feb 2017 16:26:58 -0800 (PST) X-Received: by 10.200.39.77 with SMTP id h13mr18232659qth.62.1486513618770; Tue, 07 Feb 2017 16:26:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Tue, 7 Feb 2017 16:26:58 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BFEF197@ESESSMB209.ericsson.se> From: Roman Shpount Date: Tue, 7 Feb 2017 19:26:58 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11405bac3384020547f9ecc0 Archived-At: Cc: mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 00:27:03 -0000 --001a11405bac3384020547f9ecc0 Content-Type: text/plain; charset=UTF-8 Essentially a few test cases less to test. Regards, _____________ Roman Shpount On Tue, Feb 7, 2017 at 6:52 PM, Eric Rescorla wrote: > On Tue, Feb 7, 2017 at 12:38 PM, Roman Shpount wrote: > >> I want to be able to send rtcp-mux-only. I see plenty of scenarios where >> my solution communicates exclusively with Web browsers. Once they implement >> rtcp-mux-only, given the rate with which browsers are updated, I would >> like, at some point, stop using rtcp-mux instead of inserting legacy flag >> indefinitely. >> > > What resource are you conserving here? It's not exactly consuming a lot of > space in the SDP. > > -Ekr > > > > Regards, >> _____________ >> Roman Shpount >> >> On Tue, Feb 7, 2017 at 3:33 PM, Eric Rescorla wrote: >> >>> >>> >>> On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> >>>> Hi, >>>> >>>> >> We had a long discussion about this, with many different opinions, >>>> and it would take some time to >>>> >> go through the archive and check everything. But, one opinion was >>>> that it IS useful to send the >>>> >> attribute, as it indicates support of the mechanism. >>>> > >>>> > What does the other side do with that? >>>> >>>> Well, it knows that it doesn't have to include a=rtcp-mux the next time >>>> it wants to do mux-only. >>>> >>>> Obviously, as you suggested in your original e-mail, if we wouldn't >>>> allow a=rtcp-mux-only without a=rtcp-mux (alt #4) in an offer to begin >>>> with, it doesn't matter. >>>> >>> >>> Yeah, I don't think this is a plausible option. >>> >>> At this point it would be great to hear from anyone who thinks that we >>> should allow >>> a=rtcp-mux-only without a=rtcp-mux.... >>> >>> -Ekr >>> >>> >>>> >>>> > Is there any precedent for this in SDP? >>>> >>>> Not anything I can think of. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> From: Eric Rescorla >>>> Date: Monday 6 February 2017 at 16:32 >>>> To: Christer Holmberg >>>> Cc: "mmusic@ietf.org" >>>> Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux >>>> >>>> >>>> >>>> On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg < >>>> christer.holmberg@ericsson.com> wrote: >>>> Hi, >>>> >>>> >>> Following up to myself, I don't think it's sensible for answers to >>>> >>>contain a=rtcp-mux-only, because either you accepted mux, in which >>>> case >>>> >>>all is good, or you rejected it, in which case it was rejected. >>>> >> >>>> >> While I agree that a=rtcp-mux would be enough in the Answer as far as >>>> >>indicating mux is concerned, including a=rtcp-mux-only in the Answer >>>> >>does indicate that the Answerer supports the mux-exclusive mechanism. >>>> > >>>> > I don't see how that's really that useful >>>> >>>> But what harm does it cause? >>>> >>>> I don't think that's the standard here. We should only send indicators >>>> in SDP when they >>>> do something useful. >>>> >>>> -Ekr >>>> >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla >>>> wrote: >>>> >>>> I have been reading the mux-exclusive document and I'm not sure it says >>>> quite what we want. Specifically, S 4.2 says: >>>> >>>> When an offerer sends the initial offer, if the offerer wants to >>>> indicate exclusive RTP/RTCP multiplexing for RTP-based media, the >>>> offerer MUST associate an SDP 'rtcp-mux-only' attribute with the >>>> associated SDP media description ("m=" line). >>>> >>>> In addition, if the offerer associates an SDP 'rtcp-mux-only' >>>> attribute with an SDP media description ("m=" line), the offerer MAY >>>> also associate an SDP 'rtcp-mux' attribute with the same SDP media >>>> description ("m=" line), following the procedures in [RFC5761]. >>>> >>>> As I understand this text, the offerer may say the following things: >>>> >>>> 1. No a=rtcp-mux: No muxing. >>>> 2. a=rtcp-mux: I am offering RTCP mux >>>> 3. a=rtcp-mux-only + a=rtcp-mux: I will only do RTCP mux >>>> 4. a=rtcp-mux-only: I will only do RTCP mux (same as #3). >>>> >>>> I don't think the last of these is sensible. No current implementation >>>> will know what to do with a=rtcp-mux-only w/o a=rtcp-mux, so this will >>>> result in interop failures. Thus the MAY in the second graf needs to be >>>> a MUST. >>>> >>>> -Ekr >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >> > --001a11405bac3384020547f9ecc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Essentially a few test cases less to test.

<= div>Regards,
_____________
Roman Shpount

On Tue, Feb 7, 2017 at 6:52 PM, Eric Rescorl= a <e= kr@rtfm.com> wrote:
On Tue, Feb 7, 2017 at 12:38 PM, Roman Shpount <= roman@telurix.com> wrote:
I wa= nt to be able to send rtcp-mux-only. I see plenty of scenarios where my sol= ution communicates exclusively with Web browsers. Once they implement rtcp-= mux-only, given the rate with which browsers are updated, I would like, at = some point, stop using rtcp-mux instead of inserting legacy flag indefinite= ly.

What resource are you cons= erving here? It's not exactly consuming a lot of space in the SDP.

-Ekr

<= br>

Regards,
_____________
Roman Shpount



On Tue, Feb 7, 2017 at 9:40 AM, Christer Holm= berg <christer.holmberg@ericsson.com> wrot= e:
Hi,

>> We had a long discussion about this, with many different opinions,= and it would take some time to
>> go through the archive and check everything. But, one opinion was = that it IS useful to send the
>> attribute, as it indicates support of the mechanism.
>
> What does the other side do with that?

Well, it knows that it doesn't have to include a=3D= rtcp-mux the next time it wants to do mux-only.

Obviously, as you suggested in your original e-mail, if we wouldn't all= ow a=3Drtcp-mux-only without a=3Drtcp-mux (alt #4) in an offer to begin wit= h, it doesn't matter.

Yeah, = I don't think this is a plausible option.

At t= his point it would be great to hear from anyone who thinks that we should a= llow
a=3Drtcp-mux-only without a=3Drtcp-mux....

-Ekr
=C2=A0

> Is there any precedent for this in SDP?

Not anything I can think of.

Regards,

Christer


From: Eric Rescorla <e= kr@rtfm.com>
Date: Monday 6 February 2017 at 16:32
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "mmusic@ietf.= org" <mmus= ic@ietf.org>
Subject: Re: [MMUSIC] Sending a=3Drtcp-mux-only w/o a=3Drtcp-mux



On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
Hi,

>>> Following up to myself, I don't think it's sensible fo= r answers to
>>>contain a=3Drtcp-mux-only, because either you accepted mux, in = which case
>>>all is good, or you rejected it, in which case it was rejected.=
>>
>> While I agree that a=3Drtcp-mux would be enough in the Answer as f= ar as
>>indicating mux is concerned, including a=3Drtcp-mux-only in the Ans= wer
>>does indicate that the Answerer supports the mux-exclusive mechanis= m.
>
> I don't see how that's really that useful

But what harm does it cause?

I don't think that's the standard here. We should only send indicat= ors in SDP when they
do something useful.

-Ekr


Regards,

Christer




On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla
<ekr@rtfm.com> = wrote:

I have been reading the mux-exclusive document and I'm not sure it says=
quite what we want. Specifically, S 4.2 says:

=C2=A0 =C2=A0When an offerer sends the initial offer, if the offerer wants = to
=C2=A0 =C2=A0indicate exclusive RTP/RTCP multiplexing for RTP-based media, = the
=C2=A0 =C2=A0offerer MUST associate an SDP 'rtcp-mux-only' attribut= e with the
=C2=A0 =C2=A0associated SDP media description ("m=3D" line).

=C2=A0 =C2=A0In addition, if the offerer associates an SDP 'rtcp-mux-on= ly'
=C2=A0 =C2=A0attribute with an SDP media description ("m=3D" line= ), the offerer MAY
=C2=A0 =C2=A0also associate an SDP 'rtcp-mux' attribute with the sa= me SDP media
=C2=A0 =C2=A0description ("m=3D" line), following the procedures = in [RFC5761].

As I understand this text, the offerer may say the following things:

=C2=A01. No a=3Drtcp-mux: No muxing.
=C2=A02. a=3Drtcp-mux: I am offering RTCP mux
=C2=A03. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux
=C2=A04. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3).

I don't think the last of these is sensible. No current implementation<= br> will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will<= br> result in interop failures. Thus the MAY in the second graf needs to be
a MUST.

-Ekr


















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



--001a11405bac3384020547f9ecc0-- From nobody Tue Feb 7 17:16:00 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68F1129715 for ; Tue, 7 Feb 2017 17:15:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK0MrwVeShhW for ; Tue, 7 Feb 2017 17:15:57 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CDE1296F0 for ; Tue, 7 Feb 2017 17:15:41 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id u68so77789708ywg.0 for ; Tue, 07 Feb 2017 17:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wO1XUn4U3+H0uLMl5kuQj5x2+J+1Ju1/gGzBGXVGB/I=; b=rQE+lzfgUAXx6VXEfL5LXkdCQGz9A2zFTKcNAgthZwIqAOtwFgJ8ATz+agTa8ZsbL1 TpRmMjgcGmWeqOKXwz0kNK8nafdivZ6EvQ4fRHk/3+uNhf4rIagBw5wD4NbVkm0KcAdP 5jeyW6E0sJaUDx85+pnnohVG6JxyX1seStBLIIqzzEbsBlWpy8cjvxwZJGJgkZeza5ZC OVzcp5oouVN4I4WEl6a7J9d1+Q1CXcpYNQV+ngn4g8vh6IYVWzcby/RVJid6vkgqWVD/ Vkse0aWhcpQPPqlzSZ0n9bhBbDVaol4C+oFYS8mgHgjSB7mjYydqwap+2M01QYZyAGyX ur4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wO1XUn4U3+H0uLMl5kuQj5x2+J+1Ju1/gGzBGXVGB/I=; b=fmPvYbu5L6Q33+o8kghwy9UCjEv46YRGX9tWI5Hx/wsmX3n9Y1kU+/Y/FY/qfH+IYN jl1//f/cPJCmos7acWaqobf921xDcZSPntMBSAK1mzh5+olxHTFjVC2XwPF1Ob2RFzvC Nm0eUcfTAQhUB6FriazqT7qgam5dugSB5qzzSoI4Fof0R63db4N+7pnox6O7+8f/sMNZ fU1jmJF9o596+tMI87Y0+Th8bYxE+/4xro5BP54dxNNiD/CVDtox3QZqOz1KmAh8/tkx 3P17fTeyaqJoZY3hudQH4r1uIntDKXX4kfoDh5CICHGoyCDEuoM9Q1wqmh6SwOyaPsI2 JD/A== X-Gm-Message-State: AMke39kjtrcx+mYy/7KOPn8dtVyXdgWZr+bx1AYDuO6DVvwynW1Fpf5aeXxXH+MRx9hAj2cPqAfGIApfU1PLWA== X-Received: by 10.129.162.130 with SMTP id z124mr14356706ywg.276.1486516541088; Tue, 07 Feb 2017 17:15:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Tue, 7 Feb 2017 17:15:00 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BFEF197@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Tue, 7 Feb 2017 17:15:00 -0800 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=94eb2c1292926297550547fa9ad2 Archived-At: Cc: mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 01:15:59 -0000 --94eb2c1292926297550547fa9ad2 Content-Type: text/plain; charset=UTF-8 It seems like that just moves the load onto everyone else who has to process both the case where you have a=rtcp-mux and the one where you do not. -Ekr On Tue, Feb 7, 2017 at 4:26 PM, Roman Shpount wrote: > Essentially a few test cases less to test. > > Regards, > _____________ > Roman Shpount > > On Tue, Feb 7, 2017 at 6:52 PM, Eric Rescorla wrote: > >> On Tue, Feb 7, 2017 at 12:38 PM, Roman Shpount wrote: >> >>> I want to be able to send rtcp-mux-only. I see plenty of scenarios where >>> my solution communicates exclusively with Web browsers. Once they implement >>> rtcp-mux-only, given the rate with which browsers are updated, I would >>> like, at some point, stop using rtcp-mux instead of inserting legacy flag >>> indefinitely. >>> >> >> What resource are you conserving here? It's not exactly consuming a lot >> of space in the SDP. >> >> -Ekr >> >> >> >> Regards, >>> _____________ >>> Roman Shpount >>> >>> On Tue, Feb 7, 2017 at 3:33 PM, Eric Rescorla wrote: >>> >>>> >>>> >>>> On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg < >>>> christer.holmberg@ericsson.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> >> We had a long discussion about this, with many different opinions, >>>>> and it would take some time to >>>>> >> go through the archive and check everything. But, one opinion was >>>>> that it IS useful to send the >>>>> >> attribute, as it indicates support of the mechanism. >>>>> > >>>>> > What does the other side do with that? >>>>> >>>>> Well, it knows that it doesn't have to include a=rtcp-mux the next >>>>> time it wants to do mux-only. >>>>> >>>>> Obviously, as you suggested in your original e-mail, if we wouldn't >>>>> allow a=rtcp-mux-only without a=rtcp-mux (alt #4) in an offer to begin >>>>> with, it doesn't matter. >>>>> >>>> >>>> Yeah, I don't think this is a plausible option. >>>> >>>> At this point it would be great to hear from anyone who thinks that we >>>> should allow >>>> a=rtcp-mux-only without a=rtcp-mux.... >>>> >>>> -Ekr >>>> >>>> >>>>> >>>>> > Is there any precedent for this in SDP? >>>>> >>>>> Not anything I can think of. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> From: Eric Rescorla >>>>> Date: Monday 6 February 2017 at 16:32 >>>>> To: Christer Holmberg >>>>> Cc: "mmusic@ietf.org" >>>>> Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux >>>>> >>>>> >>>>> >>>>> On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg < >>>>> christer.holmberg@ericsson.com> wrote: >>>>> Hi, >>>>> >>>>> >>> Following up to myself, I don't think it's sensible for answers to >>>>> >>>contain a=rtcp-mux-only, because either you accepted mux, in which >>>>> case >>>>> >>>all is good, or you rejected it, in which case it was rejected. >>>>> >> >>>>> >> While I agree that a=rtcp-mux would be enough in the Answer as far >>>>> as >>>>> >>indicating mux is concerned, including a=rtcp-mux-only in the Answer >>>>> >>does indicate that the Answerer supports the mux-exclusive mechanism. >>>>> > >>>>> > I don't see how that's really that useful >>>>> >>>>> But what harm does it cause? >>>>> >>>>> I don't think that's the standard here. We should only send indicators >>>>> in SDP when they >>>>> do something useful. >>>>> >>>>> -Ekr >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla >>>>> wrote: >>>>> >>>>> I have been reading the mux-exclusive document and I'm not sure it says >>>>> quite what we want. Specifically, S 4.2 says: >>>>> >>>>> When an offerer sends the initial offer, if the offerer wants to >>>>> indicate exclusive RTP/RTCP multiplexing for RTP-based media, the >>>>> offerer MUST associate an SDP 'rtcp-mux-only' attribute with the >>>>> associated SDP media description ("m=" line). >>>>> >>>>> In addition, if the offerer associates an SDP 'rtcp-mux-only' >>>>> attribute with an SDP media description ("m=" line), the offerer MAY >>>>> also associate an SDP 'rtcp-mux' attribute with the same SDP media >>>>> description ("m=" line), following the procedures in [RFC5761]. >>>>> >>>>> As I understand this text, the offerer may say the following things: >>>>> >>>>> 1. No a=rtcp-mux: No muxing. >>>>> 2. a=rtcp-mux: I am offering RTCP mux >>>>> 3. a=rtcp-mux-only + a=rtcp-mux: I will only do RTCP mux >>>>> 4. a=rtcp-mux-only: I will only do RTCP mux (same as #3). >>>>> >>>>> I don't think the last of these is sensible. No current implementation >>>>> will know what to do with a=rtcp-mux-only w/o a=rtcp-mux, so this will >>>>> result in interop failures. Thus the MAY in the second graf needs to be >>>>> a MUST. >>>>> >>>>> -Ekr >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>>> >>> >> > --94eb2c1292926297550547fa9ad2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It seems like that just moves t= he load onto everyone else who has to process both the
case where you have a=3Drtcp-mux and the one where you do not.<= /div>

-Ekr

On Tue, Feb 7, 2017 at 4:26 PM, Roman Shpount <roman@t= elurix.com> wrote:
Essentially a few test cases less to test.

Rega= rds,
______= _______
Roman Shpount

On Tue, Feb 7, 2017 at 6:52 PM, Eric Rescorl= a <e= kr@rtfm.com> wrote:
On Tu= e, Feb 7, 2017 at 12:38 PM, Roman Shpount <roman@telurix.com> wrote:
I want to be ab= le to send rtcp-mux-only. I see plenty of scenarios where my solution commu= nicates exclusively with Web browsers. Once they implement rtcp-mux-only, g= iven the rate with which browsers are updated, I would like, at some point,= stop using rtcp-mux instead of inserting legacy flag indefinitely.

What resource are you conserving here= ? It's not exactly consuming a lot of space in the SDP.

<= /div>
-Ekr



Regards,
_= ____________
Roman Shpount

On Tue, Feb 7, 2017 at 3:33 PM, = Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Feb 7, 2017 at 9:40 AM, Chr= ister Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

>> We had a long discussion about this, with many different opinions,= and it would take some time to
>> go through the archive and check everything. But, one opinion was = that it IS useful to send the
>> attribute, as it indicates support of the mechanism.
>
> What does the other side do with that?

Well, it knows that it doesn't have to include a=3D= rtcp-mux the next time it wants to do mux-only.

Obviously, as you suggested in your original e-mail, if we wouldn't all= ow a=3Drtcp-mux-only without a=3Drtcp-mux (alt #4) in an offer to begin wit= h, it doesn't matter.

Yeah, = I don't think this is a plausible option.

At t= his point it would be great to hear from anyone who thinks that we should a= llow
a=3Drtcp-mux-only without a=3Drtcp-mux....

-Ekr
=C2=A0

> Is there any precedent for this in SDP?

Not anything I can think of.

Regards,

Christer


From: Eric Rescorla <e= kr@rtfm.com>
Date: Monday 6 February 2017 at 16:32
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "mmusic@ietf.= org" <mmus= ic@ietf.org>
Subject: Re: [MMUSIC] Sending a=3Drtcp-mux-only w/o a=3Drtcp-mux



On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
Hi,

>>> Following up to myself, I don't think it's sensible fo= r answers to
>>>contain a=3Drtcp-mux-only, because either you accepted mux, in = which case
>>>all is good, or you rejected it, in which case it was rejected.=
>>
>> While I agree that a=3Drtcp-mux would be enough in the Answer as f= ar as
>>indicating mux is concerned, including a=3Drtcp-mux-only in the Ans= wer
>>does indicate that the Answerer supports the mux-exclusive mechanis= m.
>
> I don't see how that's really that useful

But what harm does it cause?

I don't think that's the standard here. We should only send indicat= ors in SDP when they
do something useful.

-Ekr


Regards,

Christer




On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla
<ekr@rtfm.com> = wrote:

I have been reading the mux-exclusive document and I'm not sure it says=
quite what we want. Specifically, S 4.2 says:

=C2=A0 =C2=A0When an offerer sends the initial offer, if the offerer wants = to
=C2=A0 =C2=A0indicate exclusive RTP/RTCP multiplexing for RTP-based media, = the
=C2=A0 =C2=A0offerer MUST associate an SDP 'rtcp-mux-only' attribut= e with the
=C2=A0 =C2=A0associated SDP media description ("m=3D" line).

=C2=A0 =C2=A0In addition, if the offerer associates an SDP 'rtcp-mux-on= ly'
=C2=A0 =C2=A0attribute with an SDP media description ("m=3D" line= ), the offerer MAY
=C2=A0 =C2=A0also associate an SDP 'rtcp-mux' attribute with the sa= me SDP media
=C2=A0 =C2=A0description ("m=3D" line), following the procedures = in [RFC5761].

As I understand this text, the offerer may say the following things:

=C2=A01. No a=3Drtcp-mux: No muxing.
=C2=A02. a=3Drtcp-mux: I am offering RTCP mux
=C2=A03. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux
=C2=A04. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3).

I don't think the last of these is sensible. No current implementation<= br> will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will<= br> result in interop failures. Thus the MAY in the second graf needs to be
a MUST.

-Ekr


















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




--94eb2c1292926297550547fa9ad2-- From nobody Wed Feb 8 13:13:39 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74AE1294C7 for ; Wed, 8 Feb 2017 13:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 yOVNqbVuiLEX for ; Wed, 8 Feb 2017 13:13:35 -0800 (PST) Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8CE1294B1 for ; Wed, 8 Feb 2017 13:13:35 -0800 (PST) Received: from smtp29.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp29.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D4DE9251EE; Wed, 8 Feb 2017 16:13:24 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp29.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 8C2F624F86; Wed, 8 Feb 2017 16:13:24 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.24.4.137] ([UNAVAILABLE]. [128.107.241.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Wed, 08 Feb 2017 16:13:24 -0500 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Feb 2017 13:13:23 -0800 Message-Id: To: mmusic Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: RTCWeb IETF Subject: [MMUSIC] normative dependencies in draft-ietf-mmusic-sdp-bundle-negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 21:13:37 -0000 Looking at draft-ietf-mmusic-sdp-bundle-negotiation, it seems that it = would be fine to normatively depend on RFC 5245 instead of = ietf-mmusic-ice-sip-sdp. It does not rely on any changes in made from = 4245 to ice-sip-sdp.=20 We don't want JSEP to normatively depend on ietf-mmusic-ice-sip-sdp = since that is not needed. Could you change = draft-ietf-mmusic-sdp-bundle-negotiation to not normatively depend on = ietf-mmusic-ice-sip-sdp? Thanks From nobody Wed Feb 8 13:22:11 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E544127ABE; Wed, 8 Feb 2017 13:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jD0ZXiIqZE6R; Wed, 8 Feb 2017 13:22:08 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E72612949A; Wed, 8 Feb 2017 13:22:08 -0800 (PST) X-AuditID: c1b4fb3a-bb7cb98000005e23-a6-589b8bfe2d87 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 65.2C.24099.EFB8B985; Wed, 8 Feb 2017 22:22:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0319.002; Wed, 8 Feb 2017 22:22:05 +0100 From: Christer Holmberg To: Cullen Jennings , mmusic Thread-Topic: [MMUSIC] normative dependencies in draft-ietf-mmusic-sdp-bundle-negotiation Thread-Index: AQHSglA50cSQ9ZWGAEW5AKQpNBZRyqFfngYg Date: Wed, 8 Feb 2017 21:22:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFF2670@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7hO6/7tkRBo++qlt8WP+D0WLq8scs Fmv/tbM7MHssWfKTyePy+Y+MAUxRXDYpqTmZZalF+nYJXBlfN85mKzjAXnH+XxdzA+Mati5G Tg4JAROJj9NvgtlCAusYJY7eDIKwFzFKHPjL18XIwcEmYCHR/U8bJCwiYCvRt+sEM4jNLKAo 8WX5fLBWYYEoiSfHfzND1ERLfN4wiw3CNpJo3jCLFcRmEVCReHP3DhvISF4BX4l9l3ghNllK 3H99jxUkzClgJTF7TjxImFFATOL7qTVMEJvEJW49mc8EcbCAxJI955khbFGJl4//sULYShJr D29ngajXkViw+xMbhK0tsWzha7B6XgFBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRWjaHFq cXFuupGRXmpRZnJxcX6eXl5qySZGYKQc3PLbagfjweeOhxgFOBiVeHg3ZM2OEGJNLCuuzD3E KMHBrCTC69YBFOJNSaysSi3Kjy8qzUktPsQozcGiJM5rtvJ+uJBAemJJanZqakFqEUyWiYNT qoFxU8mxlR9s89bIKW34vK7s8vIviScdteo3RXZvafoeNOnMBbknqgJb9gp+WJybHWqdUlt6 juvEWUbtYq+cHZeVvXRe9Ds3HNz15JDekvtTD3/f0nCHj9frxuetaxJdN1+Y9/qJmqO1T7ik asgbSWZGjZpH4X9XaQoLvJN6qCLWfDR43Qvrqwd5lViKMxINtZiLihMBxNPjW5ACAAA= Archived-At: Cc: RTCWeb IETF Subject: Re: [MMUSIC] normative dependencies in draft-ietf-mmusic-sdp-bundle-negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 21:22:10 -0000 Hi, Don't you also reference trickle in JSEP? Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: 08 February 2017 23:13 To: mmusic Cc: RTCWeb IETF Subject: [MMUSIC] normative dependencies in draft-ietf-mmusic-sdp-bundle-ne= gotiation Looking at draft-ietf-mmusic-sdp-bundle-negotiation, it seems that it would= be fine to normatively depend on RFC 5245 instead of ietf-mmusic-ice-sip-s= dp. It does not rely on any changes in made from 4245 to ice-sip-sdp.=20 We don't want JSEP to normatively depend on ietf-mmusic-ice-sip-sdp since t= hat is not needed. Could you change draft-ietf-mmusic-sdp-bundle-negotiatio= n to not normatively depend on ietf-mmusic-ice-sip-sdp? Thanks _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Feb 8 15:10:15 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F096012A0A5; Wed, 8 Feb 2017 15:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzkUKp2DghZc; Wed, 8 Feb 2017 15:10:11 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F41412A0D7; Wed, 8 Feb 2017 15:09:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=490; q=dns/txt; s=iport; t=1486595394; x=1487804994; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=Qw0fym9sLr9qYKIn8pEKr25EJ3LWW5m4jA+TqAIX0+M=; b=eu07IDXo7vyYYPucj0JzxCo1wlL614dY/AfaPQjG166+IcgJyBmrFS9s TwBYxeCS0N9Yjh3s9v9jVuLhvnps8cm/FFfm6EzdGhZBjDmRZOy1t2vHO bjGNH7UOn417fxT+agvffwtdyHHpiNvlI12zt/oppwr5KoekQFJDSaIFY g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BkBADmpJtY/4sNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1FhAydfg1mvOIQbKohpQhUBAgEBAQEBAQFiKIUTFXYCJgJfAQwIAQG?= =?us-ascii?q?JYw0OsCeCJYtPAQEBAQEFAQEBAQEBHQWBC4VBggWKRIJfBZBBiy+SEoFjGIUXg?= =?us-ascii?q?y2FDYE5kxM1In4yHRU8hmAiNQGIfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,348,1484006400"; d="scan'208";a="383175242" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2017 23:09:53 +0000 Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v18N9rNE012310; Wed, 8 Feb 2017 23:09:53 GMT To: mmusic , draft-ietf-mmusic-sdp-simulcast@ietf.org From: Flemming Andreasen Message-ID: <01a352cf-9adc-18bb-3cd0-ce82d39e5490@cisco.com> Date: Wed, 8 Feb 2017 18:09:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 23:10:13 -0000 Greetings MMUSIC This is to announce a 2 week WGLC on the draft: https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-07.txt as Proposed Standard. Please review and provide any comments you may have on the document by Wednesday, February 22, 2017. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks -- Flemming (MMUSIC co-chair) From nobody Wed Feb 8 15:23:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAF412A0CC for ; Wed, 8 Feb 2017 15:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NOu10XlxJAc for ; Wed, 8 Feb 2017 15:23:53 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180CD129511 for ; Wed, 8 Feb 2017 15:23:53 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id x49so180822813qtc.2 for ; Wed, 08 Feb 2017 15:23:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/tflwvr+071yrKQI2wwdeZXfdaaz29EY8s3BOVXqI+A=; b=totjWz0flVqO0jwJNghw21iP4bgi077iKvskzpXFRxcRnau4IlK/WuvJAD579EXfO8 kzRNfb5skz2IT9iHguUaSZl9x+VFpQl3DPzuGWFPn1V3xbxqexayQ1ZN6iRPaj6b4A9s eAtcIW/KGaror3My3wHyX5LT4l0pwP04HBzabloA4ksh8QNYqTYRB2gJD7Og+JDr9VoS wxEKK/0bVTPnCe/kP31m0u51mA41MbzcOUZKdFb/pr0fVNWLxvmMuM+JqVrX6zZFgyxz ewa+hwgR9rYPdUPkR4OLuuzhV3u9JDLrAnVa2qWMklcjmVEfXv/JEoVttSJtjAcKS/eH fRow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/tflwvr+071yrKQI2wwdeZXfdaaz29EY8s3BOVXqI+A=; b=E8F4QZz9q+ZEsNWVvVQ5pRTqPQr9GtGSQFJkqV5U1D2Qo3fyBX5C57GnOe6ys5bV9D /MSAOVGalZDRr1rmSLWXPqdhD/bUwoT95Ml3VI2JPG+Vdb3FBUggPH36foeeZ9GiWA9P +0733Kwh/hKPF5GIaC33JINHQ7tuenQRxbzLhc1OOGItaHl96j8D4ZDV2a9/kc2qIXrS Dn+ikkLpW3nYGRy/ZHl4yLqFQH7/ytG+lususzwLzVMIiH+O0Qrpl+vOELpcuPz1rG8f kbZWXGZhWmoArwPVLJhMPmdtrltRT3IFTOmBaafdxlhlezLYrYJUYkIJ3e9x1ZjHfO99 Dm9A== X-Gm-Message-State: AMke39lmZ6YdqNW/yaFN3ipyy4W1h1Hm1g198+FHitVjEwdTki/9zk+jgUXKNv8NS24Jx0HwjwYNnwyQhl6NsORC X-Received: by 10.200.48.172 with SMTP id v41mr112500qta.54.1486596231905; Wed, 08 Feb 2017 15:23:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.38.188 with HTTP; Wed, 8 Feb 2017 15:23:51 -0800 (PST) From: Taylor Brandstetter Date: Wed, 8 Feb 2017 15:23:51 -0800 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary=001a113a14d05402b105480d281d Archived-At: Subject: [MMUSIC] Can we use "a=bundle-only" in subsequent offers, instead of using a "shared address"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 23:23:54 -0000 --001a113a14d05402b105480d281d Content-Type: text/plain; charset=UTF-8 In an initial offer, if we want to communicate "this 'm=' section must be either bundled or rejected", that's accomplished with "a=bundle-only": a=group:BUNDLE A B m=audio 10000 ... a=mid:A ... m=video 0 ... a=mid:B a=bundle-only In subsequent offers, this is accomplished by duplicating the IP address/port (see section 8.3.3): a=group:BUNDLE A B m=audio 10000 ... a=mid:A ... m=video 10000 ... a=mid:B Is this initial vs. subsequent offer difference necessary? Both blobs of SDP are communicating the same information, so the "shared address" rules seem to only add complexity. Also, the approach of using a "shared address" to communicate something isn't extensible to protocols that don't use an address for identification, like ICE. We'd need to define additional rules for those cases, or allow them specifically to use "a=bundle-only" in subsequent offers. --001a113a14d05402b105480d281d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In an initial offer, if we want to communicate "= this 'm=3D' section must be either bundled or rejected", that&= #39;s accomplished with "a=3Dbundle-only":

a=3Dgroup:BUNDLE A B
m=3Daudio 10000 ...
= a=3Dmid:A
...
m=3Dvideo 0 ...
a=3Dbundle= -only

In subsequent offers, this is accompl= ished by duplicating the IP address/port (see section 8.3.3):
a=3Dgroup:BUNDLE A B=
m=3Daudio=C2=A010000=C2=A0...
a=3Dmid:A
...
m=3D= video=C2=A010000=C2=A0...
a=3Dmid:B

Is thi= s initial vs. subsequent offer difference necessary? Both blobs of SDP are = communicating the same information, so the "shared address" rules= seem to only add complexity.

Also, the approach o= f using a "shared address" to communicate something isn't ext= ensible to protocols that don't use an address for identification, like= ICE. We'd need to define additional rules for those cases, or allow th= em specifically to use "a=3Dbundle-only" in subsequent offers.
--001a113a14d05402b105480d281d-- From nobody Wed Feb 8 16:14:10 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD681294DB; Wed, 8 Feb 2017 16:14:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148659924433.4342.11826853350029314823.idtracker@ietfa.amsl.com> Date: Wed, 08 Feb 2017 16:14:04 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rid-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 00:14:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : RTP Payload Format Restrictions Authors : Peter Thatcher Mo Zanaty Suhas Nandakumar Bo Burman Adam Roach Byron Campen Filename : draft-ietf-mmusic-rid-09.txt Pages : 25 Date : 2017-02-08 Abstract: In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol. This framework defines a new "rid" SDP attribute to unambiguously identify the RTP Streams within a RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the restrictions defined by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-rid-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rid-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 Thu Feb 9 00:55:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670DE12973D for ; Thu, 9 Feb 2017 00:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 IKFpJp5e-jhs for ; Thu, 9 Feb 2017 00:55:52 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E58129618 for ; Thu, 9 Feb 2017 00:55:51 -0800 (PST) X-AuditID: c1b4fb30-f7ac898000007389-53-589c2e965457 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 19.FE.29577.69E2C985; Thu, 9 Feb 2017 09:55:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 09:55:41 +0100 From: Christer Holmberg To: Taylor Brandstetter , mmusic WG Thread-Topic: [MMUSIC] Can we use "a=bundle-only" in subsequent offers, instead of using a "shared address"? Thread-Index: AQHSgmJtSJnKWRlz6kyWOb8c3XMxoKFgcSgA Date: Thu, 9 Feb 2017 08:55:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D4C1FAC717AEEchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7lu40vTkRBjM+CVhcXvGQ1WLq8scs DkweCzaVeixZ8pMpgCmKyyYlNSezLLVI3y6BK+PivR+MBdeNKrqunWBqYGzS6WLk5JAQMJF4 8fg+axcjF4eQwDpGiSXbvkI5ixglti39wNzFyMHBJmAh0f1PG6RBRMBLYsmXV8wgtrBArkTb r5vsEPE8iZudzxghbCOJrVPesoDYLAIqEismbGEBGcMrYC3RvDUSJCwkECAx4eEfVpAwp0Cg xOQ1eiBhRgExie+n1jCB2MwC4hK3nsxngjhTQGLJnvPMELaoxMvH/1hBbFEBPYnlz9dAxRUl dp5tBzuYWSBBouukAUiYV0BQ4uTMJywTGEVmIZk6C6FqFpIqiBIDiffn5jND2NoSyxa+hrL1 JTZ+OcsIYVtLnLxygR1ZzQJGjlWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgVF2cMtvgx2M L587HmIU4GBU4uHdkDU7Qog1say4MvcQowQHs5IIr6bGnAgh3pTEyqrUovz4otKc1OJDjNIc LErivGYr74cLCaQnlqRmp6YWpBbBZJk4OKUaGGff9txYFXNHSPvByku3pdc9Lb/jXvRp5U42 t45/Zctn7kide+fLtIjPVY/WazH2eF2L9A5oeyw37Tmjj+an7Ka5L7+ffPVpyvmMAN2Wfv4q nYeJjrOUHQt3Tbgv6uF53Yb38V6n/8IMy31nPIz5te37lMOHjeoSrs8L4BHT0tTY7c5SVHR8 mY8SS3FGoqEWc1FxIgB4pfamrgIAAA== Archived-At: Subject: Re: [MMUSIC] Can we use "a=bundle-only" in subsequent offers, instead of using a "shared address"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 08:55:53 -0000 --_000_D4C1FAC717AEEchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, In principle, sending port zero + bundle-only also in subsequent offers sho= uld be ok. However, there always needs to be at least one m- line containing the actua= l used port, and the answerer must not reject that m- line (no matter wheth= er it=92s an initial or subsequent request). The advantage of sending the = =93shared address=94 is that the answerer can reject any m- line, as all th= e other m- lines contain the used port. Regards, Christer From: mmusic > on b= ehalf of Taylor Brandstetter > Date: Thursday 9 February 2017 at 01:23 To: "mmusic@ietf.org" > Subject: [MMUSIC] Can we use "a=3Dbundle-only" in subsequent offers, instea= d of using a "shared address"? In an initial offer, if we want to communicate "this 'm=3D' section must be= either bundled or rejected", that's accomplished with "a=3Dbundle-only": a=3Dgroup:BUNDLE A B m=3Daudio 10000 ... a=3Dmid:A ... m=3Dvideo 0 ... a=3Dmid:B a=3Dbundle-only In subsequent offers, this is accomplished by duplicating the IP address/po= rt (see section 8.3.3): a=3Dgroup:BUNDLE A B m=3Daudio 10000 ... a=3Dmid:A ... m=3Dvideo 10000 ... a=3Dmid:B Is this initial vs. subsequent offer difference necessary? Both blobs of SD= P are communicating the same information, so the "shared address" rules see= m to only add complexity. Also, the approach of using a "shared address" to communicate something isn= 't extensible to protocols that don't use an address for identification, li= ke ICE. We'd need to define additional rules for those cases, or allow them= specifically to use "a=3Dbundle-only" in subsequent offers. --_000_D4C1FAC717AEEchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <25462F653B994E41B718EEE351ABB02A@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

In principle, sending port zero + bundle-only also in subsequent o= ffers should be ok. 

However, there always needs to be at least one m- line containing the = actual used port, and the answerer must not reject that m- line (no matter = whether it=92s an initial or subsequent request). The advantage of sending = the =93shared address=94 is that the answerer can reject any m- line, as all the other m- lines contain the used port.

Regards,

Christer



From: mmusic <mmusic-bounces@ietf.org> on behalf of Taylo= r Brandstetter <deadbeef@google.c= om>
Date: Thursday 9 February 2017 at 0= 1:23
To: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: [MMUSIC] Can we use "= a=3Dbundle-only" in subsequent offers, instead of using a "shared= address"?

In an initial offer, if we want to communicate "this 'm=3D' secti= on must be either bundled or rejected", that's accomplished with "= ;a=3Dbundle-only":

a=3Dgroup:BUNDLE A B
m=3Daudio 10000 ...
a=3Dmid:A
...
m=3Dvideo 0 ...
a=3Dmid:B
a=3Dbundle-only

In subsequent offers, this is accomplished by duplicating the IP addre= ss/port (see section 8.3.3):

a=3Dgroup:BUNDLE A B
m=3Daudio&nbs= p;10000 ...
a=3Dmid:A
...
m=3Dvideo 10000 ...
a=3Dmid:B

Is this initial vs. subsequent offer difference necessary? Both blobs = of SDP are communicating the same information, so the "shared address&= quot; rules seem to only add complexity.

Also, the approach of using a "shared address" to communicat= e something isn't extensible to protocols that don't use an address for ide= ntification, like ICE. We'd need to define additional rules for those cases= , or allow them specifically to use "a=3Dbundle-only" in subsequent offers.
 --_000_D4C1FAC717AEEchristerholmbergericssoncom_-- From nobody Thu Feb 9 01:46:43 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10463129636 for ; Thu, 9 Feb 2017 01:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hkdBF9Lerz4 for ; Thu, 9 Feb 2017 01:46:40 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4C5129488 for ; Thu, 9 Feb 2017 01:46:40 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id x49so190961845qtc.2 for ; Thu, 09 Feb 2017 01:46:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ypteY1Gu8Iri7bAoU8i1Zo+yw55dKAXmW4IRfYJVGXs=; b=qoQMfATsMpllRuwvseyHonsWLvQAv4SWIgINTtOdB9mWW5lthpyns8oBgHZVTMZEc9 Qe1f9pwcHJJzc3VLgZhNMBjnD3QdHLlPq9NSb0xcej309E+z80br0zv8ymoYjAiODI8g kj2DX5QMjJYv8EW5QnQxz43kK28vUnFR+KivnRo4dkMpgDGrqBtt7+1+tb5y7W2+b3hF 29rx1XIIMAGJ0LHjmBA1BTxHOmQ01MxcnQp7/f6kBLNDZ0BgH7JdM+AsyI6pCKga03AK KowYynmTi+hMhIFiGfw9ZTyRiNaCvPh306uWekPJlatD/7KNqOWQXDvoLcIH482uBJES jtwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ypteY1Gu8Iri7bAoU8i1Zo+yw55dKAXmW4IRfYJVGXs=; b=UL77iIMn90IlQkfBi2MOUzPYO3Cdxep9mYpYo6KxOa1ICP3GecuwJQwQGpoSLUf1PD 3aDWiTs51WMEbZ7MlKlVLSbIHF2Sqas6VW/gKav17Me8a8CWq3gz0KXYnuK0ZX2NcoxH AedJfPr571Le7Vo1KKisxr/BnzBh4NclhsTn25wfJ6r9IPNou8RaVKwXpgOM+iI/S8Tx uwBiIMZd2rdgiZ9qv40JcsmuonwH1wPaIg3ZO43yeGGioDXt9DsjStOhFG+c+ny69C/1 TN5Z7fYYGu0EOx6yvAbXCbSzWioKxKLhJUQ33hbv5krHlqLFIxWyZsqtqE5IU/1pgo+V oWBQ== X-Gm-Message-State: AMke39ntkM/WZOYu0MuFNrcTcOV6v9eA2owyKRcqNIvqNwEN0lNRrrPePuz1VLMvsZP2+vbVvqHFl8rr0J8s7Aj1 X-Received: by 10.237.36.208 with SMTP id u16mr1988631qtc.105.1486633599383; Thu, 09 Feb 2017 01:46:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.38.188 with HTTP; Thu, 9 Feb 2017 01:46:38 -0800 (PST) In-Reply-To: References: From: Taylor Brandstetter Date: Thu, 9 Feb 2017 01:46:38 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114104ce9a7e9d054815dbbb Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Can we use "a=bundle-only" in subsequent offers, instead of using a "shared address"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 09:46:42 -0000 --001a114104ce9a7e9d054815dbbb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, the advantage of using port zero + bundle-only in subsequent offers would be to eliminate the complexity of the "shared address" logic. So there wouldn't be much point in allowing it if we need shared addresses anyway. This relates to another issue Christer and I have been talking about. I had thought that this use case was supported: Offer (A, B, C, bundle-only): a=3Dgroup:BUNDLE A B C m=3Dvideo 10000 a=3Dmid:A m=3Dvideo 0 a=3Dmid:B a=3Dbundle-only m=3Dvideo 0 a=3Dmid:C a=3Dbundle-only Answer (rejects A, keeps B and C): a=3Dgroup:BUNDLE B C m=3Dvideo 0 a=3Dmid:A m=3Dvideo 20000 a=3Dmid:B m=3Dvideo 20000 a=3Dmid:C But I realized recently it isn't. The answerer can't reject "A" without rejecting the whole BUNDLE group. So, as long as that restriction exists, "shared addresses" have an advantage over using "a=3Dbundle-only". On Thu, Feb 9, 2017 at 12:55 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > In principle, sending port zero + bundle-only also in subsequent offers > should be ok. > > However, there always needs to be at least one m- line containing the > actual used port, and the answerer must not reject that m- line (no matte= r > whether it=E2=80=99s an initial or subsequent request). The advantage of = sending > the =E2=80=9Cshared address=E2=80=9D is that the answerer can reject any = m- line, as all > the other m- lines contain the used port. > > Regards, > > Christer > > > > From: mmusic on behalf of Taylor Brandstetter < > deadbeef@google.com> > Date: Thursday 9 February 2017 at 01:23 > To: "mmusic@ietf.org" > Subject: [MMUSIC] Can we use "a=3Dbundle-only" in subsequent offers, > instead of using a "shared address"? > > In an initial offer, if we want to communicate "this 'm=3D' section must = be > either bundled or rejected", that's accomplished with "a=3Dbundle-only": > > a=3Dgroup:BUNDLE A B > m=3Daudio 10000 ... > a=3Dmid:A > ... > m=3Dvideo 0 ... > a=3Dmid:B > a=3Dbundle-only > > In subsequent offers, this is accomplished by duplicating the IP > address/port (see section 8.3.3): > > a=3Dgroup:BUNDLE A B > m=3Daudio 10000 ... > a=3Dmid:A > ... > m=3Dvideo 10000 ... > a=3Dmid:B > > Is this initial vs. subsequent offer difference necessary? Both blobs of > SDP are communicating the same information, so the "shared address" rules > seem to only add complexity. > > Also, the approach of using a "shared address" to communicate something > isn't extensible to protocols that don't use an address for identificatio= n, > like ICE. We'd need to define additional rules for those cases, or allow > them specifically to use "a=3Dbundle-only" in subsequent offers. > --001a114104ce9a7e9d054815dbbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, the advantage of using port zero + bundle-only in su= bsequent offers would be to eliminate the complexity of the "shared ad= dress" logic. So there wouldn't be much point in allowing it if we= need shared addresses anyway.

This relates to another i= ssue Christer and I have been talking about. I had thought that this use ca= se was supported:

Offer (A, B, C, bundle-only):

= a=3Dgroup:BUNDLE A B C
m=3Dvideo 10000
a=3Dm= id:A
m=3Dvideo 0
a=3Dmid:B
= a=3Dbundle-only
m=3Dvideo 0
a=3Dmid:C
a=3Dbundle-only
Answer (rejects= A, keeps B and C):
a=3Dgroup:BUNDLE B = C
m=3Dvideo 0
a=3Dmid:A
m=3Dvideo 20000
a=3Dmid:B
m=3Dvideo 20000
a=3Dmid:C

But I realized rec= ently it isn't. The answerer can't reject "A" without rej= ecting the whole BUNDLE group. So, as long as that restriction exists, &quo= t;shared addresses" have an advantage over using "a=3Dbundle-only= ".


On Thu, Feb 9, 2017 at 12:55 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

In principle, sending port zero + bundle-only also in subsequent offer= s should be ok.=C2=A0

However, there always needs to be at least one m- line containing the = actual used port, and the answerer must not reject that m- line (no matter = whether it=E2=80=99s an initial or subsequent request). The advantage of se= nding the =E2=80=9Cshared address=E2=80=9D is that the answerer can reject any m- line, as all the other m- lines contain the used port.

Regards,

Christer



From: mmusic <mmusic-bounces@ietf.org> = on behalf of Taylor Brandstetter <deadbeef@google.com>
Date: Thursday 9 February 2017 at 0= 1:23
To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: [MMUSIC] Can we use "= a=3Dbundle-only" in subsequent offers, instead of using a "shared= address"?

In an initial offer, if we want to communicate "this 'm=3D= 9; section must be either bundled or rejected", that's accomplishe= d with "a=3Dbundle-only":

a=3Dgroup:BUNDLE A B
m=3Daudio 10000 ...
a=3Dmid:A
...
m=3Dvideo 0 ...
a=3Dmid:B
a=3Dbundle-only

In subsequent offers, this is accomplished by duplicating the IP addre= ss/port (see section 8.3.3):

a=3Dgroup:BUNDLE A B
m=3Daudio=C2= =A010000=C2=A0...
a=3Dmid:A
...
m=3Dvideo=C2=A010000=C2=A0...
a=3Dmid:B

Is this initial vs. subsequent offer difference necessary? Both blobs = of SDP are communicating the same information, so the "shared address&= quot; rules seem to only add complexity.

Also, the approach of using a "shared address" to communicat= e something isn't extensible to protocols that don't use an address= for identification, like ICE. We'd need to define additional rules for= those cases, or allow them specifically to use "a=3Dbundle-only" in subsequent offers.

--001a114104ce9a7e9d054815dbbb-- From nobody Thu Feb 9 02:46:47 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E00129979 for ; Thu, 9 Feb 2017 02:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 zO3_Xs0UnL7r for ; Thu, 9 Feb 2017 02:46:42 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3832C129973 for ; Thu, 9 Feb 2017 02:46:42 -0800 (PST) X-AuditID: c1b4fb3a-bb7cb98000005e23-c7-589c48902905 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 94.F7.24099.0984C985; Thu, 9 Feb 2017 11:46:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 11:46:39 +0100 From: Christer Holmberg To: Taylor Brandstetter Thread-Topic: [MMUSIC] Can we use "a=bundle-only" in subsequent offers, instead of using a "shared address"? Thread-Index: AQHSgmJtSJnKWRlz6kyWOb8c3XMxoKFgcSgA///sIACAADLggA== Date: Thu, 9 Feb 2017 10:46:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D4C2146317B1Cchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7lu4EjzkRBn1TVS0ur3jIajF1+WMW ByaPBZtKPZYs+ckUwBTFZZOSmpNZllqkb5fAlfF4ySfGgvWeFZOXrmVqYPxm18XIySEhYCLR tn0BexcjF4eQwDpGiRlvWlhAEkICixglOveldjFycLAJWEh0/9MGCYsI6Erc/LqQDcRmFpCX uLBkDROILSyQK9H26yY7RE2exM3OZ4wQtpPEtCMzwepZBFQkZuxZDjaeV8BaYnPveSaIVScZ Jc4dTQexOQUCJVa+uQNWwyggJvH9FMR8ZgFxiVtP5jNB3CwgsWTPeWYIW1Ti5eN/rCC2qICe xPLna5hBTpYQUJKYtjUNojVB4mT7RjaItYISJ2c+YZnAKDoLydRZSMpmISmDiBtIvD83nxnC 1pZYtvA1lK0vsfHLWUYI21pi/9xGFmQ1Cxg5VjGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIE RuDBLb+tdjAefO54iFGAg1GJh3dD1uwIIdbEsuLK3EOMEhzMSiK8J13nRAjxpiRWVqUW5ccX leakFh9ilOZgURLnNVt5P1xIID2xJDU7NbUgtQgmy8TBKdXAuGaN95RItVD7E4/zSiq095Rc W6iaW8G+sfKO8IEqlV1WMZbXpweWOK/Zny4c+Pz1R++bAhn9tkdvHT2+yOHoAu17T+YfitV4 WXztm+r6xtxffpuiIvwb3DOXvJZeFyO1OSNn88SQvx4avIX9e7aZOT87zOVUKaSecmBBK6e3 rMac6ONPzth5KrEUZyQaajEXFScCAL/f0ZW8AgAA Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Can we use "a=bundle-only" in subsequent offers, instead of using a "shared address"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 10:46:44 -0000 --_000_D4C2146317B1Cchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >Well, the advantage of using port zero + bundle-only in subsequent offers = would be to eliminate the complexity of the "shared address" logic. So ther= e wouldn't be much point in allowing it if we need shared addresses anyway. At the end of the day (this was also raised by Ekr some time ago), once the= bundle group has been created, it doesn=92t really matter what address:por= t you use in subsequent offers =96 as long as the actual BUNDLE address is = present in at least one m- line. The advantage of using the =93shared address=94 is that the answerer can re= ject any m- line in a subsequent offer, as the BUNDLE address will be prese= nt in the other m- lines. I don=92t know how often that happens in reality = =96 typically, if an endpoint wants to remove media, it will send an offer = itself in order to do so. Regards, Christer On Thu, Feb 9, 2017 at 12:55 AM, Christer Holmberg > wrote: Hi, In principle, sending port zero + bundle-only also in subsequent offers sho= uld be ok. However, there always needs to be at least one m- line containing the actua= l used port, and the answerer must not reject that m- line (no matter wheth= er it=92s an initial or subsequent request). The advantage of sending the = =93shared address=94 is that the answerer can reject any m- line, as all th= e other m- lines contain the used port. Regards, Christer From: mmusic > on b= ehalf of Taylor Brandstetter > Date: Thursday 9 February 2017 at 01:23 To: "mmusic@ietf.org" > Subject: [MMUSIC] Can we use "a=3Dbundle-only" in subsequent offers, instea= d of using a "shared address"? In an initial offer, if we want to communicate "this 'm=3D' section must be= either bundled or rejected", that's accomplished with "a=3Dbundle-only": a=3Dgroup:BUNDLE A B m=3Daudio 10000 ... a=3Dmid:A ... m=3Dvideo 0 ... a=3Dmid:B a=3Dbundle-only In subsequent offers, this is accomplished by duplicating the IP address/po= rt (see section 8.3.3): a=3Dgroup:BUNDLE A B m=3Daudio 10000 ... a=3Dmid:A ... m=3Dvideo 10000 ... a=3Dmid:B Is this initial vs. subsequent offer difference necessary? Both blobs of SD= P are communicating the same information, so the "shared address" rules see= m to only add complexity. Also, the approach of using a "shared address" to communicate something isn= 't extensible to protocols that don't use an address for identification, li= ke ICE. We'd need to define additional rules for those cases, or allow them= specifically to use "a=3Dbundle-only" in subsequent offers. --_000_D4C2146317B1Cchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9166250AF7C7024ABA2713EE25079FD9@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>Well, the advantage of using port zero + bundle-on= ly in subsequent offers would be to eliminate the complexity of the "s= hared address" logic. So there wouldn't be much point in allowing it i= f we need shared addresses anyway.

At the end of the day (this was also raised by Ekr some time ago), onc= e the bundle group has been created, it doesn=92t really matter what addres= s:port you use in subsequent offers =96 as long as the actual BUNDLE addres= s is present in at least one m- line.

The advantage of using the =93shared address=94 is that the answerer c= an reject any m- line in a subsequent offer, as the BUNDLE address will be = present in the other m- lines. I don=92t know how often that happens in rea= lity =96 typically, if an endpoint wants to remove media, it will send an offer itself in order to do so.

Regards,

Christer



On Thu, Feb 9, 2017 at 12:55 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

In principle, sending port zero + bundle-only also in subsequent o= ffers should be ok. 

However, there always needs to be at least one m- line containing the = actual used port, and the answerer must not reject that m- line (no matter = whether it=92s an initial or subsequent request). The advantage of sending = the =93shared address=94 is that the answerer can reject any m- line, as all the other m- lines contain the used port.

Regards,

Christer



From: mmusic <mmusic-bounces@ietf.org> = on behalf of Taylor Brandstetter <deadbeef@google.com>
Date: Thursday 9 February 2017 at 0= 1:23
To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: [MMUSIC] Can we use "= a=3Dbundle-only" in subsequent offers, instead of using a "shared= address"?

In an initial offer, if we want to communicate "this 'm=3D' secti= on must be either bundled or rejected", that's accomplished with "= ;a=3Dbundle-only":

a=3Dgroup:BUNDLE A B
m=3Daudio 10000 ...
a=3Dmid:A
...
m=3Dvideo 0 ...
a=3Dmid:B
a=3Dbundle-only

In subsequent offers, this is accomplished by duplicating the IP addre= ss/port (see section 8.3.3):

a=3Dgroup:BUNDLE A B
m=3Daudio&nbs= p;10000 ...
a=3Dmid:A
...
m=3Dvideo 10000 ...
a=3Dmid:B

Is this initial vs. subsequent offer difference necessary? Both blobs = of SDP are communicating the same information, so the "shared address&= quot; rules seem to only add complexity.

Also, the approach of using a "shared address" to communicat= e something isn't extensible to protocols that don't use an address for ide= ntification, like ICE. We'd need to define additional rules for those cases= , or allow them specifically to use "a=3Dbundle-only" in subsequent offers.

 --_000_D4C2146317B1Cchristerholmbergericssoncom_-- From nobody Thu Feb 9 14:14:30 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 830C4129411; Thu, 9 Feb 2017 14:14:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148667846953.8248.6325422942304056842.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 14:14:29 -0800 Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-sctp-sdp@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Ben Campbell's Yes on draft-ietf-mmusic-sctp-sdp-22: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 22:14:29 -0000 Ben Campbell has entered the following ballot position for draft-ietf-mmusic-sctp-sdp-22: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I hope to see a TSV-ART review before the telechat. If that brings up non-trivial issues, I may defer this. From nobody Thu Feb 9 19:27:35 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BB7129568; Thu, 9 Feb 2017 19:27:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148669725288.8138.2095744202497272272.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 19:27:32 -0800 Archived-At: Cc: draft-ietf-mmusic-sctp-sdp.all@ietf.org, ietf@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 03:27:33 -0000 Reviewer: Paul Wouters Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. [Note that I am not well versed in SCTP] This document defines SDP [RFC4566] protocol identifiers (proto values): 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism [RFC3264] for negotiating SCTP-over-DTLS associations. As this document only defines a method of signaling to use UDP/DTLS/SCTP or UDP/DTLS/SCTP, there are not specific Security Considerations for this document, and the Security Considerations correctly points to the documents that actually implement the UDP/DTLS/SCTP and TCP/DTLS/SCTP protocols. So from a security point of view, this document is Ready. I do have some generic concerns and questions I would like to see addressed: One general issue I have is with the specification of IANA values and punting some of its meaning. Let me quote an example: NOTE: This specification only defines the usage of the SDP 'max- message-size' attribute when associated with an m- line containing one of the following proto values: 'UDP/DTLS/SCTP' or 'TCP/DTLS/ SCTP'. Usage of the attribute with other proto values needs to be defined in a separate specification. This type of constraint is not clear and easilly displayed in an IANA registry if other values are later added to the table. This text is also an example of how througout the document, items are explicitely "this use is unspecified for now but other documents may change that". It would have been better to just simply and clearly state the current specified use, and let future documents handle updating this document appropriately. This language use makes a lot of decisions for implementers unclear as these decisions are punted forward in time without a reference to follow. Section 4.4.1 states: This specification creates an IANA registry for 'association-usage' values. I think this should be specified a little more clearly, similar to the IANA section specification itself. Something like: This specification creates the IANA 'association-usage' registry for SDP Attributes. Section 4.4.2: The table contains an error on the entries (UDP instead of TCP). I would personally change the port parameter value to just "port number for " or "UDP or TCP port number" Section 4.5: I'm unsure if ordering matters, so I am confused by the table ordering in media, proto, port, and the m= line example ordering media, port proto. I'm further confused by the table listing colon's, eg ":" and the m= line not using colons but spaces. And the following a= lines using colons again. Is this an error, or this is my lack of familiarity with the used protocols? Section 5.1: Therefore, if the attribute is not present, the associated m- line MUST be considered invalid. Is it obvious what one must done when the m- line is considered invalid? Section 5.2: Leading zeroes MUST NOT be used. What is the problem with leading zeros? What can go wrong when these are used? Should an implementor be warned about something specific? Section 6.1: An SCTP endpoint MUST NOT send a SCTP user message with a message size that is larger than the maximum size indicated by the peer, as it cannot be assumed that the peer would accept such message. While this tells an implementer what not to do, it does not tell the implementer what to do when this happens on the receiving end. It would be good to specify that here as well so that implementors will be reminded to think of this error handling case. a maximum message size value of zero, it indicates the SCTP endpoint will handle messages of any size, subject to memory capacity etc. I'm personally not a big fan of 0 meaning infinite, but if this is how other related specs are handling these values in this way, I can understand doing it here as well. For instance, not specifying a max-message-size seems more indicative of not having a max message size. But here that has been defined as meaning 64k. If this usage would be a precedent, I would recommend to not do this. If this is how these things are done in this world, then I guess stick to what has already been done in this space. The table entry in 6.2 lists an email contact for an IANA entry. Why does an IANA entry need someone's email address as contact? IANA entries normally only refer to the RFC's that define them, and people are expected to contact the working group or maybe one of the RFC authors for questions. But putting a name and email address entry here seems to convey some kind of "ownership" of the IANA entry which I think is the wrong thing to do. Section 6.3 As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of this specification, no mux rules are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values. Why is this out of scope? If there are good reasons not to do it, should it not be defined to MUST NOT? If it is out of scope only for now, then it seems that this document should in fact just specify it so people know how to do it. The way this is phrased seems to leave the thing hanging in midair, and implememters might end up doing different things. Section 7: NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP associations on top of a single DTLS association, the procedures in this specification only support the negotiation of a single SCTP association on top of any given DTLS association. And similar here. Setion 8: Similar issues with "the procedures" and with "is out of scope for this" Section 9.2: This specification does not define semantics for the SDP direction attributes [RFC4566]. Unless semantics of these attributes for an SCTP association usage have been defined, SDP direction attributes MUST be ignored if present. Why are these attributes not defined in this specification? If there are good reasons for it not to have been specified, why not change the language to clearly state these attributes here are invalid and MUST be ignored? If it is possibly these will be defined in the future (which the current text suggest might happen) perhaps that specification really belongs in this document. Nits: Through the document, there are paragraphs that start with "NOTE:". I think those can all be safely removed to increase the readability. Section 1: [I-D.ietf-tsvwg-sctp-dtls-encaps] This looks but is not a proper reference. (eg there is no link) When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values, the m- line fmt value, identifying the application-layer protocol, MUST be registered by IANA. This sentence does not parse. Section 6.1 Line wrapping 'TCP/DTLS/ SCTP' is best avoided. Section 9 Each can be established and closed without impacting others. Should that not be "each other" or "the others" (as opposed to "others" being other things far far away) Section 10.3 [I-D.ietf-mmusic-dtls-sdp] is not a proper reference with link. Section 12 I would rephrase "The text in the paragraph above" as these indirect references make the text harder to read. From nobody Thu Feb 9 19:32:53 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50296129656; Thu, 9 Feb 2017 19:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 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.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpVunRpmG5i2; Thu, 9 Feb 2017 19:32:41 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895E7129578; Thu, 9 Feb 2017 19:32:41 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vKL9g3zFlz3Dh; Fri, 10 Feb 2017 04:32:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1486697559; bh=41ItAJCBPu8Y4GNdSkUe64AugKBIen1ZNJ36Nn8rYY0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=slCOM8j0RCSCK0AZi/mUHPru6llcQWjcW7MumLmWS30EjA+6TzWxr8JKAXYT8owNm F06QC+162aALKyENVP3Tk99IaZUG1CHbAOd5fkw7sSTvFVKKR08WpvT95AqwVS3Q7/ 0Lazuo+v9qV+Pm5ymisq7Wx4PqdvzloHClqiwdwA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id NlL_y-MJBiUh; Fri, 10 Feb 2017 04:32:37 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 10 Feb 2017 04:32:37 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1C8292DEFE9; Thu, 9 Feb 2017 22:32:35 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1C8292DEFE9 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0473940267E6; Thu, 9 Feb 2017 22:32:34 -0500 (EST) Date: Thu, 9 Feb 2017 22:32:34 -0500 (EST) From: Paul Wouters To: Paul Wouters In-Reply-To: <148669725288.8138.2095744202497272272.idtracker@ietfa.amsl.com> Message-ID: References: <148669725288.8138.2095744202497272272.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: draft-ietf-mmusic-sctp-sdp.all@ietf.org, ietf@ietf.org, mmusic@ietf.org, secdir Subject: Re: [MMUSIC] [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 03:32:44 -0000 On Thu, 9 Feb 2017, Paul Wouters wrote: > Subject: [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 > > Reviewer: Paul Wouters > Review result: Has Issues ouch. The new secdir review submission using file upload really mangled the whitespace into something unreadable. I've included the original review txt file here inline to make the review readable. Perhaps Tero can investigate what's going on here? Paul I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. [Note that I am not well versed in SCTP] This document defines SDP [RFC4566] protocol identifiers (proto values): 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism [RFC3264] for negotiating SCTP-over-DTLS associations. As this document only defines a method of signaling to use UDP/DTLS/SCTP or UDP/DTLS/SCTP, there are not specific Security Considerations for this document, and the Security Considerations correctly points to the documents that actually implement the UDP/DTLS/SCTP and TCP/DTLS/SCTP protocols. So from a security point of view, this document is Ready. I do have some generic concerns and questions I would like to see addressed: One general issue I have is with the specification of IANA values and punting some of its meaning. Let me quote an example: NOTE: This specification only defines the usage of the SDP 'max- message-size' attribute when associated with an m- line containing one of the following proto values: 'UDP/DTLS/SCTP' or 'TCP/DTLS/ SCTP'. Usage of the attribute with other proto values needs to be defined in a separate specification. This type of constraint is not clear and easilly displayed in an IANA registry if other values are later added to the table. This text is also an example of how througout the document, items are explicitely "this use is unspecified for now but other documents may change that". It would have been better to just simply and clearly state the current specified use, and let future documents handle updating this document appropriately. This language use makes a lot of decisions for implementers unclear as these decisions are punted forward in time without a reference to follow. Section 4.4.1 states: This specification creates an IANA registry for 'association-usage' values. I think this should be specified a little more clearly, similar to the IANA section specification itself. Something like: This specification creates the IANA 'association-usage' registry for SDP Attributes. Section 4.4.2: The table contains an error on the entries (UDP instead of TCP). I would personally change the port parameter value to just "port number for " or "UDP or TCP port number" Section 4.5: I'm unsure if ordering matters, so I am confused by the table ordering in media, proto, port, and the m= line example ordering media, port proto. I'm further confused by the table listing colon's, eg ":" and the m= line not using colons but spaces. And the following a= lines using colons again. Is this an error, or this is my lack of familiarity with the used protocols? Section 5.1: Therefore, if the attribute is not present, the associated m- line MUST be considered invalid. Is it obvious what one must done when the m- line is considered invalid? Section 5.2: Leading zeroes MUST NOT be used. What is the problem with leading zeros? What can go wrong when these are used? Should an implementor be warned about something specific? Section 6.1: An SCTP endpoint MUST NOT send a SCTP user message with a message size that is larger than the maximum size indicated by the peer, as it cannot be assumed that the peer would accept such message. While this tells an implementer what not to do, it does not tell the implementer what to do when this happens on the receiving end. It would be good to specify that here as well so that implementors will be reminded to think of this error handling case. a maximum message size value of zero, it indicates the SCTP endpoint will handle messages of any size, subject to memory capacity etc. I'm personally not a big fan of 0 meaning infinite, but if this is how other related specs are handling these values in this way, I can understand doing it here as well. For instance, not specifying a max-message-size seems more indicative of not having a max message size. But here that has been defined as meaning 64k. If this usage would be a precedent, I would recommend to not do this. If this is how these things are done in this world, then I guess stick to what has already been done in this space. The table entry in 6.2 lists an email contact for an IANA entry. Why does an IANA entry need someone's email address as contact? IANA entries normally only refer to the RFC's that define them, and people are expected to contact the working group or maybe one of the RFC authors for questions. But putting a name and email address entry here seems to convey some kind of "ownership" of the IANA entry which I think is the wrong thing to do. Section 6.3 As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of this specification, no mux rules are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values. Why is this out of scope? If there are good reasons not to do it, should it not be defined to MUST NOT? If it is out of scope only for now, then it seems that this document should in fact just specify it so people know how to do it. The way this is phrased seems to leave the thing hanging in midair, and implememters might end up doing different things. Section 7: NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP associations on top of a single DTLS association, the procedures in this specification only support the negotiation of a single SCTP association on top of any given DTLS association. And similar here. Setion 8: Similar issues with "the procedures" and with "is out of scope for this" Section 9.2: This specification does not define semantics for the SDP direction attributes [RFC4566]. Unless semantics of these attributes for an SCTP association usage have been defined, SDP direction attributes MUST be ignored if present. Why are these attributes not defined in this specification? If there are good reasons for it not to have been specified, why not change the language to clearly state these attributes here are invalid and MUST be ignored? If it is possibly these will be defined in the future (which the current text suggest might happen) perhaps that specification really belongs in this document. Nits: Through the document, there are paragraphs that start with "NOTE:". I think those can all be safely removed to increase the readability. Section 1: [I-D.ietf-tsvwg-sctp-dtls-encaps] This looks but is not a proper reference. (eg there is no link) When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values, the m- line fmt value, identifying the application-layer protocol, MUST be registered by IANA. This sentence does not parse. Section 6.1 Line wrapping 'TCP/DTLS/ SCTP' is best avoided. Section 9 Each can be established and closed without impacting others. Should that not be "each other" or "the others" (as opposed to "others" being other things far far away) Section 10.3 [I-D.ietf-mmusic-dtls-sdp] is not a proper reference with link. Section 12 I would rephrase "The text in the paragraph above" as these indirect references make the text harder to read. From nobody Thu Feb 9 23:40:34 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EB512A028; Thu, 9 Feb 2017 23:40:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148671243349.8176.18389003902877344350.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 23:40:33 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-23.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 07:40:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport. Authors : Christer Holmberg Roman Shpount Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-23.txt Pages : 25 Date : 2017-02-09 Abstract: The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism for negotiating SCTP-over-DTLS associations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-23 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 10 03:53:11 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52DB129590 for ; Fri, 10 Feb 2017 03:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1Qig3-wSoxX for ; Fri, 10 Feb 2017 03:53:08 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50EB1289C4 for ; Fri, 10 Feb 2017 03:53:07 -0800 (PST) X-AuditID: c1b4fb3a-bb7cb98000005e23-0f-589da9a154f6 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 07.87.24099.1A9AD985; Fri, 10 Feb 2017 12:53:05 +0100 (CET) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 10 Feb 2017 12:52:05 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UjK7SXCidIPaGYdW7Ym0Icb3ADk8kctKMlAfwtCrPHE=; b=H93P0U1sxD5APJEIR9NZf1YktWlyhxIhYBBRP5LiZ3MlSjviT8eUN6NuIhSfQp9W3VzyWZPAAY/sEit+86KHJYJYBDukpg5i90N2NYu/C2HIuvOi0u0fsvRzo0O9atbXF//+AtYuypVg93feTO1hM74shSzhsfr/zWQ6rACyNGc= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2579.eurprd07.prod.outlook.com (10.173.92.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Fri, 10 Feb 2017 11:52:04 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 11:52:04 +0000 From: Bo Burman To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11 Thread-Index: AQHScDKg32cCmWLi20qh646JJAxdrqFA+e+AgAERfwCAFYlKAA== Date: Fri, 10 Feb 2017 11:52:04 +0000 Message-ID: References: <47cd76a1-e767-9bd4-9c96-047688751866@nteczone.com> <653b4a88-a6a6-35d4-29f3-8cbe2665d08c@comcast.net> In-Reply-To: <653b4a88-a6a6-35d4-29f3-8cbe2665d08c@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com; x-originating-ip: [192.176.1.81] x-ms-office365-filtering-correlation-id: d338f91a-4ba3-40b1-7c07-08d451ab3b7a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2579; x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2579; 7:ULZE8eahWfdvF1/AuvMZApctCgpI0zcLTl6wRgi6IBUsDF+/RETY6bsUIeSZbfG0IVXwI7u5zm8Rds2tiRZw2knpzkAC35O5MRQK0nVdTdBm+05x41io4VhNEr1RDM0Fl3P76Vc+6uvDkcjcFGEO92/tpN2RDjBTg6JD6T4JEnuZeZYzDclwxjBDEteSP5RjfLQZOLMXbW2lBb/bR7YSmwQuU3OeoEWJERAxVSib4FHs4SQQf8T7P56wq6Mbgni0RRvEvKueWrMxmLuDP9KvdD+o0OUttUnSiEGfLnvDiizzJoy3PA5nzopnRMxRiq+K0SvMxRTDvEUdYzGnA3UW5Iszyc3E/nsLt/8bqUs6xfiwlptQFp7K6cwOxUGyqeohy1tn6Q66GJZKxz6woY9IeYCE2thrjs9betae1kLX6bTzks20iVhlCzKn67Q0s+KJvizKl7PdVgk/R4sDhcAbxmMN8WT/ZE/ag7kPCjmD3s9v/OEweAqqhBYzMn8NnIPSSTulYOfch9ymp6wTGws27g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(35073007944872); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123558025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:AM5PR0701MB2579; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2579; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377454003)(13464003)(199003)(24454002)(189002)(54356999)(50986999)(105586002)(2351001)(106356001)(66066001)(230783001)(93886004)(53936002)(55016002)(81166006)(106116001)(1730700003)(81156014)(8936002)(5660300001)(3280700002)(99286003)(101416001)(6306002)(110136004)(38730400002)(3660700001)(53546003)(2950100002)(6246003)(9686003)(229853002)(68736007)(6506006)(76176999)(5640700003)(25786008)(6436002)(77096006)(189998001)(33656002)(122556002)(450100001)(97736004)(6916009)(7696004)(6116002)(2501003)(7736002)(2906002)(74316002)(3846002)(2900100001)(92566002)(86362001)(102836003)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2579; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 11:52:04.3861 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2579 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUyM2K7ou7ClXMjDF5dM7WYuvwxiwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mn5+2MlecF+xYtX92gbGm1JdjJwcEgImEj9erWLqYuTiEBJY xyjR0LmDHcI5wSjRf6WfFcRhEehllmhc/5oRIjOdSWLR8ldMcGV3dt1hBhnGJqAhMX/HXUYQ W0RAXeLr3h6gOAeHsECgxJGt8RDhIInZ36axQthOEncWHwNrZRFQlfi5oAvM5hVIkPjT/Ahq fgOTxParXSwgCU4Be4ndZ9cwgdiMAmIS309B2MwC4hK3nsxngnhIQGLJnvPMELaoxMvH/1gh 6iMlJk88yw4RV5A4NmMlC4TtK/Hx6xqoen+J7+2tLCCLJQTOsUj8edUCNTRfYuGclVBFVhIP 171ihCiaxyQx+9YfqKkyEm8vfmWFSKxlk5i54T/YCiGBVInla1vBwSIsICVx90onlC0j8eLO XtYJjJqzkHwBYetILNj9iQ3C1pZYtvA18yxw0AhKnJz5hGUBI8sqRtHi1OLi3HQjI73Uoszk 4uL8PL281JJNjMA0cXDLb6sdjAefOx5iFOBgVOLh/dA8J0KINbGsuDL3EKMEB7OSCG/20rkR QrwpiZVVqUX58UWlOanFhxilOViUxHnNVt4PFxJITyxJzU5NLUgtgskycXBKNTAu8+7KenDN L+DZ4xs2l63NTm1Y5iE4d+GL1tx7Ls8EWC5GzbI/qGbb2/1cRDc9s1mno//mn83XzHQi3fWF zaeUMPbq3ZT7vF56xxGReMk6/z1LHy3MfO+q/WLlhdVLGQN3aLCeONmzUDWwtvF4MdORjevu Ghz74HBz9Ubda/ViXwLXzNg77ymnEktxRqKhFnNRcSIAF+7ccw8DAAA= Archived-At: Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 11:53:09 -0000 Hi, I'm wondering if 4566bis has to be a normative reference in this document? = While the registrations of the new attributes use the 4566bis template that= includes the mux category, I don't think it necessarily motivates having 4= 566bis as normative reference, but informative should be sufficient. The do= cument also normatively references -mux-attributes for the chosen mux categ= ory "SPECIAL", which seems OK to me. /Bo (as individual) > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: den 21 januari 2017 00:36 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdp= neg-11 >=20 > On 1/20/17 2:16 AM, Christian Groves wrote: > > Hello Paul, > > > > Please see below. > > > > Regards, Christian > > > > On 17/01/2017 6:56 AM, Paul Kyzivat wrote: > >> I've followed this document closely throughout its development. > >> In preparation for this message I reviewed the document again. I > >> found some things that need to be addressed: > >> > >> 1) MAJOR: Section 5.1.1.3 and various other places: > >> > >> I can find nothing here or elsewhere in the document that says > >> whether the the stream id in an offer is the id on which the offerer > >> will receive, or the ID on which it will send. Of course this is > >> irrelevant if both ends agree to use the same id, but that isn't requi= red. > >> > >> For this to interact properly with attributes for individual streams > >> (in dcsa) I think it will be necessary for this to be consistent with > >> the say SDP negotiates media sections - namely that the SDP in an > >> offer identifies where the offerer wants to *receive* the media. > >> > >> It will probably require changes in a variety of places to get this > >> sorted out. > > > > [CNG] There is some guidance in clause 5.2.1 around managing stream > > identifiers. Utilising the same Stream ID is required when supporting > > WebRTC datachannel (see clause 6.4/draft-ietf-rtcweb-data-channel-13). > > Clause 5.1.1 / ietf-mmusic-data-channel-sdpneg vaguely mentions that > > the opposite datachannels have the same set of attributes. SCTP stream > > identifier being one of those. >=20 > I was taking that into account, and yet found it incomplete. >=20 > However, upon rereading, I did find some language in section 5.2.3 that h= elps clarify this: >=20 > The peer receiving such an SDP offer performs the following: > ... > o For accepted data channels, it creates peer instances for the data > channels with the agent using the channel parameters described in > the SDP offer. Note that the agent is asked to create data > channels with SCTP stream identifiers contained in the SDP offer > if the SDP offer is accepted. >=20 > The "Note" is what resolves any ambiguity. But it is written as if it was= an implication that is simply being noted, rather > than being a normative statement. >=20 > So I propose that it be revised as follows: >=20 > o For accepted data channels, the agent MUST create peer instances > for the data channels using the SCTP stream identifiers and > channel parameters contained in the SDP offer. >=20 > Thanks, > Paul >=20 > >> 2) MINOR: Section 5.1.1 says: > >> > >> The intention in exchanging these attributes is to create, on two > >> peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched > >> pairs of oppositely directed data channels having the same set of > >> attributes. It is assumed that the data channel properties > >> (reliable/partially reliable, ordered/unordered) are suitable per t= he > >> subprotocol transport requirements. > >> > >> In this, "matched pairs of oppositely directed data channels" is > >> improper terminology. Each channel *is* a matched pair, of oppositely > >> directed SCTP streams. > > [CNG] Yes I agree. > >> ..snip.. > > > > _______________________________________________ > > 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 Fri Feb 10 06:08:44 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA9512997D for ; Fri, 10 Feb 2017 06:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgqhLjEUH9CZ for ; Fri, 10 Feb 2017 06:08:42 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A33129850 for ; Fri, 10 Feb 2017 06:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2914; q=dns/txt; s=iport; t=1486735722; x=1487945322; h=to:from:subject:message-id:date:mime-version; bh=w7QxuTZJodFKSG1jGEe7M8hi2eUlEXp0V20f5l0RlRE=; b=bJbL6p8uCdeMSdQ/hW7AGOXYlWkZANgiiS23Rlm1bpG3TeZYoAxxB/+l RNrW/5tmRXuZ4ACY9EoXZAs4Ggrw/dNEv/3oVWx6mPMDcUE3CGiF9EDdZ D4yW92UvrVc1AjHeNaOTHuR4aUBwRhaEm+ynMWhOoT098syChnAdFNbvi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DGBAAdyZ1Y/5hdJa1eHAEBBAEBCgEBg?= =?us-ascii?q?1JkJ4Q4igiiFoMdgg+CDYkaPxgBAgEBAQEBAQFiKIUTSyQGAT0CXw0IAQGJZw2?= =?us-ascii?q?SF41NkAGCJSuLKQEBCAEBAQEkhkyCBYpEgl8Fhl6IZX6LMY0yhGKBe4UXgy2GR?= =?us-ascii?q?pMVHzg6RDIdFTyGYCKKUwEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,141,1484006400"; d="scan'208,217";a="210794261" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2017 14:08:30 +0000 Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v1AE8UVD017971 for ; Fri, 10 Feb 2017 14:08:30 GMT To: mmusic From: Flemming Andreasen Message-ID: <977409c0-d622-9f5d-30b5-aee54240e01e@cisco.com> Date: Fri, 10 Feb 2017 09:08:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------1563B2A04B83101BFEEB81F9" Archived-At: Subject: [MMUSIC] MMUSIC Agenda Requests for IETF 98 (Chicago) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 14:08:44 -0000 This is a multi-part message in MIME format. --------------1563B2A04B83101BFEEB81F9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi IETF98 in Chicago will be here before you know it, and the MMUSIC WG has asked for a 2 hour meeting this time. Draft submissions and WG agendas are both due in ~1 month, so now would be a good time to start preparing and let the chairs know if you have anything you would like to get on the agenda. As usual, we want to ensure we take advantage of our meeting time in a productive manner. This means that we want presenters to come prepared to discuss open issues that have already been raised on the mailing list and ideally received some feedback. Priority will be given to drafts that gather attention and discussion on the mailing list prior to the meeting. We also aim to give adequate time for drafts holding up progress elsewhere. To facilitate this, please specify in your agenda request e-mail the following: - name of the draft and the presenter - how much time you would like - outline of major open issues; what needs to be discussed at the meeting - dependencies to your draft (if any) Thanks Bo & Flemming (MMUSIC co-chairs) --------------1563B2A04B83101BFEEB81F9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi

IETF98 in Chicago will be here before you know it, and the MMUSIC WG has asked for a 2 hour meeting this time. Draft submissions and WG agendas are both due in ~1 month, so now would be a good time to start preparing and let the chairs know if you have anything you would like to get on the agenda.

As usual, we want to ensure we take advantage of our meeting time in a productive manner. This means that we want presenters to come prepared to discuss open issues that have already been raised on the mailing list and ideally received some feedback. Priority will be given to drafts that gather attention and discussion on the mailing list prior to the meeting. We also aim to give adequate time for drafts holding up progress elsewhere. To facilitate this, please specify in your agenda request e-mail the following:

- name of the draft and the presenter
- how much time you would like
- outline of major open issues; what needs to be discussed at the meeting
- dependencies to your draft (if any)
 

Thanks

     Bo & Flemming (MMUSIC co-chairs)


--------------1563B2A04B83101BFEEB81F9-- From nobody Fri Feb 10 06:15:39 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22C0129965; Fri, 10 Feb 2017 06:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 j6RUWTahSP87; Fri, 10 Feb 2017 06:15:29 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3B812988A; Fri, 10 Feb 2017 06:15:28 -0800 (PST) X-AuditID: c1b4fb2d-2a63298000001743-e6-589dcaff6922 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id E3.7D.05955.FFACD985; Fri, 10 Feb 2017 15:15:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Fri, 10 Feb 2017 15:15:26 +0100 From: Christer Holmberg To: Paul Wouters , Paul Wouters Thread-Topic: [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 Thread-Index: AQHSg02fz09JgsaxQEyJwWweq6l2mKFhhUMAgADVvIA= Date: Fri, 10 Feb 2017 14:15:25 +0000 Message-ID: References: <148669725288.8138.2095744202497272272.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="Windows-1252" Content-ID: <055BCFB29D6093489DCA3E1D4B0D75A4@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM2K7tO7/U3MjDF6+FbXY1L+JxeLZxvks FlOXP2axeH/rEpPFyX33mCw+LHzI4sDmsWTJTyaP7/OYPN7vu8oWwBzFZZOSmpNZllqkb5fA lXFqW1LBRf+KW/dOMzUwvrHrYuTkkBAwkdj47Dk7iC0ksI5R4uhili5GLiB7MaPEh/e3gRIc HGwCFhLd/7RBakQEXCX27r0BVsMssJtR4tmR/WA1wgK2Eqe/KUDU2Ek0z/7ABhIWEbCSaJtp DBJmEVCVaGnqZAGxeQWsJaadf8cMsaqZUWLyheNgYzgFHCW6tuSA1DAKiEl8P7WGCcRmFhCX uPVkPhPEyQISS/acZ4awRSVePv7HCmKLCuhJLH++BiquKPHx1T5GiF4Diffn5jND2NYSa3q3 QtnaEssWvmaGuEdQ4uTMJywTGMVnIVk3C0n7LCTts5C0z0LSvoCRdRWjaHFqcXFuupGxXmpR ZnJxcX6eXl5qySZGYGQe3PJbdwfj6teOhxgFOBiVeHg/NM+JEGJNLCuuzD3EKMHBrCTCO+HQ 3Agh3pTEyqrUovz4otKc1OJDjNIcLErivGYr74cLCaQnlqRmp6YWpBbBZJk4OKUaGJ0u14dN ND6qEuCYlvO5ailXp83By51hKZEtT5a0SHWt4Tx13/1z9c/frH4p387kJ67RX/M84m/Lk4lv mN5IxynNKkva6DbRchL7RomU7jT/6ZdYXnx83qn4pviTuW/Ox6OuytMy/r81fS3a/0uy8ftW ty+/oxsaWdcuS9JaU1z35MGnBRH8DUosxRmJhlrMRcWJAE9Mpl7IAgAA Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" , secdir Subject: Re: [MMUSIC] [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 14:15:32 -0000 Hi Paul, Thanks for your review! Please see inline. ... >This document defines SDP [RFC4566] protocol identifiers (proto values): >'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies >how to use the new proto values with the SDP Offer/Answer mechanism >[RFC3264] for negotiating SCTP-over-DTLS associations. > >As this document only defines a method of signaling to use UDP/DTLS/SCTP >or UDP/DTLS/SCTP, there are not specific Security Considerations for this >document, and the Security Considerations correctly points to the >documents >that actually implement the UDP/DTLS/SCTP and TCP/DTLS/SCTP protocols. > >So from a security point of view, this document is Ready. Thanks! ---- >I do have some generic concerns and questions I would like to see >addressed: > >One general issue I have is with the specification of IANA values and >punting >some of its meaning. Let me quote an example: > > NOTE: This specification only defines the usage of the SDP 'max- > message-size' attribute when associated with an m- line containing > one of the following proto values: 'UDP/DTLS/SCTP' or 'TCP/DTLS/ > SCTP'. Usage of the attribute with other proto values needs to be > defined in a separate specification. > >This type of constraint is not clear and easilly displayed in an IANA >registry if >other values are later added to the table. This text is also an example >of how >througout the document, items are explicitely "this use is unspecified >for now >but other documents may change that". It would have been better to just >simply >and clearly state the current specified use, and let future documents >handle >updating this document appropriately. This language use makes a lot of >decisions >for implementers unclear as these decisions are punted forward in time >without >a reference to follow. I think the idea is that if someone wants to define the usage for other proto values he/she does not need to update THIS specification, as it already allows it. ---- >Section 4.4.1 states: > > This specification creates an IANA registry for 'association-usage' >values. > >I think this should be specified a little more clearly, similar to the >IANA section >specification itself. Something like: > > This specification creates the IANA 'association-usage' registry for >SDP Attributes. We are discussing this with IANA, so the text will be aligned. ---- >Section 4.4.2: > >The table contains an error on the entries (UDP instead of TCP). Correct. That was noted also by the AD. ---- > I would personally change the port parameter value to just "port number >for " or "UDP or TCP port number" People wanted to have the proto values explicitly stated, so I=B9d like to keep them. ---- >Section 4.5: > >I'm unsure if ordering matters, so I am confused by the table ordering in >media, proto, port, >and the m=3D line example ordering media, port proto. I obivously can=B9t change the order in the m=3D line, but I can change the order of and in the table, if you think that make things more clear. ---- >I'm further confused by the table listing colon's, eg ":" and the >m=3D line not >using colons but spaces. And the following a=3D lines using colons again. >Is this an error, >or this is my lack of familiarity with the used protocols? I honestly have no idea why the colones are there (probably a copy/paste error). I can remove them. ---- >Section 5.1: > > Therefore, if the attribute is not present, the associated m- line MUST >be considered invalid. > >Is it obvious what one must done when the m- line is considered invalid? I could add =B3, and MUST NOT be used to establish an SCTP-over-DTLS association." ---- >Section 5.2: > > Leading zeroes MUST NOT be used. > >What is the problem with leading zeros? What can go wrong when these are >used? Should >an implementor be warned about something specific? I don=B9t know. The same statement exists for a number of SDP attributes, but I didn=B9t find any justification. ---- >Section 6.1: > > An SCTP endpoint MUST NOT send a SCTP user message with a message > size that is larger than the maximum size indicated by the peer, as > it cannot be assumed that the peer would accept such message. > >While this tells an implementer what not to do, it does not tell the >implementer >what to do when this happens on the receiving end. It would be good to >specify >that here as well so that implementors will be reminded to think of this >error >handling case. I am not sure whether it=B9s within the scope of this document to say what SCTP endpoints do if they receive SCTP user messages that are too big for them to handle. > a maximum message size value of zero, it indicates the SCTP endpoint >will handle > messages of any size, subject to memory capacity etc. > >I'm personally not a big fan of 0 meaning infinite, but if this is how >other related >specs are handling these values in this way, I can understand doing it >here as well. >For instance, not specifying a max-message-size seems more indicative of >not having >a max message size. But here that has been defined as meaning 64k. If >this usage >would be a precedent, I would recommend to not do this. If this is how >these things >are done in this world, then I guess stick to what has already been done >in this space. I don=B9t know how things are normally done, because the only other SDP attribute I can think of providing similar information is =8Cmax-size=B9 (R= FC 4975), but it does not define a default value, nor a infinite value. >The table entry in 6.2 lists an email contact for an IANA entry. Why does >an IANA >entry need someone's email address as contact? IANA entries normally only >refer to >the RFC's that define them, and people are expected to contact the >working group >or maybe one of the RFC authors for questions. But putting a name and >email address >entry here seems to convey some kind of "ownership" of the IANA entry >which I think >is the wrong thing to do. You=B9ll have to ask IANA about that :) The e-mail address is within the template that has to be filled. Keep in mind, though, that IANA entries are not always defined in RFCs. For example, a number of registrations have been provided by 3GPP. ---- >Section 6.3 > > As the usage of multiple SCTP associations on top of a single DTLS > association is outside the scope of this specification, no mux rules > are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto > values. > >Why is this out of scope? If there are good reasons not to do it, should >it not >be defined to MUST NOT? If it is out of scope only for now, then it seems >that >this document should in fact just specify it so people know how to do it. >The >way this is phrased seems to leave the thing hanging in midair, and >implememters >might end up doing different things. In order to allow multiple SCTP associations, you would have to be able to provide multiple SCTP ports, and somehow associate those with each association. We decided not to do that. But, I don=B9t think we want to forbid people from establishing multiple SCTP associations - this spec just doesn=B9t support using SDP offer/answer for negotiating multiple associations. ---- >Section 7: > > NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP > associations on top of a single DTLS association, the procedures in > this specification only support the negotiation of a single SCTP > association on top of any given DTLS association. > >And similar here. See above. ---- >Setion 8: > >Similar issues with "the procedures" and with "is out of scope for this" > >Section 9.2: > > This specification does not define semantics for the SDP direction > attributes [RFC4566]. Unless semantics of these attributes for an > SCTP association usage have been defined, SDP direction attributes > MUST be ignored if present. > >Why are these attributes not defined in this specification? If there are >good >reasons for it not to have been specified, why not change the language to >clearly state these attributes here are invalid and MUST be ignored? If it >is possibly these will be defined in the future (which the current text >suggest might happen) perhaps that specification really belongs in this >document. The direction attributes are not used for transports. They are used for =B3applications=B2, e.g, RTP. But, as nobody has indicated any interest of defining RTP-over-SCTP-over-DTLS, there is no idea to define how the direction attributes would be used. ---- Nits: >Through the document, there are paragraphs that start with "NOTE:". I >think >those can all be safely removed to increase the readability. Ok, I=B9ll look into that. ---- >Section 1: > > [I-D.ietf-tsvwg-sctp-dtls-encaps] > >This looks but is not a proper reference. (eg there is no link) > > When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values, the m- > line fmt value, identifying the application-layer protocol, MUST be > registered by IANA. > >This sentence does not parse. > > >Section 6.1 > >Line wrapping 'TCP/DTLS/ > SCTP' is best avoided. I=B9ll fix that. ---- >Section 9 > > Each can be established and closed without impacting others. > >Should that not be "each other" or "the others" (as opposed to "others" >being other things far far away) I=B9ll change to =B3the others=B2. ---- >Section 10.3 > >[I-D.ietf-mmusic-dtls-sdp] is not a proper reference with link. I=B9ll look into that. ---- >Section 12 > >I would rephrase "The text in the paragraph above" as these indirect >references make the text harder >to read. I could remove the first sentence, and keep the second: "If ICE is not used, the proto value MUST always reflect the transport protocol used at any given time." Regards, Christer From nobody Fri Feb 10 13:03:18 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E80F2129BDD; Fri, 10 Feb 2017 13:03:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Stiemerling To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148676059794.29305.2115176925259048270.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2017 13:03:17 -0800 Archived-At: Cc: draft-ietf-mmusic-sctp-sdp.all@ietf.org, ietf@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-23 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 21:03:18 -0000 Reviewer: Martin Stiemerling Review result: Ready Hi there, I have reviewed draft-ietf-mmusic-sctp-sdp-23 as part of the TSV Area Review. Short summary: This draft is ready. Thank you for the clearly written draft. Martin From nobody Fri Feb 10 13:14:21 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0D3129C1A for ; Fri, 10 Feb 2017 13:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBqtxo7xGVSw for ; Fri, 10 Feb 2017 13:14:14 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA2B129C16 for ; Fri, 10 Feb 2017 13:14:14 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-09v.sys.comcast.net with SMTP id cIW0c8KnxImZIcIWDcnS2I; Fri, 10 Feb 2017 21:14:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1486761253; bh=DwWWjcs+g0wSGoVjpU7K9oCXSDpCznjfD8sB55d7Q/M=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=myAEJ2CD/bqEFhBJt/LjsLjqPeI3x+0yFBoe4k0mrKM2Yc0aJQohJizBtgUEiHNTi FMxM8HBI7skJF+gh0bCKOkN83xYu3evyGtzocEW3Tw+IzhYovEZRfz10jhbWP1J0kA 4ANdsIoce6VAYbLEPnt2v6DJO4QDUx40jmoley68S1e34w3GyJnDq+4a8g/60ZZq9j q4/Cdogfr2ht7V+X3VXSLDPbYwq8LxC1E5vFbEk/ZgYqIuWTmNrqwFHZbq6VL4veTF 3bJ0J9eaBAkslI/Zdztr56NjgYj4IahXxE1crgZHzBf5uX9qzE5nhZOAbdIgPn40H5 iNh9rTHskAfaA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-09v.sys.comcast.net with SMTP id cIWCcerjhifKAcIWCcOJ33; Fri, 10 Feb 2017 21:14:13 +0000 To: mmusic@ietf.org References: <47cd76a1-e767-9bd4-9c96-047688751866@nteczone.com> <653b4a88-a6a6-35d4-29f3-8cbe2665d08c@comcast.net> From: Paul Kyzivat Message-ID: <7da7302f-957f-4568-fee8-99a8d70a61a6@comcast.net> Date: Fri, 10 Feb 2017 16:14:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKYnbFzyAcx98eQWyDtYklUG6WslxqzDTpOswiMmXebKRmN0wRJY2qDIelTYpmE32gUFKER/Dq/wV8vojl4J5p57HhVbLRp+hBx/iPli36S6I5tOaWI8 j3+N1MH1P+xSPd1jZ0QXGsJMSgkp8TxCytfW8qCmP+ZU/YR/1diOnmg9twtiX0jdHhWpr9dgGIYVeA== Archived-At: Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 21:14:18 -0000 On 2/10/17 6:52 AM, Bo Burman wrote: > Hi, > > I'm wondering if 4566bis has to be a normative reference in this document? While the registrations of the new attributes use the 4566bis template that includes the mux category, I don't think it necessarily motivates having 4566bis as normative reference, but informative should be sufficient. The document also normatively references -mux-attributes for the chosen mux category "SPECIAL", which seems OK to me. I don't think so. Thanks, Paul > /Bo (as individual) > >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: den 21 januari 2017 00:36 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11 >> >> On 1/20/17 2:16 AM, Christian Groves wrote: >>> Hello Paul, >>> >>> Please see below. >>> >>> Regards, Christian >>> >>> On 17/01/2017 6:56 AM, Paul Kyzivat wrote: >>>> I've followed this document closely throughout its development. >>>> In preparation for this message I reviewed the document again. I >>>> found some things that need to be addressed: >>>> >>>> 1) MAJOR: Section 5.1.1.3 and various other places: >>>> >>>> I can find nothing here or elsewhere in the document that says >>>> whether the the stream id in an offer is the id on which the offerer >>>> will receive, or the ID on which it will send. Of course this is >>>> irrelevant if both ends agree to use the same id, but that isn't required. >>>> >>>> For this to interact properly with attributes for individual streams >>>> (in dcsa) I think it will be necessary for this to be consistent with >>>> the say SDP negotiates media sections - namely that the SDP in an >>>> offer identifies where the offerer wants to *receive* the media. >>>> >>>> It will probably require changes in a variety of places to get this >>>> sorted out. >>> >>> [CNG] There is some guidance in clause 5.2.1 around managing stream >>> identifiers. Utilising the same Stream ID is required when supporting >>> WebRTC datachannel (see clause 6.4/draft-ietf-rtcweb-data-channel-13). >>> Clause 5.1.1 / ietf-mmusic-data-channel-sdpneg vaguely mentions that >>> the opposite datachannels have the same set of attributes. SCTP stream >>> identifier being one of those. >> >> I was taking that into account, and yet found it incomplete. >> >> However, upon rereading, I did find some language in section 5.2.3 that helps clarify this: >> >> The peer receiving such an SDP offer performs the following: >> ... >> o For accepted data channels, it creates peer instances for the data >> channels with the agent using the channel parameters described in >> the SDP offer. Note that the agent is asked to create data >> channels with SCTP stream identifiers contained in the SDP offer >> if the SDP offer is accepted. >> >> The "Note" is what resolves any ambiguity. But it is written as if it was an implication that is simply being noted, rather >> than being a normative statement. >> >> So I propose that it be revised as follows: >> >> o For accepted data channels, the agent MUST create peer instances >> for the data channels using the SCTP stream identifiers and >> channel parameters contained in the SDP offer. >> >> Thanks, >> Paul >> >>>> 2) MINOR: Section 5.1.1 says: >>>> >>>> The intention in exchanging these attributes is to create, on two >>>> peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched >>>> pairs of oppositely directed data channels having the same set of >>>> attributes. It is assumed that the data channel properties >>>> (reliable/partially reliable, ordered/unordered) are suitable per the >>>> subprotocol transport requirements. >>>> >>>> In this, "matched pairs of oppositely directed data channels" is >>>> improper terminology. Each channel *is* a matched pair, of oppositely >>>> directed SCTP streams. >>> [CNG] Yes I agree. >>>> ..snip.. >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri Feb 10 13:34:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A2B12946B; Fri, 10 Feb 2017 13:34:41 -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, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=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 ywz9Lz0wpR2r; Fri, 10 Feb 2017 13:34:41 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDF1126BF6; Fri, 10 Feb 2017 13:26:37 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v1ALQY1U053101 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 10 Feb 2017 15:26:36 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Martin Stiemerling" Date: Fri, 10 Feb 2017 15:26:33 -0600 Message-ID: <5D2D3F1D-9D7A-4C20-B8D5-E5F118F07DEE@nostrum.com> In-Reply-To: <148676059794.29305.2115176925259048270.idtracker@ietfa.amsl.com> References: <148676059794.29305.2115176925259048270.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5344) Archived-At: Cc: tsv-art@ietf.org, draft-ietf-mmusic-sctp-sdp.all@ietf.org, ietf@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-23 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 21:34:42 -0000 Thanks, Martin! Ben. On 10 Feb 2017, at 15:03, Martin Stiemerling wrote: > Reviewer: Martin Stiemerling > Review result: Ready > > Hi there, > > I have reviewed draft-ietf-mmusic-sctp-sdp-23 as part of the TSV Area > Review. > > Short summary: This draft is ready. > > Thank you for the clearly written draft. > > Martin From nobody Fri Feb 10 13:38:44 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3C0129C5A for ; Fri, 10 Feb 2017 13:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOjeiuuwG4vy for ; Fri, 10 Feb 2017 13:38:34 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F35B129C5F for ; Fri, 10 Feb 2017 13:38:34 -0800 (PST) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-02v.sys.comcast.net with SMTP id cItccoV7iJ5z3cItlccDfi; Fri, 10 Feb 2017 21:38:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1486762713; bh=7tDqX5nGw8BcSEyogUbMdVOJwrDRWay92FsFnlZzSyg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=E4w+Zb+WTtLmMBLg/94ZE03mxnGoYiu1dkvpIPoXpoSzBsGUqz6To67NO/9zf2XiD waB/MNf+PScw0Asqy9nDvXeuO10OpL743Li27cptZyiZj3vuMO9TUr6pi9P38nCeyh kP5d7lKSfTj9MabEvyUAmSn0/ptNrdUf1+mfcvU/Ajq9xebkLXiwNAGfWdAL2xwYnL sEi2e4AdIzPjui86l6GmEsdRrfAU+37ivfAsVkh4QRjoP+2sZdr+lxxwq/4Or/IH+d Y1Br1ky1dUpO5nG7slX9hlqSH1warqPUFi3uoiWQbkRUFljQ0p/ZhmT81MqO2WkN7P FnqM4K5m96VuA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-12v.sys.comcast.net with SMTP id cItkcwJXIL4A9cItkcosTN; Fri, 10 Feb 2017 21:38:33 +0000 To: mmusic@ietf.org References: <148669725288.8138.2095744202497272272.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: Date: Fri, 10 Feb 2017 16:38:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfEdoB83f8ViJU6cEXKX3c9PxtJceW6gndDkiWGj3YYrml6e6spEfPnUG+vJ5JfoUpF4UK1OVNcNsRZREt8+2q2tU1Ie8yIn5hHoUXOTQEuxrcad0Jd/P Jr+8aNWts29XYa1Z+c9hRMBdRRYlB9C9EDEsqiml4nStf4BlOJHT3cZOsrtBj+/rj7QUURCDC6TcTg== Archived-At: Subject: Re: [MMUSIC] [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 21:38:42 -0000 On 2/10/17 9:15 AM, Christer Holmberg wrote: >> Section 5.2: >> >> Leading zeroes MUST NOT be used. >> >> What is the problem with leading zeros? What can go wrong when these are >> used? Should >> an implementor be warned about something specific? > > I don¹t know. The same statement exists for a number of SDP attributes, > but I didn¹t find any justification. This is standard practice in RFC4566. It has an ABNF rule: integer = POS-DIGIT *DIGIT that makes it invalid to insert leading zeros. I don't *know*, but speculate, that this might be tied to the C language convention where a leading zero means octal, and not wanting to introduce that confusion. But the sctp port value isn't defined using the 'integer' rule. It has its own definition: sctp-port-value = 1*5 To be consistent, perhaps that should be changed to: sctp-port-value = *4 Thanks, Paul From nobody Fri Feb 10 15:06:14 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 863E412A069; Fri, 10 Feb 2017 15:06:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Carpenter To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148676797054.29317.17761463000129345942.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2017 15:06:10 -0800 Archived-At: Cc: draft-ietf-mmusic-sctp-sdp.all@ietf.org, mmusic@ietf.org, brian.e.carpenter@gmail.com Subject: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-23 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 23:06:10 -0000 Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-ietf-mmusic-sctp-sdp-23 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-mmusic-sctp-sdp-23.txt Reviewer: Brian Carpenter Review Date: 2017-02-11 IETF LC End Date: 2017-02-09 IESG Telechat date: 2017-02-16 Summary: Ready -------- Comment: -------- Thanks for handling my Last Call comments. Nit: ---- Thanks for the IPv6 example. But RFC5952 recommends lower case as the canonical form: 2001:db8::a8fd From nobody Fri Feb 10 21:26:26 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFBB129420; Fri, 10 Feb 2017 21:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 YkQOAT399ruC; Fri, 10 Feb 2017 21:26:20 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17B91293E8; Fri, 10 Feb 2017 21:26:19 -0800 (PST) X-AuditID: c1b4fb30-b99fe70000007389-56-589ea0781ab2 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 58.75.29577.870AE985; Sat, 11 Feb 2017 06:26:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0319.002; Sat, 11 Feb 2017 06:26:16 +0100 From: Christer Holmberg To: Brian Carpenter Thread-Topic: Review of draft-ietf-mmusic-sctp-sdp-23 Thread-Index: AQHSg/JG+PDZpBijwkuorCJaK5ShS6FjRtZ7 Date: Sat, 11 Feb 2017 05:26:15 +0000 Message-ID: <9007DD69-14A7-4B15-9F2C-A8CB0223E817@ericsson.com> References: <148676797054.29317.17761463000129345942.idtracker@ietfa.amsl.com> In-Reply-To: <148676797054.29317.17761463000129345942.idtracker@ietfa.amsl.com> 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+NgFvrNLMWRmVeSWpSXmKPExsUyM2J7oG7lgnkRBvffWlm0XdzHZLGpfxOL xdVXn1kspi5/zOLA4rFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZXSsvsxeMIWzYmnvTvYG xlXsXYycHBICJhLzFzQwdTFycQgJrGOUOPbuNBuEs5hR4lr7NqAMBwebgIVE9z9tkAYRAUOJ /08/M4LUMAusZJS4eOc2E0hCGGhS55GbzBBFphJb+uexQ9hGEvcmLwerYRFQlWh7dAWshlfA XmJj1wU2EFtIwE9i6YyXYDWcAv4SK1dsZwSxGQXEJL6fWgMWZxYQl7j1ZD4TxNUCEkv2nGeG sEUlXj7+xwpRoyOxYPcnNghbW2LZwtdQuwQlTs58wjKBUWQWklGzkLTMQtIyC0nLAkaWVYyi xanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBUXJwy2+DHYwvnzseYhTgYFTi4S24OjdCiDWxrLgy 9xCjBAezkgjvjunzIoR4UxIrq1KL8uOLSnNSiw8xSnOwKInzmq28Hy4kkJ5YkpqdmlqQWgST ZeLglGpgDOex8DydvNDSgF+r980c7/7bx2PyTJLXhsqyJ0tVOj2ovqxRX8B89ti7HZXr+U/x PjrCeJX/aHvDEtNpqtL7rWKrPydqPpG7zfA7uu/6ufyTc1hte9LtVwZUns1ymdXvcn7exi1f 7d5MYrqTMsdefJ2V/Imd8+Tfft/Fla0bfu9B3O0It5NflFiKMxINtZiLihMBL9nmZo4CAAA= Archived-At: Cc: "gen-art@ietf.org" , "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-23 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 05:26:22 -0000 Hi Brian, I will fix the case in the next version. Thanks!=20 Regards, Christer=20 Sent from my iPhone > On 11 Feb 2017, at 1.06, Brian Carpenter wr= ote: >=20 > Reviewer: Brian Carpenter > Review result: Ready >=20 > Gen-ART telechat review of draft-ietf-mmusic-sctp-sdp-23 >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at > . >=20 > Document: draft-ietf-mmusic-sctp-sdp-23.txt > Reviewer: Brian Carpenter > Review Date: 2017-02-11 > IETF LC End Date: 2017-02-09 > IESG Telechat date: 2017-02-16 >=20 > Summary: Ready > -------- >=20 > Comment: > -------- >=20 > Thanks for handling my Last Call comments. >=20 > Nit: > ---- >=20 > Thanks for the IPv6 example. But RFC5952 recommends=20 > lower case as the canonical form: 2001:db8::a8fd >=20 From nobody Sun Feb 12 02:50:04 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D498C127A90; Sun, 12 Feb 2017 02:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 AxF-T-mrUSU1; Sun, 12 Feb 2017 02:50:02 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C246129443; Sun, 12 Feb 2017 02:50:01 -0800 (PST) X-AuditID: c1b4fb2d-ec7ff70000001743-2f-58a03dd78d06 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id D8.07.05955.7DD30A85; Sun, 12 Feb 2017 11:49:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0319.002; Sun, 12 Feb 2017 11:49:58 +0100 From: Christer Holmberg To: Ben Campbell , Martin Stiemerling Thread-Topic: Review of draft-ietf-mmusic-sctp-sdp-23 Thread-Index: AQHSg+EbAwpJPT4tJUqGBSz5Ce2Q06FisC2AgAKDhPA= Date: Sun, 12 Feb 2017 10:49:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFF8030@ESESSMB209.ericsson.se> References: <148676059794.29305.2115176925259048270.idtracker@ietfa.amsl.com> <5D2D3F1D-9D7A-4C20-B8D5-E5F118F07DEE@nostrum.com> In-Reply-To: <5D2D3F1D-9D7A-4C20-B8D5-E5F118F07DEE@nostrum.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2J7oO512wURBj3nNSzmd55mt9jUv4nF 4tnG+SwWk55OY7KYuvwxi8WsPYtYHNg8ds66y+6xZMlPJo9ZO5+wBDBHcdmkpOZklqUW6dsl cGV8PveSpWAva8XZo39YGhh3s3QxcnJICJhIPHxyibmLkYtDSGAdo8S0N3tZIJzFjBLPdjxm 62Lk4GATsJDo/qcN0iAi4C0xo2kxWA2zwClGiW8zD7GBJISBJu3s2sgEUWQqsaV/HjuEbSXR O286mM0ioCpxfOZOsHpeAV+J1sdbGCGWNTFK/P28ixkkwSlgL7HpwW2wIkYBMYnvp9aADWUW EJe49WQ+E8TZAhJL9pxnhrBFJV4+/scKYStJNC55wgpRryOxYPcnNghbW2LZwtfMEIsFJU7O fMIygVF0FpKxs5C0zELSMgtJywJGllWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgdF1cMtv 3R2Mq187HmIU4GBU4uE1iJ8fIcSaWFZcmXuIUYKDWUmElx0Ym0K8KYmVValF+fFFpTmpxYcY pTlYlMR5zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUwWm1t27JBbr2XuXCL1p2Pi66UGgWoOPrm aH4X7Z+1IbnF2OXQcpEV15N0o3fdPaB2UEJL6tBrdRH29Pmv77QxrTxy0bX95ofQhU87OQ8u e8ljMZfrmscBuROVrbuOnToWVcaw+JxHvU/c+y8OdxgXxH3LizvFrHamdEZh3dYH5sLPmzNm KnM+VWIpzkg01GIuKk4EABE5CcWqAgAA Archived-At: Cc: "tsv-art@ietf.org" , "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-23 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 10:50:04 -0000 Thank You, Martin!=20 Regards, Christer -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: 10 February 2017 23:27 To: Martin Stiemerling Cc: tsv-art@ietf.org; draft-ietf-mmusic-sctp-sdp.all@ietf.org; ietf@ietf.or= g; mmusic@ietf.org Subject: Re: Review of draft-ietf-mmusic-sctp-sdp-23 Thanks, Martin! Ben. On 10 Feb 2017, at 15:03, Martin Stiemerling wrote: > Reviewer: Martin Stiemerling > Review result: Ready > > Hi there, > > I have reviewed draft-ietf-mmusic-sctp-sdp-23 as part of the TSV Area=20 > Review. > > Short summary: This draft is ready. > > Thank you for the clearly written draft. > > Martin From nobody Mon Feb 13 05:17:29 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73539129667; Mon, 13 Feb 2017 05:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 1t0M00N8YflB; Mon, 13 Feb 2017 05:17:18 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7969129666; Mon, 13 Feb 2017 05:17:17 -0800 (PST) X-AuditID: c1b4fb3a-bb7cb98000005e23-4a-58a1b1db6ad5 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 08.20.24099.BD1B1A85; Mon, 13 Feb 2017 14:17:15 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0319.002; Mon, 13 Feb 2017 14:16:29 +0100 From: Christer Holmberg To: Christer Holmberg , Paul Wouters , Paul Wouters Thread-Topic: [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 Thread-Index: AQHSg02fz09JgsaxQEyJwWweq6l2mKFhhUMAgADVvICABKaOgA== Date: Mon, 13 Feb 2017 13:16:28 +0000 Message-ID: References: <148669725288.8138.2095744202497272272.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="euc-kr" Content-ID: <7C93A738973FC344BE5F5B64AC34F280@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM2J7oO7tjQsjDDY1mFts6t/EYvFs43wW i6nLH7NYvL91icni5L57TBYfFj5kcWDzWLLkJ5PH93lMHu/3XWULYI7isklJzcksSy3St0vg ypi2+SxTwQ6mipmPNzA3MG5g6mLk5JAQMJHo/97C3MXIxSEksI5R4saxKSwgCSGBxYwSvxZY dTFycLAJWEh0/9MGCYsIVEu8bu1kAqlnFtjNKPHsyH52kBphAVuJ098UIGrsJJpnf2CDsJ0k Jn5dwQxiswioSnQ3bWEFsXkFrCW+dl+B2ruVUeL88p9gB3EK2EhcWX8E7AZGATGJ76fWgMWZ BcQlbj2ZD3W0gMSSPeeZIWxRiZeP/4ENFRXQk1j+fA0zyD0SAkoS07amQbRqSXz5sY8NwraW ePD4PTOErSgxpfshO8Q9ghInZz5hmcAoPgvJtllI2mchaZ+FpH0WkvYFjKyrGEWLU4uLc9ON jPRSizKTi4vz8/TyUks2MQKj8+CW31Y7GA8+dzzEKMDBqMTDu2HDgggh1sSy4srcQ4wSHMxK IrzlGxZGCPGmJFZWpRblxxeV5qQWH2KU5mBREuc1W3k/XEggPbEkNTs1tSC1CCbLxMEp1cBY +GgKB+/cdmf1Db9+ndjedO+k6ZWMN/dvZd+wCzz98NYklaONp76eu/ExT1Rc7zTD7rio+H2M p17VT65etuyu8UaBSjsbBm71+Lllk2bx6H5vauD73HVuZ+HJU2LaDQJGSrVX7rs5/us7w8z5 dq6pptrrbSpe689pFVla8vU+WNls1debP/GlEktxRqKhFnNRcSIAqy7p5MoCAAA= Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" , secdir Subject: Re: [MMUSIC] [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 13:17:19 -0000 SGkgUGF1bCwNCg0KLi4uDQoNCj4+U2VjdGlvbiAxMC4zDQo+Pg0KPj5bSS1ELmlldGYtbW11c2lj LWR0bHMtc2RwXSBpcyBub3QgYSBwcm9wZXIgcmVmZXJlbmNlIHdpdGggbGluay4NCj4NCj5JqfZs bCBsb29rIGludG8gdGhhdC4NCg0KSSBoYWQgYSBsb29rIGEgdGhpcywgYnV0IEkgYW0gbm90IHN1 cmUgSSB1bmRlcnN0YW5kIHlvdXIgaXNzdWUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Mon Feb 13 07:41:38 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564931296CA; Mon, 13 Feb 2017 07:41:32 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05R1TK_WSdyr; Mon, 13 Feb 2017 07:41:31 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C38129406; Mon, 13 Feb 2017 07:41:30 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vMVBb4lTmzd3; Mon, 13 Feb 2017 16:40:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1487000456; bh=nu5I0bqJq9L+xfMF+e5anV7CyisU334gGcoBDcUyBIU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Hj4kT1oBeEzoONM2kDVZubv0bMeV+p6n1ywJgoQCSAsgxWHUgmhlpYOUnjvUBZH+O tVCVlAy6Uk+5Q7fU0Elcj3CJT3NuPTxtGtLQMqakvfTn8AEmLIkgbyUN3RE6b+eBG5 t6zEvC6IPn0gzpc2z3oyIH5qgcVBzQ2FrYEX6UDw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id qzZk10l4PELa; Mon, 13 Feb 2017 16:40:53 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 13 Feb 2017 16:40:53 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A42E02DEFF6; Mon, 13 Feb 2017 10:40:52 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca A42E02DEFF6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8D6AC41DA420; Mon, 13 Feb 2017 10:40:52 -0500 (EST) Date: Mon, 13 Feb 2017 10:40:52 -0500 (EST) From: Paul Wouters To: Christer Holmberg In-Reply-To: Message-ID: References: <148669725288.8138.2095744202497272272.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=euc-kr; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , Paul Wouters , "ietf@ietf.org" , "mmusic@ietf.org" , secdir Subject: Re: [MMUSIC] [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 15:41:32 -0000 On Mon, 13 Feb 2017, Christer Holmberg wrote: >>> Section 10.3 >>> >>> [I-D.ietf-mmusic-dtls-sdp] is not a proper reference with link. >> >> I©öll look into that. > > I had a look a this, but I am not sure I understand your issue. It has the ascii test "[I-D.ietf-mmusic-dtls-sdp]" instead of the markup text: Paul From nobody Mon Feb 13 11:41:25 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABEE12988C; Mon, 13 Feb 2017 11:41:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148701488410.25051.3153323866385115213.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2017 11:41:24 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-19.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 19:41:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-19.txt Pages : 26 Date : 2017-02-13 Abstract: This document defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, 'dtls-id'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 13 14:02:26 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22DE12999A for ; Mon, 13 Feb 2017 14:02:24 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToGZNZGP2jCI for ; Mon, 13 Feb 2017 14:02:18 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566051299A2 for ; Mon, 13 Feb 2017 14:02:18 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id w20so95675129qtb.1 for ; Mon, 13 Feb 2017 14:02:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ki6BvIHk+jOzacJu4MrZXgyTSCrvfoP41pb/JiCJwzg=; b=hVZOkZdAgQfcqxA3p6/H1sNTw5HwNoQGTYeZFBXKyecxQeKbYl0nG1hTdK9wR6ZOVD XwOGLnxnq8IJQwn9zT+5RjcQvW4vJkx2Skbr1BQOjSRlwq3YWLeKE881lV0UPVfOPzVx 87pcEt/CUYg1j16HK+EVWa4CiSw8xiIt+qNqeSP5tzRRiRO68UMRmQn32ii31cRMWxUw hasOHCVzm5TxeXsPu/+2nSXGCD1BTf0CpwGxaZwSrxrVzGfWB/nPn+oMcZFNv1/EcHZz j87cl978sRYSQS28oPHnQ0ZNP3FH19EWTuJOBPfb989scpVzZRrhbbMnShx5UYpBVp2l zq/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ki6BvIHk+jOzacJu4MrZXgyTSCrvfoP41pb/JiCJwzg=; b=jqJ1a8gWiwjCKoczs7WR/XwITmWoxv+A+w0JAA+455hUSyEnf6A7cYJJp9wzJ7G20E FNf8ib7IbUwVz0LtOf0yprnzjUzyw2ARCa5T9KqhuHNN3oUIyYsUKw74TXC1ONNAzrIt T/6aXGywdoMlSrsOZVpb++14Q0FtgM6B3N7Xt+jtVBbRB20k6NDGLZqhwJQv4mvGbLE9 P7SEGuAzIvsnjjY09amUepSLmVVCvuDAmN7dlJPDR97my1VUTvoWhn56i/Ify0+OvO2Y UWhDrcKFCKgchrIbxd92rp/Shpowc91kc7guEAt67xuqG9mQquQEIUd1ObRkA6ekcmeA KQXw== X-Gm-Message-State: AMke39kWWpIbASduiqxHAtwieFG8XQTJJ1vGgJRZyAjeHA6scuFlnuji2oog42defsE7CA== X-Received: by 10.237.50.229 with SMTP id z92mr22539787qtd.182.1487023337251; Mon, 13 Feb 2017 14:02:17 -0800 (PST) Received: from mail-qt0-f170.google.com (mail-qt0-f170.google.com. [209.85.216.170]) by smtp.gmail.com with ESMTPSA id h33sm8327933qtc.42.2017.02.13.14.02.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Feb 2017 14:02:16 -0800 (PST) Received: by mail-qt0-f170.google.com with SMTP id k15so96223958qtg.3 for ; Mon, 13 Feb 2017 14:02:16 -0800 (PST) X-Received: by 10.200.50.18 with SMTP id x18mr25703188qta.58.1487023335892; Mon, 13 Feb 2017 14:02:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Mon, 13 Feb 2017 14:02:15 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BFEF197@ESESSMB209.ericsson.se> From: Roman Shpount Date: Mon, 13 Feb 2017 17:02:15 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1143ac58b56d3705487099d1 Archived-At: Cc: mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 22:02:24 -0000 --001a1143ac58b56d3705487099d1 Content-Type: text/plain; charset=UTF-8 Hi All, I got the principal question about rtcp-mux-only. Is it needed only as a hint to SBC while connection is being established? It it is a hint to SBC, it does not matter that the answering end point does not support it. All it says is that offering end point is not expecting any media on rtp port + 1 and will refuse any connection which sends it, so SBC does not need to allocate an extra port during setup. If this is all, we should not insert rtcp-mux-only in the answer and always must include both rtcp-mux-only and rtcp-mux in the offer. If my understanding is correct, I agree with Eric's logic and we should tighten up the mux-exclusive draft. Regards, _____________ Roman Shpount On Tue, Feb 7, 2017 at 8:15 PM, Eric Rescorla wrote: > It seems like that just moves the load onto everyone else who has to > process both the > case where you have a=rtcp-mux and the one where you do not. > > -Ekr > > On Tue, Feb 7, 2017 at 4:26 PM, Roman Shpount wrote: > >> Essentially a few test cases less to test. >> >> Regards, >> _____________ >> Roman Shpount >> >> On Tue, Feb 7, 2017 at 6:52 PM, Eric Rescorla wrote: >> >>> On Tue, Feb 7, 2017 at 12:38 PM, Roman Shpount >>> wrote: >>> >>>> I want to be able to send rtcp-mux-only. I see plenty of scenarios >>>> where my solution communicates exclusively with Web browsers. Once they >>>> implement rtcp-mux-only, given the rate with which browsers are updated, I >>>> would like, at some point, stop using rtcp-mux instead of inserting legacy >>>> flag indefinitely. >>>> >>> >>> What resource are you conserving here? It's not exactly consuming a lot >>> of space in the SDP. >>> >>> -Ekr >>> >>> >>> >>> Regards, >>>> _____________ >>>> Roman Shpount >>>> >>>> On Tue, Feb 7, 2017 at 3:33 PM, Eric Rescorla wrote: >>>> >>>>> >>>>> >>>>> On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg < >>>>> christer.holmberg@ericsson.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> >> We had a long discussion about this, with many different opinions, >>>>>> and it would take some time to >>>>>> >> go through the archive and check everything. But, one opinion was >>>>>> that it IS useful to send the >>>>>> >> attribute, as it indicates support of the mechanism. >>>>>> > >>>>>> > What does the other side do with that? >>>>>> >>>>>> Well, it knows that it doesn't have to include a=rtcp-mux the next >>>>>> time it wants to do mux-only. >>>>>> >>>>>> Obviously, as you suggested in your original e-mail, if we wouldn't >>>>>> allow a=rtcp-mux-only without a=rtcp-mux (alt #4) in an offer to begin >>>>>> with, it doesn't matter. >>>>>> >>>>> >>>>> Yeah, I don't think this is a plausible option. >>>>> >>>>> At this point it would be great to hear from anyone who thinks that we >>>>> should allow >>>>> a=rtcp-mux-only without a=rtcp-mux.... >>>>> >>>>> -Ekr >>>>> >>>>> >>>>>> >>>>>> > Is there any precedent for this in SDP? >>>>>> >>>>>> Not anything I can think of. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> From: Eric Rescorla >>>>>> Date: Monday 6 February 2017 at 16:32 >>>>>> To: Christer Holmberg >>>>>> Cc: "mmusic@ietf.org" >>>>>> Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg < >>>>>> christer.holmberg@ericsson.com> wrote: >>>>>> Hi, >>>>>> >>>>>> >>> Following up to myself, I don't think it's sensible for answers to >>>>>> >>>contain a=rtcp-mux-only, because either you accepted mux, in which >>>>>> case >>>>>> >>>all is good, or you rejected it, in which case it was rejected. >>>>>> >> >>>>>> >> While I agree that a=rtcp-mux would be enough in the Answer as far >>>>>> as >>>>>> >>indicating mux is concerned, including a=rtcp-mux-only in the Answer >>>>>> >>does indicate that the Answerer supports the mux-exclusive >>>>>> mechanism. >>>>>> > >>>>>> > I don't see how that's really that useful >>>>>> >>>>>> But what harm does it cause? >>>>>> >>>>>> I don't think that's the standard here. We should only send >>>>>> indicators in SDP when they >>>>>> do something useful. >>>>>> >>>>>> -Ekr >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla >>>>>> wrote: >>>>>> >>>>>> I have been reading the mux-exclusive document and I'm not sure it >>>>>> says >>>>>> quite what we want. Specifically, S 4.2 says: >>>>>> >>>>>> When an offerer sends the initial offer, if the offerer wants to >>>>>> indicate exclusive RTP/RTCP multiplexing for RTP-based media, the >>>>>> offerer MUST associate an SDP 'rtcp-mux-only' attribute with the >>>>>> associated SDP media description ("m=" line). >>>>>> >>>>>> In addition, if the offerer associates an SDP 'rtcp-mux-only' >>>>>> attribute with an SDP media description ("m=" line), the offerer >>>>>> MAY >>>>>> also associate an SDP 'rtcp-mux' attribute with the same SDP media >>>>>> description ("m=" line), following the procedures in [RFC5761]. >>>>>> >>>>>> As I understand this text, the offerer may say the following things: >>>>>> >>>>>> 1. No a=rtcp-mux: No muxing. >>>>>> 2. a=rtcp-mux: I am offering RTCP mux >>>>>> 3. a=rtcp-mux-only + a=rtcp-mux: I will only do RTCP mux >>>>>> 4. a=rtcp-mux-only: I will only do RTCP mux (same as #3). >>>>>> >>>>>> I don't think the last of these is sensible. No current implementation >>>>>> will know what to do with a=rtcp-mux-only w/o a=rtcp-mux, so this will >>>>>> result in interop failures. Thus the MAY in the second graf needs to >>>>>> be >>>>>> a MUST. >>>>>> >>>>>> -Ekr >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>>> >>>> >>> >> > --001a1143ac58b56d3705487099d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I got the principal question ab= out rtcp-mux-only. Is it needed only as a hint to SBC while connection is b= eing established?

It it is a hint to SBC, it does = not matter that the answering end point does not support it. All it says is= that offering end point is not expecting any media on rtp port + 1 and wil= l refuse any connection which sends it, so SBC does not need to allocate an= extra port during setup. If this is all, we should not insert rtcp-mux-onl= y in the answer and always must include both rtcp-mux-only and rtcp-mux in = the offer.

If my understanding is correct, I agree= with Eric's logic and we should tighten up the mux-exclusive draft.

Regards,

_____________
Roman Shpount

On Tue, Feb 7, 2017 at 8:15 PM, Eric Rescorl= a <e= kr@rtfm.com> wrote:
It seems like that just moves the load= onto everyone else who has to process both the
case where you have a=3Drtcp-mux and the one where you do not.

-Ekr

On Tue, Feb 7, 2017 at 4:26 PM, Roman S= hpount <roman@telurix.com> wrote:
Essentially a few test cases less to test.
Regards,
_____________
Roman Shpoun= t

On Tue, Feb 7, 2017 at 6:52 PM, Eric Rescorl= a <e= kr@rtfm.com> wrote:
On Tu= e, Feb 7, 2017 at 12:38 PM, Roman Shpount <roman@telurix.com> wrote:
I want to be ab= le to send rtcp-mux-only. I see plenty of scenarios where my solution commu= nicates exclusively with Web browsers. Once they implement rtcp-mux-only, g= iven the rate with which browsers are updated, I would like, at some point,= stop using rtcp-mux instead of inserting legacy flag indefinitely.

What resource are you conserving here= ? It's not exactly consuming a lot of space in the SDP.

<= /div>
-Ekr



Regards,
_____________
Roman Shpount

On Tue, Feb= 7, 2017 at 3:33 PM, Eric Rescorla <ekr@rtfm.com> wrote:


= On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
Hi,

>> We had a long discussion about this, with many different opinions,= and it would take some time to
>> go through the archive and check everything. But, one opinion was = that it IS useful to send the
>> attribute, as it indicates support of the mechanism.
>
> What does the other side do with that?

Well, it knows that it doesn't have to include a=3D= rtcp-mux the next time it wants to do mux-only.

Obviously, as you suggested in your original e-mail, if we wouldn't all= ow a=3Drtcp-mux-only without a=3Drtcp-mux (alt #4) in an offer to begin wit= h, it doesn't matter.

Yeah, = I don't think this is a plausible option.

At t= his point it would be great to hear from anyone who thinks that we should a= llow
a=3Drtcp-mux-only without a=3Drtcp-mux....

-Ekr
=C2=A0

> Is there any precedent for this in SDP?

Not anything I can think of.
=

Regards,

Christer


From: Eric Rescorla <e= kr@rtfm.com>
Date: Monday 6 February 2017 at 16:32
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "mmusic@ietf.= org" <mmus= ic@ietf.org>
Subject: Re: [MMUSIC] Sending a=3Drtcp-mux-only w/o a=3Drtcp-mux



On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
Hi,

>>> Following up to myself, I don't think it's sensible fo= r answers to
>>>contain a=3Drtcp-mux-only, because either you accepted mux, in = which case
>>>all is good, or you rejected it, in which case it was rejected.=
>>
>> While I agree that a=3Drtcp-mux would be enough in the Answer as f= ar as
>>indicating mux is concerned, including a=3Drtcp-mux-only in the Ans= wer
>>does indicate that the Answerer supports the mux-exclusive mechanis= m.
>
> I don't see how that's really that useful

But what harm does it cause?

I don't think that's the standard here. We should only send indicat= ors in SDP when they
do something useful.

-Ekr


Regards,

Christer




On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla
<ekr@rtfm.com> = wrote:

I have been reading the mux-exclusive document and I'm not sure it says=
quite what we want. Specifically, S 4.2 says:

=C2=A0 =C2=A0When an offerer sends the initial offer, if the offerer wants = to
=C2=A0 =C2=A0indicate exclusive RTP/RTCP multiplexing for RTP-based media, = the
=C2=A0 =C2=A0offerer MUST associate an SDP 'rtcp-mux-only' attribut= e with the
=C2=A0 =C2=A0associated SDP media description ("m=3D" line).

=C2=A0 =C2=A0In addition, if the offerer associates an SDP 'rtcp-mux-on= ly'
=C2=A0 =C2=A0attribute with an SDP media description ("m=3D" line= ), the offerer MAY
=C2=A0 =C2=A0also associate an SDP 'rtcp-mux' attribute with the sa= me SDP media
=C2=A0 =C2=A0description ("m=3D" line), following the procedures = in [RFC5761].

As I understand this text, the offerer may say the following things:

=C2=A01. No a=3Drtcp-mux: No muxing.
=C2=A02. a=3Drtcp-mux: I am offering RTCP mux
=C2=A03. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux
=C2=A04. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3).

I don't think the last of these is sensible. No current implementation<= br> will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will<= br> result in interop failures. Thus the MAY in the second graf needs to be
a MUST.

-Ekr


















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





--001a1143ac58b56d3705487099d1-- From nobody Mon Feb 13 22:47:34 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF11212940E; Mon, 13 Feb 2017 22:47:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148705484897.22133.10177366979991601003.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2017 22:47:28 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-20.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 06:47:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-20.txt Pages : 26 Date : 2017-02-13 Abstract: This document defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, 'dtls-id'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 14 01:27:38 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A689412952F for ; Tue, 14 Feb 2017 01:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 eeMC_P6tnoFH for ; Tue, 14 Feb 2017 01:27:34 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82EC1294D8 for ; Tue, 14 Feb 2017 01:27:33 -0800 (PST) X-AuditID: c1b4fb30-b99fe70000007389-c6-58a2cd81f930 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 68.B4.29577.18DC2A85; Tue, 14 Feb 2017 10:27:31 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0319.002; Tue, 14 Feb 2017 10:27:29 +0100 From: Christer Holmberg To: Roman Shpount , Eric Rescorla Thread-Topic: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux Thread-Index: AQHSfkR3UhfsVBhEwUWv5/2Z0yKCVaFXfBcAgASHPoD//+NbAIAAMCIA///nooCAAVZKgIAAF9KAgABohoCAACCTAIAAAV4AgAA2PgCAAAmMAIAADWsAgAk4I4CAAOGbAA== Date: Tue, 14 Feb 2017 09:27:29 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BFEF197@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D4C898F7181B1christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM2J7lG7z2UURBjM3G1useH2O3WLq8scs FjMuTGV2YPZYsuQnk8fkx23MHremFAQwR3HZpKTmZJalFunbJXBlLD7wgLng4GzGiiMLF7M0 MN5pZuxi5OSQEDCR+PN8OXMXIxeHkMA6RonFFyexQjiLGSU2PPvI0sXIwcEmYCHR/U8bpEFE wFmiq/ceK4jNLCAvcWHJGiYQW1jARuLeidesEDW2Ek+3HwYbKiIwiVGi5/cXsCIWAVWJoycm M4PYvALWEks3f2aDWPaBXWLG2SNsIAlOgUCJDwuegRUxCohJfD8FsYFZQFzi1pP5TBBnC0gs 2XOeGcIWlXj5+B/YZlEBPYnlz9dAxRUlrk5fzgTyALNAgsSJQ5kQewUlTs58wjKBUXQWkqmz EKpmIamCKNGRWLD7ExuErS2xbOFrZhj7zIHHTBC2tcTdkzNR1Cxg5FjFKFqcWpyUm25kpJda lJlcXJyfp5eXWrKJERidB7f8NtjB+PK54yFGAQ5GJR7eDycXRgixJpYVV+YeYpTgYFYS4S05 tihCiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/ZyvvhQgLpiSWp2ampBalFMFkmDk6pBkav/X/D dCaf0X0Zev//Z9uDUzTOCHK1yun+vf/91b6J4hUnVDu8VN/4Pfhof5l1olanz45u0z1X/58/ 47eQ+Zd99HvDNdPfNdztdDK2WeV9q8PIXO3tAmXhA6ttM2Q2/Q9mEKuY11nLv+XAJZ3KXWy2 i+p2/+ZZ+bDzrLfRzsuiRovkr1pdNt6nxFKckWioxVxUnAgAWV5H08oCAAA= Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 09:27:36 -0000 --_000_D4C898F7181B1christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Just to make sure I understand. You are suggesting: 1. In the offer, the offerer includes BOTH rtcp-mux-only and rtcp-mux. Or, = is including rtcp-mux still a MAY? 2. In the answerer, the answerer includes ONLY rtcp-mux. rtcp-mux-only is n= ever used in an answer. Regards, Christer From: Roman Shpount > Date: Tuesday 14 February 2017 at 00:02 To: Eric Rescorla > Cc: Christer Holmberg >, "mmusic@ietf.org" > Subject: Re: [MMUSIC] Sending a=3Drtcp-mux-only w/o a=3Drtcp-mux Hi All, I got the principal question about rtcp-mux-only. Is it needed only as a hi= nt to SBC while connection is being established? It it is a hint to SBC, it does not matter that the answering end point doe= s not support it. All it says is that offering end point is not expecting a= ny media on rtp port + 1 and will refuse any connection which sends it, so = SBC does not need to allocate an extra port during setup. If this is all, w= e should not insert rtcp-mux-only in the answer and always must include bot= h rtcp-mux-only and rtcp-mux in the offer. If my understanding is correct, I agree with Eric's logic and we should tig= hten up the mux-exclusive draft. Regards, _____________ Roman Shpount On Tue, Feb 7, 2017 at 8:15 PM, Eric Rescorla > wrote: It seems like that just moves the load onto everyone else who has to proces= s both the case where you have a=3Drtcp-mux and the one where you do not. -Ekr On Tue, Feb 7, 2017 at 4:26 PM, Roman Shpount > wrote: Essentially a few test cases less to test. Regards, _____________ Roman Shpount On Tue, Feb 7, 2017 at 6:52 PM, Eric Rescorla > wrote: On Tue, Feb 7, 2017 at 12:38 PM, Roman Shpount > wrote: I want to be able to send rtcp-mux-only. I see plenty of scenarios where my= solution communicates exclusively with Web browsers. Once they implement r= tcp-mux-only, given the rate with which browsers are updated, I would like,= at some point, stop using rtcp-mux instead of inserting legacy flag indefi= nitely. What resource are you conserving here? It's not exactly consuming a lot of = space in the SDP. -Ekr Regards, _____________ Roman Shpount On Tue, Feb 7, 2017 at 3:33 PM, Eric Rescorla > wrote: On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg > wrote: Hi, >> We had a long discussion about this, with many different opinions, and i= t would take some time to >> go through the archive and check everything. But, one opinion was that i= t IS useful to send the >> attribute, as it indicates support of the mechanism. > > What does the other side do with that? Well, it knows that it doesn't have to include a=3Drtcp-mux the next time i= t wants to do mux-only. Obviously, as you suggested in your original e-mail, if we wouldn't allow a= =3Drtcp-mux-only without a=3Drtcp-mux (alt #4) in an offer to begin with, i= t doesn't matter. Yeah, I don't think this is a plausible option. At this point it would be great to hear from anyone who thinks that we shou= ld allow a=3Drtcp-mux-only without a=3Drtcp-mux.... -Ekr > Is there any precedent for this in SDP? Not anything I can think of. Regards, Christer From: Eric Rescorla > Date: Monday 6 February 2017 at 16:32 To: Christer Holmberg > Cc: "mmusic@ietf.org" > Subject: Re: [MMUSIC] Sending a=3Drtcp-mux-only w/o a=3Drtcp-mux On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg > wrote: Hi, >>> Following up to myself, I don't think it's sensible for answers to >>>contain a=3Drtcp-mux-only, because either you accepted mux, in which cas= e >>>all is good, or you rejected it, in which case it was rejected. >> >> While I agree that a=3Drtcp-mux would be enough in the Answer as far as >>indicating mux is concerned, including a=3Drtcp-mux-only in the Answer >>does indicate that the Answerer supports the mux-exclusive mechanism. > > I don't see how that's really that useful But what harm does it cause? I don't think that's the standard here. We should only send indicators in S= DP when they do something useful. -Ekr Regards, Christer On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla > wrote: I have been reading the mux-exclusive document and I'm not sure it says quite what we want. Specifically, S 4.2 says: When an offerer sends the initial offer, if the offerer wants to indicate exclusive RTP/RTCP multiplexing for RTP-based media, the offerer MUST associate an SDP 'rtcp-mux-only' attribute with the associated SDP media description ("m=3D" line). In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=3D" line), the offerer MAY also associate an SDP 'rtcp-mux' attribute with the same SDP media description ("m=3D" line), following the procedures in [RFC5761]. As I understand this text, the offerer may say the following things: 1. No a=3Drtcp-mux: No muxing. 2. a=3Drtcp-mux: I am offering RTCP mux 3. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux 4. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3). I don't think the last of these is sensible. No current implementation will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will result in interop failures. Thus the MAY in the second graf needs to be a MUST. -Ekr _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_D4C898F7181B1christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0EE9F74DA17D864A89B838B0F4E2D268@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Just to make sure I understand. You are suggesting:

1. In the offer, the offerer includes BOTH rtcp-mux-only and rtcp-mux.= Or, is including rtcp-mux still a MAY?

2. In the answerer, the answerer includes ONLY rtcp-mux. rtcp-mux-only= is never used in an answer.

Regards,

Christer

From: Roman Shpount <roman@telurix.com>
Date: Tuesday 14 February 2017 at 0= 0:02
To: Eric Rescorla <ekr@rtfm.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" = <mmusic@ietf.org>
Subject: Re: [MMUSIC] Sending a=3Dr= tcp-mux-only w/o a=3Drtcp-mux

Hi All,

I got the principal question about rtcp-mux-only. Is it needed only as= a hint to SBC while connection is being established?

It it is a hint to SBC, it does not matter that the answering end poin= t does not support it. All it says is that offering end point is not expect= ing any media on rtp port + 1 and will refuse any connection which send= s it, so SBC does not need to allocate an extra port during setup. If this is all, we should not insert rtcp-mux-= only in the answer and always must include both rtcp-mux-only and rtcp-mux = in the offer.

If my understanding is correct, I agree with Eric's logic and we shoul= d tighten up the mux-exclusive draft.

Regards,

_________= ____
Roman Shpount

On Tue, Feb 7, 2017 at 8:15 PM, Eric Rescorla <ekr@rtfm.com><= /span> wrote:
It seems like that just moves the load onto ever= yone else who has to process both the
case where you have a=3Drtcp-mux and the one whe= re you do not.

-Ekr

On Tue, Feb 7, 2017 at 4:26 PM, Roman Shpount <roman@telurix.co= m> wrote:
Essentially a few test cases less to test.

Regards,
_____________
Roman Shpount

On Tue, Feb 7, 2017 at 6:52 PM, Eric Rescorla <ekr@rtfm.com><= /span> wrote:
On Tue, Feb 7, 2017 at 12:38 PM, Roman Shp= ount <roman@telurix.co= m> wrote:
I want to be able to send rtcp-mux-only. I see plenty of s= cenarios where my solution communicates exclusively with Web browsers. Once= they implement rtcp-mux-only, given the rate with which browsers are updat= ed, I would like, at some point, stop using rtcp-mux instead of inserting legacy flag indefinitely.
What resource are you conserving here? It's not exactly consuming a lo= t of space in the SDP.

-Ekr



Regards,
_____________
Roman Shpount

On Tue, Feb 7, 2017 at 3:33 PM, Eric Rescorla <ekr@rtfm.com> wrot= e:


On Tue, Feb 7, 2017 at 9:40 AM, Christer H= olmberg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

>> We had a long discussion about this, with many different opi= nions, and it would take some time to
>> go through the archive and check everything. But, one opinion was = that it IS useful to send the
>> attribute, as it indicates support of the mechanism.
>
> What does the other side do with that?

Well, it knows that it doesn't have to include a=3Drtcp= -mux the next time it wants to do mux-only.

Obviously, as you suggested in your original e-mail, if we wouldn't allow a= =3Drtcp-mux-only without a=3Drtcp-mux (alt #4) in an offer to begin with, i= t doesn't matter.

Yeah, I don't think this is a plausible option.

At this point it would be great to hear from anyone who thinks that we= should allow
a=3Drtcp-mux-only without a=3Drtcp-mux....

-Ekr
 

> Is there any precedent for this in SDP?

Not anything I can think of.

Regards,

Christer


From: Eric Rescorla <e= kr@rtfm.com>
Date: Monday 6 February 2017 at 16:32
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "mmusic@ietf.= org" <mmus= ic@ietf.org>
Subject: Re: [MMUSIC] Sending a=3Drtcp-mux-only w/o a=3Drtcp-mux



On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
Hi,

>>> Following up to myself, I don't think it's sensible for answer= s to
>>>contain a=3Drtcp-mux-only, because either you accepted mux, in = which case
>>>all is good, or you rejected it, in which case it was rejected.=
>>
>> While I agree that a=3Drtcp-mux would be enough in the Answer as f= ar as
>>indicating mux is concerned, including a=3Drtcp-mux-only in the Ans= wer
>>does indicate that the Answerer supports the mux-exclusive mechanis= m.
>
> I don't see how that's really that useful

But what harm does it cause?

I don't think that's the standard here. We should only send indicators in S= DP when they
do something useful.

-Ekr


Regards,

Christer




On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla
<ekr@rtfm.com> = wrote:

I have been reading the mux-exclusive document and I'm not sure it says
quite what we want. Specifically, S 4.2 says:

   When an offerer sends the initial offer, if the offerer wants = to
   indicate exclusive RTP/RTCP multiplexing for RTP-based media, = the
   offerer MUST associate an SDP 'rtcp-mux-only' attribute with t= he
   associated SDP media description ("m=3D" line).

   In addition, if the offerer associates an SDP 'rtcp-mux-only'<= br>    attribute with an SDP media description ("m=3D" line= ), the offerer MAY
   also associate an SDP 'rtcp-mux' attribute with the same SDP m= edia
   description ("m=3D" line), following the procedures = in [RFC5761].

As I understand this text, the offerer may say the following things:

 1. No a=3Drtcp-mux: No muxing.
 2. a=3Drtcp-mux: I am offering RTCP mux
 3. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux
 4. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3).

I don't think the last of these is sensible. No current implementation
will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will<= br> result in interop failures. Thus the MAY in the second graf needs to be
a MUST.

-Ekr


















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





--_000_D4C898F7181B1christerholmbergericssoncom_-- From nobody Tue Feb 14 06:21:05 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675FC129A1E; Tue, 14 Feb 2017 06:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WjYj0yL-k9yf; Tue, 14 Feb 2017 06:20:58 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DDBA129502; Tue, 14 Feb 2017 06:20:57 -0800 (PST) X-AuditID: c1b4fb3a-7d7ff70000005e23-0c-58a312468720 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id F4.EA.24099.64213A85; Tue, 14 Feb 2017 15:20:56 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.319.2; Tue, 14 Feb 2017 15:20:54 +0100 From: Magnus Westerlund To: "Cullen Jennings (fluffy)" References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> Message-ID: <0e84fe0e-8e50-7b9f-bede-76ebf293a0d8@ericsson.com> Date: Tue, 14 Feb 2017 15:20:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM2K7uq6H0OIIg5W/uSymz3rHZjG/Yx2b RcdkNoupyx+zWKz9187uwOox5fdGVo8lS34yeXy5/JktgDmKyyYlNSezLLVI3y6BK6Ov5wlz wS71iv3Ny9kbGN/KdTFyckgImEh8/7ubDcQWEljHKPHrglMXIxeQvZxRYtajR0wgCTYBC4mb PxrBioQFqiU2zP4JFhcRMJRo2jOPCaJhBaPEz03TwRLMAh1MEpdWKIDYvAL2Ek9PH2PtYuTg YBFQlWjo8QUJiwrESOztv88EUSIocXLmExYQm1PAVuLD1PeMEGMsJGbOPw9ly0s0b53NDHGo tkRDUwfrBEaBWUjaZyFpmYWkZQEj8ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwOA9uOW3 1Q7Gg88dDzEKcDAq8fB+OLkwQog1say4MvcQowQHs5IIr7Dg4ggh3pTEyqrUovz4otKc1OJD jNIcLErivGYr74cLCaQnlqRmp6YWpBbBZJk4OKUaGHWXl6kKrZ+besryzJ2EujS9vRWvr1pa bzY4+P/krjWR9/heanx4HHzcz+7yNVvhf5eCeVT0ss+uS2Re5nvweOSEGTob9V6q5K3/5avJ e+ma3CbXPSn/4mrKNa/M7D78/b95wq5PizumaG1+mdtcOkN6V9nCndv23135q/nKMn+JGVFG K2QPCcsosRRnJBpqMRcVJwIA4Ax+OloCAAA= Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , "mmusic \(E-mail\)" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 14:21:00 -0000 Hi, Thanks for the feedback. Sorry for my delay in responding, a cold have kept from work. Den 2017-02-02 kl. 23:19, skrev Cullen Jennings (fluffy): > > So I much prefer the current text and think there are a bunch of > problems with this text. If we actually had emails explaining what > problems in the current text this was trying to fix, with individual > PRs for those, this would be much easier to resolve each of them and > get them fixed. > > 1) we have been trying to avoid the use of "RTP session" as it has > been very unclear to implementors what it is. I think this would be > better if we could rephrase to not use that Okay, but the RTP session is very easy to make clear in the context in of BUNDLE, where this text is intended to be. I can improve that. > > 2) both the proposed and current text seem lacking in dealing with > multiple bundle groups Okay, that can be fixed by clarifying that each bundle group results in its own RTP session, thus the procedures in this is per bundle group. > > 3) Stats are typically maintained by things after the packet is > routed - not before. So this comes a question of ones view of RTP stack and the question of layering. And this is exactly why I think the current text is problematic. It takes one very particular view, why I attempted to be much more neutral on which order things happens. There are a number of functions that are in the RTP protocol layer, not in the higher layers. There are however some things, like XR VoIP metrcis that are metrics in the higher layers. So, yes this is not clear cut. I think ones view of this depends on if one have a very integrated RTP implementation, then what you say makes sense, but if one has a very layered and modularized design, then my viewpoint makes more sense. From my perspective the most important thing here is that this text if it contains any RFC 2119 words can't prevent some possible implementation choices of the RTP stack. > > 4) Need to explain how the SDES in compound RTCP causes updates > I can attempt to clarify this. However, there is a potential issue here in that some implementations may not be able to force the receiver to process the content of the SDES RTCP packet prior to some or even all the other RTCP packets in a compound packet. What in the current text: On reception of any compound RTCP packet prior to dispatching the received information and data, if there is an RTCP SDES packet included that SHOULD be processed first. If that SDES packet contains SDES MID entries, this can results in updates and additions to the RTP stream to "m=" line mapping table. Thus each of the SDES MID items are processed and the current table entries are checked if the corresponding MID value matches the current RTP stream to "m=" line mapping, else the entry is updated. If there is no RTP stream to "m=" line table mapping entry for the received SDES item's SSRC, such an entry is created. Note, that in the process of updating the table entries, update flap suppression as discussed in Section 4.2.6 of [RFC7941] should be considered. Is insufficient in that regards. Is it only the placement prior to the individual RTCP packet types that is the issue? Should with the exception of the first sentence be moved under the SDES text? > 5) given this removes the outgoing SSRC table, not clear how it > routes RTCP reports. I think this needs to be clarified. > Okay, I think I understand that. I have an implicit assumption that the implementation knows how its local (outgoing) RTP Streams are related to the media sources and thus the related RTPsender. I can update the text to address this. > 6) I don't think most implementers are going to have a clue what to > do for the "Third Party Targeted Reports or Feedback" section > I can understand that, but I think it is important to call out that this bucket do exist, and if you don't know what to do I think it is fine to ignore these. > I will try and take your PR and break it up into some bit size pieces > so we can try and see if we can get the easy ones out of the way and > focus on the parts that are key changes. > Ok, I have seen that you generated a lot of individual issues, I will attempt to look through them and comment if there are things that was unintentional or where I have additional aspects to add. I intend to update my PR based on the feedback I received. 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 14 06:21:09 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691E0129A4D; Tue, 14 Feb 2017 06:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 XR0gz6YVSANa; Tue, 14 Feb 2017 06:21:01 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6B71298C1; Tue, 14 Feb 2017 06:21:00 -0800 (PST) X-AuditID: c1b4fb3a-7d7ff70000005e23-21-58a3124b7da0 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 38.EA.24099.B4213A85; Tue, 14 Feb 2017 15:21:00 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.319.2; Tue, 14 Feb 2017 15:20:59 +0100 From: Magnus Westerlund To: Cullen Jennings , Jonathan Lennox References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> Message-ID: Date: Tue, 14 Feb 2017 15:20:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM2J7lK6P0OIIg3nGFtNnvWOzmN+xjs3i w/ofjBb7F59ntpi6/DGLxdp/7ewObB5Llvxk8rh8/iOjx5fLn9k82p7dYQ9gieKySUnNySxL LdK3S+DKWDAtvWCWUsXl3/dZGhhvSXUxcnJICJhI3J3wh62LkYtDSGAdo8Tn39eZIJzljBI3 r/9nAqliE7CQuPmjkQ3EFhYokjjwso0ZxBYR8JRYtuUtVPciRon12y4xgzjMAn8ZJToXLmUB qeIVsJf42n2fFcRmEVCVaD70gx3EFhWIkdjbf58JokZQ4uTMJ2D1nAJWEheOzgfbwAy0eeb8 84wQtrxE89bZYHEhAW2JhqYO1gmMArOQtM9C0jILScsCRuZVjKLFqcXFuelGRnqpRZnJxcX5 eXp5qSWbGIFBfXDLb6sdjAefOx5iFOBgVOLh/XByYYQQa2JZcWXuIUYJDmYlEV5hwcURQrwp iZVVqUX58UWlOanFhxilOViUxHnNVt4PFxJITyxJzU5NLUgtgskycXBKNTBa/blW2iumqHm0 MmzK9uctR/XvneKafuS059XqU//L7obtPP1C1zuOQaDE1tU7clqg8Bshh0evfpgFO1wOeFYj FdK4gTvzdIWDqp4i18Q71hbmIjFT2e1cq0WPv771gn+pz+KP+7+K+7r35If+3q//YtdJi1mP ptkfjVnFedC/LyCTY3dn5HklluKMREMt5qLiRADSufa8ZgIAAA== Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 14:21:02 -0000 Hi, Please see below for my feedback on this. Den 2017-02-02 kl. 23:19, skrev Cullen Jennings: > >> On Jan 31, 2017, at 10:43 AM, Jonathan Lennox >> wrote: >> >> In general, this looks good. >> >> I have one question, however. What should happen if an RTP packet >> (without a MID) is received for a stream that has an existing >> mapping to an m= line, but whose PT is not valid for that m= line? >> >> Should it 1. Cause the stream’s mapping to be moved to another m= >> line, if the received PT is in the payload type table for some >> other m= line? or 2. Be an error? > > > Imagine a case where we have two sends call A and B and they each use > one PT that is unique and go to different m lines on receiver C via a > SFU. Initially C get a packet from B with a given SSRC and the PT > and creates a mapping for it. But imagine that A and B had an SSRC > collision which they sort that out and A ends up having the SSRC that > B initially used. If you don't have the PT override the SSRC, the > packets are going to go to the wrong m-line because the PT points at > the m-line A is using but the old SSRC incorrectly points at the > m-line B is using. > > To put this a different way, if the packet has a mid, I think it is > very clear the mid has to override the PT. Same for the PT. The mid > is effectively just an extended PT. > > I'm not thinking to much about the case where SSRC is signalled in > SDP but ignoring that case for a second, I think the really easy > thing to specify, implement, and understand works is simply a > priority order where roughly > > 1) if you have mid, use that and latch the SSRC > 2) if you have a unique pt, use that and latch the SSRC > 3) if you have a latched SSRC use that > > If you had signaled SSRC, guess I would insert that as step 1.5 of > use that > The issue as I see it is when and how you update the RTP stream to m= line mapping table. I think we have to be clear and separate the actions for how the RTP stream to m= line table is built and how it is updated. Signalling: Build mid to m= line table If a=ssrc is used, enter SSRC in RTP stream to m= line table. Add flag (signalled) to entry. On Reception of RTP stream not in RTP stream to m= line table: 1) if you have mid, use that and add to RTP stream table. 2) if you have a unique pt, use that and add to RTP stream table If the RTP stream is in the RTP stream to m= line table. On RTP packet reception check if update is needed: 1) New MID, then update RTP stream entry, unless signalled 2) If PT indicates different m= line, update entry unless signalled or set by MID. The point of looking on the problem from this direction is that we actually need to care about what set the entry originally and if it has precedence. Yes, the question of how one removes or updates stale entries are important. But this brings out the question for the above. Is an entry set by MID to be overwritten by a PT change? Yes, it will be possible to construct edge cases where one or the other approach will be sub-optimal. However, I think biasing the usage for working correctly with MID and having sub-optimal behaviors in other cases that can be avoided by for example the SFU not making bad choices, like not suppressing SSRC collisions between the different SSRC spaces. So entry updates are happening for the following reasons. New SDP: Remove all signalled entries not explicitly included in new signalling message. Explicitly listed entries are updated to indicate the correct m= line. RTCP BYE: Remove SSRC from table (using timeout procedure to avoid RTP packet reordering from reinstating entry), unless signalled? SSRC timeout. If the SSRC times out on RTP/RTCP level, then the entry is also removed, unless signaled. 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 14 09:30:00 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56911296CE for ; Tue, 14 Feb 2017 09:29:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzaDuzTcU4sy for ; Tue, 14 Feb 2017 09:29:45 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D9812941A for ; Tue, 14 Feb 2017 09:29:45 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id v23so117001899qtb.0 for ; Tue, 14 Feb 2017 09:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NXl8vhCcjxSniHYfaNZb/LulsudP9vUso8gzgGWmHoM=; b=k+OHlxONvBxaN3ba87FRRz9otshh0sKu58jfJ8s2ewULyYGb+ygb88P8bHHKZTikFJ c94inK0FlvWVSELqnEt0NSOgXqvYCedlXvsxTEALK6S+5I8n8XfrTpGokgKthZrUe+g8 jkepCbax2YqbMumhYkHpyZyYtUmo3k/VVuw5/vKcXVzV1Ne1mkqtZfrBeKsLGzejB+vf kHMsQ8C9mK9SWfpa1Lwldq+1xL6nGK20K8mbnGwmKLoKRQsBPORZ/Jzk8lH26V7/AUGQ 2RaVYf76nUCz5aiFngZqp+LJz1CMpjT30ZFo1C3SOZtJUVO47UcbqBZwPEcRgOR2qNd1 Lezg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NXl8vhCcjxSniHYfaNZb/LulsudP9vUso8gzgGWmHoM=; b=r+JJS/RHRczbAO0YXUYVsOcBFihAEkjQl8x3rjKQZbpACxyyGgfgLO2rPjZyuHdEhk Cz23ZROFjeLiYlZcKi3g3+9GGlJlA5CTEyvqPcy5MTDnGkmhUIV7FWCSsWctLXLzRFZj WI3TplxDcuPeg7IA2xANNm5Y363+MsC1bHXIesAFupyGPDFsQ4itFeD4Zvk+yeAn7OV0 ljKc/tUgbwQDE6RcrwGya8RzNzWGG5/O+PB/U+fIOsORKb6KDr+1bVzLT5ojyq25egYx dXfoUmv01nWl7cOY2Lm77wx5F7OiMVTxv88CLnDKKuQ4bBmAutcF7pFwuecBLMR3O1TE /6Iw== X-Gm-Message-State: AMke39mr4uZvrJ6j+rEzCpm9GSfoT/KMH73nzASGrYTFzzJLnbr6z29lNgzBakIxN+9hfA== X-Received: by 10.237.42.1 with SMTP id c1mr26718154qtd.10.1487093384036; Tue, 14 Feb 2017 09:29:44 -0800 (PST) Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com. [209.85.216.182]) by smtp.gmail.com with ESMTPSA id l53sm682526qtl.41.2017.02.14.09.29.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 09:29:43 -0800 (PST) Received: by mail-qt0-f182.google.com with SMTP id k15so117217952qtg.3 for ; Tue, 14 Feb 2017 09:29:43 -0800 (PST) X-Received: by 10.200.55.173 with SMTP id d42mr26880545qtc.168.1487093383107; Tue, 14 Feb 2017 09:29:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Tue, 14 Feb 2017 09:29:42 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BFEF197@ESESSMB209.ericsson.se> From: Roman Shpount Date: Tue, 14 Feb 2017 12:29:42 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113e609ad91f58054880e894 Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 17:29:48 -0000 --001a113e609ad91f58054880e894 Content-Type: text/plain; charset=UTF-8 Hi, 1. In the offer BOTH rtcp-mux and rtcp-mux-only MUSTbe included 2. In the answer rtcp-mux MUST be included or the session should be terminated. rtcp-mux-only MUST NOT be included. This removes any variation on what can and cannot be included in the offer or the answer. _____________ Roman Shpount On Tue, Feb 14, 2017 at 4:27 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Just to make sure I understand. You are suggesting: > > 1. In the offer, the offerer includes BOTH rtcp-mux-only and rtcp-mux. Or, > is including rtcp-mux still a MAY? > > 2. In the answerer, the answerer includes ONLY rtcp-mux. rtcp-mux-only is > never used in an answer. > > Regards, > > Christer > > From: Roman Shpount > Date: Tuesday 14 February 2017 at 00:02 > To: Eric Rescorla > Cc: Christer Holmberg , "mmusic@ietf.org" > > > Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux > > Hi All, > > I got the principal question about rtcp-mux-only. Is it needed only as a > hint to SBC while connection is being established? > > It it is a hint to SBC, it does not matter that the answering end point > does not support it. All it says is that offering end point is not > expecting any media on rtp port + 1 and will refuse any connection which > sends it, so SBC does not need to allocate an extra port during setup. If > this is all, we should not insert rtcp-mux-only in the answer and always > must include both rtcp-mux-only and rtcp-mux in the offer. > > If my understanding is correct, I agree with Eric's logic and we should > tighten up the mux-exclusive draft. > > Regards, > > _____________ > Roman Shpount > > On Tue, Feb 7, 2017 at 8:15 PM, Eric Rescorla wrote: > >> It seems like that just moves the load onto everyone else who has to >> process both the >> case where you have a=rtcp-mux and the one where you do not. >> >> -Ekr >> >> On Tue, Feb 7, 2017 at 4:26 PM, Roman Shpount wrote: >> >>> Essentially a few test cases less to test. >>> >>> Regards, >>> _____________ >>> Roman Shpount >>> >>> On Tue, Feb 7, 2017 at 6:52 PM, Eric Rescorla wrote: >>> >>>> On Tue, Feb 7, 2017 at 12:38 PM, Roman Shpount >>>> wrote: >>>> >>>>> I want to be able to send rtcp-mux-only. I see plenty of scenarios >>>>> where my solution communicates exclusively with Web browsers. Once they >>>>> implement rtcp-mux-only, given the rate with which browsers are updated, I >>>>> would like, at some point, stop using rtcp-mux instead of inserting legacy >>>>> flag indefinitely. >>>>> >>>> >>>> What resource are you conserving here? It's not exactly consuming a lot >>>> of space in the SDP. >>>> >>>> -Ekr >>>> >>>> >>>> >>>> Regards, >>>>> _____________ >>>>> Roman Shpount >>>>> >>>>> On Tue, Feb 7, 2017 at 3:33 PM, Eric Rescorla wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg < >>>>>> christer.holmberg@ericsson.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >> We had a long discussion about this, with many different >>>>>>> opinions, and it would take some time to >>>>>>> >> go through the archive and check everything. But, one opinion was >>>>>>> that it IS useful to send the >>>>>>> >> attribute, as it indicates support of the mechanism. >>>>>>> > >>>>>>> > What does the other side do with that? >>>>>>> >>>>>>> Well, it knows that it doesn't have to include a=rtcp-mux the next >>>>>>> time it wants to do mux-only. >>>>>>> >>>>>>> Obviously, as you suggested in your original e-mail, if we wouldn't >>>>>>> allow a=rtcp-mux-only without a=rtcp-mux (alt #4) in an offer to begin >>>>>>> with, it doesn't matter. >>>>>>> >>>>>> >>>>>> Yeah, I don't think this is a plausible option. >>>>>> >>>>>> At this point it would be great to hear from anyone who thinks that >>>>>> we should allow >>>>>> a=rtcp-mux-only without a=rtcp-mux.... >>>>>> >>>>>> -Ekr >>>>>> >>>>>> >>>>>>> >>>>>>> > Is there any precedent for this in SDP? >>>>>>> >>>>>>> Not anything I can think of. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> From: Eric Rescorla >>>>>>> Date: Monday 6 February 2017 at 16:32 >>>>>>> To: Christer Holmberg >>>>>>> Cc: "mmusic@ietf.org" >>>>>>> Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg < >>>>>>> christer.holmberg@ericsson.com> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> >>> Following up to myself, I don't think it's sensible for answers >>>>>>> to >>>>>>> >>>contain a=rtcp-mux-only, because either you accepted mux, in >>>>>>> which case >>>>>>> >>>all is good, or you rejected it, in which case it was rejected. >>>>>>> >> >>>>>>> >> While I agree that a=rtcp-mux would be enough in the Answer as >>>>>>> far as >>>>>>> >>indicating mux is concerned, including a=rtcp-mux-only in the >>>>>>> Answer >>>>>>> >>does indicate that the Answerer supports the mux-exclusive >>>>>>> mechanism. >>>>>>> > >>>>>>> > I don't see how that's really that useful >>>>>>> >>>>>>> But what harm does it cause? >>>>>>> >>>>>>> I don't think that's the standard here. We should only send >>>>>>> indicators in SDP when they >>>>>>> do something useful. >>>>>>> >>>>>>> -Ekr >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla >>>>>>> wrote: >>>>>>> >>>>>>> I have been reading the mux-exclusive document and I'm not sure it >>>>>>> says >>>>>>> quite what we want. Specifically, S 4.2 says: >>>>>>> >>>>>>> When an offerer sends the initial offer, if the offerer wants to >>>>>>> indicate exclusive RTP/RTCP multiplexing for RTP-based media, the >>>>>>> offerer MUST associate an SDP 'rtcp-mux-only' attribute with the >>>>>>> associated SDP media description ("m=" line). >>>>>>> >>>>>>> In addition, if the offerer associates an SDP 'rtcp-mux-only' >>>>>>> attribute with an SDP media description ("m=" line), the offerer >>>>>>> MAY >>>>>>> also associate an SDP 'rtcp-mux' attribute with the same SDP media >>>>>>> description ("m=" line), following the procedures in [RFC5761]. >>>>>>> >>>>>>> As I understand this text, the offerer may say the following things: >>>>>>> >>>>>>> 1. No a=rtcp-mux: No muxing. >>>>>>> 2. a=rtcp-mux: I am offering RTCP mux >>>>>>> 3. a=rtcp-mux-only + a=rtcp-mux: I will only do RTCP mux >>>>>>> 4. a=rtcp-mux-only: I will only do RTCP mux (same as #3). >>>>>>> >>>>>>> I don't think the last of these is sensible. No current >>>>>>> implementation >>>>>>> will know what to do with a=rtcp-mux-only w/o a=rtcp-mux, so this >>>>>>> will >>>>>>> result in interop failures. Thus the MAY in the second graf needs to >>>>>>> be >>>>>>> a MUST. >>>>>>> >>>>>>> -Ekr >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>> >>>>>> >>>>> >>>> >>> >> > --001a113e609ad91f58054880e894 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

1. In the offer BOTH rtcp-mux= and rtcp-mux-only MUSTbe included
2. In the answer rtcp-mux MUST be in= cluded or the session should be terminated. rtcp-mux-only MUST NOT be inclu= ded.

This removes any variation on what can and ca= nnot be included in the offer or the answer.

_____________
Roman Shpount

On Tue, Feb 14, 2017 at 4:27 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>
Hi,

Just to make sure I understand. You are suggesting:

1. In the offer, the offerer includes BOTH rtcp-mux-only and rtcp-mux.= Or, is including rtcp-mux still a MAY?

2. In the answerer, the answerer includes ONLY rtcp-mux. rtcp-mux-only= is never used in an answer.

Regards,

Christer

From: Roman Shpount <roman@telurix.com>
Date: Tuesday 14 February 2017 at 0= 0:02
To: Eric Rescorla <ekr@rtfm.com>
Cc: Christer Holmberg <christer.holmb= erg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>

Subject: Re: [MMUSIC] Sending a=3Dr= tcp-mux-only w/o a=3Drtcp-mux

Hi All,

I got the principal question about rtcp-mux-only. Is it needed only as= a hint to SBC while connection is being established?

It it is a hint to SBC, it does not matter that the answering end poin= t does not support it. All it says is that offering end point is not expect= ing any media on rtp port + 1 and will refuse any connection which sends it= , so SBC does not need to allocate an extra port during setup. If this is all, we should not insert rtcp-mux-= only in the answer and always must include both rtcp-mux-only and rtcp-mux = in the offer.

If my understanding is correct, I agree with Eric's logic and we s= hould tighten up the mux-exclusive draft.

Regards,

_____________
Roman Shpount

On Tue, Feb 7, 2017 at 8:15 PM, Eric Rescorla <ekr@rtfm.com><= /span> wrote:
It seems like that just moves the load onto ever= yone else who has to process both the
case where you have a=3Drtcp-mux and the one whe= re you do not.

-Ekr

On Tue, Feb 7, 2017 at 4:26 PM, Roman Shpount <roman@telurix.co= m> wrote:
Essentially a few test cases less to test.

Regards,
_____________
Roman Shpount

On Tue, Feb 7, 2017 at 6:52 PM, Eric Rescorla <ekr@rtfm.com><= /span> wrote:
On Tue, Feb 7, 2017 at 12:38 PM, Roman Shp= ount <roman@telurix.co= m> wrote:
I want to be able to send rtcp-mux-only. I see plenty of s= cenarios where my solution communicates exclusively with Web browsers. Once= they implement rtcp-mux-only, given the rate with which browsers are updat= ed, I would like, at some point, stop using rtcp-mux instead of inserting legacy flag indefinitely.
What resource are you conserving here? It's not exactly consuming = a lot of space in the SDP.

-Ekr



Regards,
_____________
Roman Shpount

On Tue, Feb 7, 2017 at 3:33 PM, Eric Rescorla <ekr@rtfm.com> wrot= e:


On Tue, Feb 7, 2017 at 9:40 AM, Christer H= olmberg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

>> We had a long discussion about this, with many different opi= nions, and it would take some time to
>> go through the archive and check everything. But, one opinion was = that it IS useful to send the
>> attribute, as it indicates support of the mechanism.
>
> What does the other side do with that?

Well, it knows that it doesn't have to include a=3D= rtcp-mux the next time it wants to do mux-only.

Obviously, as you suggested in your original e-mail, if we wouldn't all= ow a=3Drtcp-mux-only without a=3Drtcp-mux (alt #4) in an offer to begin wit= h, it doesn't matter.

Yeah, I don't think this is a plausible option.

At this point it would be great to hear from anyone who thinks that we= should allow
a=3Drtcp-mux-only without a=3Drtcp-mux....

-Ekr
=C2=A0

> Is there any precedent for this in SDP?

Not anything I can think of.

Regards,

Christer


From: Eric Rescorla <e= kr@rtfm.com>
Date: Monday 6 February 2017 at 16:32
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "mmusic@ietf.= org" <mmus= ic@ietf.org>
Subject: Re: [MMUSIC] Sending a=3Drtcp-mux-only w/o a=3Drtcp-mux



On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
Hi,

>>> Following up to myself, I don't think it's sensible fo= r answers to
>>>contain a=3Drtcp-mux-only, because either you accepted mux, in = which case
>>>all is good, or you rejected it, in which case it was rejected.=
>>
>> While I agree that a=3Drtcp-mux would be enough in the Answer as f= ar as
>>indicating mux is concerned, including a=3Drtcp-mux-only in the Ans= wer
>>does indicate that the Answerer supports the mux-exclusive mechanis= m.
>
> I don't see how that's really that useful

But what harm does it cause?

I don't think that's the standard here. We should only send indicat= ors in SDP when they
do something useful.

-Ekr


Regards,

Christer




On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla
<ekr@rtfm.com> = wrote:

I have been reading the mux-exclusive document and I'm not sure it says=
quite what we want. Specifically, S 4.2 says:

=C2=A0 =C2=A0When an offerer sends the initial offer, if the offerer wants = to
=C2=A0 =C2=A0indicate exclusive RTP/RTCP multiplexing for RTP-based media, = the
=C2=A0 =C2=A0offerer MUST associate an SDP 'rtcp-mux-only' attribut= e with the
=C2=A0 =C2=A0associated SDP media description ("m=3D" line).

=C2=A0 =C2=A0In addition, if the offerer associates an SDP 'rtcp-mux-on= ly'
=C2=A0 =C2=A0attribute with an SDP media description ("m=3D" line= ), the offerer MAY
=C2=A0 =C2=A0also associate an SDP 'rtcp-mux' attribute with the sa= me SDP media
=C2=A0 =C2=A0description ("m=3D" line), following the procedures = in [RFC5761].

As I understand this text, the offerer may say the following things:

=C2=A01. No a=3Drtcp-mux: No muxing.
=C2=A02. a=3Drtcp-mux: I am offering RTCP mux
=C2=A03. a=3Drtcp-mux-only + a=3Drtcp-mux: I will only do RTCP mux
=C2=A04. a=3Drtcp-mux-only: I will only do RTCP mux (same as #3).

I don't think the last of these is sensible. No current implementation<= br> will know what to do with a=3Drtcp-mux-only w/o a=3Drtcp-mux, so this will<= br> result in interop failures. Thus the MAY in the second graf needs to be
a MUST.

-Ekr


















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






--001a113e609ad91f58054880e894-- From nobody Tue Feb 14 09:32:29 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162981296CF for ; Tue, 14 Feb 2017 09:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jCJqB3qkUErr for ; Tue, 14 Feb 2017 09:32:24 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F391296D5 for ; Tue, 14 Feb 2017 09:32:22 -0800 (PST) X-AuditID: c1b4fb30-b99fe70000007389-94-58a33f232e89 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 1F.95.29577.32F33A85; Tue, 14 Feb 2017 18:32:20 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0319.002; Tue, 14 Feb 2017 18:32:19 +0100 From: Christer Holmberg To: Roman Shpount , "ben@nostrum.com" Thread-Topic: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux Thread-Index: AQHSfkR3UhfsVBhEwUWv5/2Z0yKCVaFXfBcAgASHPoD//+NbAIAAMCIA///nooCAAVZKgIAAF9KAgABohoCAACCTAIAAAV4AgAA2PgCAAAmMAIAADWsAgAk4I4CAAOGbAIAAZJMAgAARMoA= Date: Tue, 14 Feb 2017 17:32:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFFEF88@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BFEF197@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BFFEF88ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7va6K/eIIg9sfFSzmd55mt1jx+hy7 xdTlj1ksZlyYyuzA4rFkyU8mj1k7n7B4TH7cxuxxa0pBAEsUl01Kak5mWWqRvl0CV0b7xCeM BdueMVVsb9rP0sDYcZepi5GTQ0LAROJD103GLkYuDiGBdYwSWw7vYIJwFjNK7Dr9Bsjh4GAT sJDo/qcN0iAi4CWx4vxcVhCbWcBWYuapi4wgtrCAjcS608uYIWpsJZ5uP8wMMkdEYB6jxIP7 p1hAEiwCqhI7t60E28wr4Cvx8ms31LKXHBJnD18Dm8QpECgx+dcSsA2MAmIS30+tYYLYJi5x 68l8qLMFJJbsOc8MYYtKvHz8jxXCVpJYdPszVH2+xOdtk5khlglKnJz5hGUCo8gsJKNmISmb haRsFtDPzAKaEut36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFSbrqRkV5qUWZycXF+ nl5easkmRmAMHtzy22AH48vnjocYBTgYlXh4P5xcGCHEmlhWXJl7iFGCg1lJhFfKdnGEEG9K YmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxSDYws3XNuGUaFBD4z uZ+QtkL80jrn51eKDAVvTH34rGe/TFbxqYsT9x8w+qXBcvhznLN8IFN4yvU8hpmp80pCkzov /rGz27LoP//+jStuMvQqGy/i/+nQ/qvZ5OE9nej5eq1PD+95kG81L8Dw3ZQHS5Wt4+b0RlqG 3azbkcPku++JoOb9udNj5mgpsRRnJBpqMRcVJwIAZ+RLZb0CAAA= Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 17:32:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BFFEF88ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkJlbiwgd2hhdCBpcyB0aGUgcHJvY2VkdXJlIGZvciBtYWtpbmcgYSBjaGFuZ2UgaW4g dGhlIGRyYWZ0PyBJdOKAmXMgY3VycmVudGx5IGluIHRoZSBSRkMgZWRpdG9ycyBxdWV1ZS4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFu QHRlbHVyaXguY29tXQ0KU2VudDogMTQgRmVicnVhcnkgMjAxNyAxOTozMA0KVG86IENocmlzdGVy IEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogRXJpYyBSZXNj b3JsYSA8ZWtyQHJ0Zm0uY29tPjsgbW11c2ljIFdHIDxtbXVzaWNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW01NVVNJQ10gU2VuZGluZyBhPXJ0Y3AtbXV4LW9ubHkgdy9vIGE9cnRjcC1tdXgNCg0K SGksDQoNCjEuIEluIHRoZSBvZmZlciBCT1RIIHJ0Y3AtbXV4IGFuZCBydGNwLW11eC1vbmx5IE1V U1RiZSBpbmNsdWRlZA0KMi4gSW4gdGhlIGFuc3dlciBydGNwLW11eCBNVVNUIGJlIGluY2x1ZGVk IG9yIHRoZSBzZXNzaW9uIHNob3VsZCBiZSB0ZXJtaW5hdGVkLiBydGNwLW11eC1vbmx5IE1VU1Qg Tk9UIGJlIGluY2x1ZGVkLg0KDQpUaGlzIHJlbW92ZXMgYW55IHZhcmlhdGlvbiBvbiB3aGF0IGNh biBhbmQgY2Fubm90IGJlIGluY2x1ZGVkIGluIHRoZSBvZmZlciBvciB0aGUgYW5zd2VyLg0KDQpf X19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCk9uIFR1ZSwgRmViIDE0LCAyMDE3IGF0IDQ6 MjcgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208 bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNCkp1 c3QgdG8gbWFrZSBzdXJlIEkgdW5kZXJzdGFuZC4gWW91IGFyZSBzdWdnZXN0aW5nOg0KDQoxLiBJ biB0aGUgb2ZmZXIsIHRoZSBvZmZlcmVyIGluY2x1ZGVzIEJPVEggcnRjcC1tdXgtb25seSBhbmQg cnRjcC1tdXguIE9yLCBpcyBpbmNsdWRpbmcgcnRjcC1tdXggc3RpbGwgYSBNQVk/DQoNCjIuIElu IHRoZSBhbnN3ZXJlciwgdGhlIGFuc3dlcmVyIGluY2x1ZGVzIE9OTFkgcnRjcC1tdXguIHJ0Y3At bXV4LW9ubHkgaXMgbmV2ZXIgdXNlZCBpbiBhbiBhbnN3ZXIuDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNCkZyb206IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21h bkB0ZWx1cml4LmNvbT4+DQpEYXRlOiBUdWVzZGF5IDE0IEZlYnJ1YXJ5IDIwMTcgYXQgMDA6MDIN ClRvOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+DQpD YzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4sICJtbXVzaWNAaWV0Zi5vcmc8bWFp bHRvOm1tdXNpY0BpZXRmLm9yZz4iIDxtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRm Lm9yZz4+DQoNClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBTZW5kaW5nIGE9cnRjcC1tdXgtb25seSB3 L28gYT1ydGNwLW11eA0KDQpIaSBBbGwsDQoNCkkgZ290IHRoZSBwcmluY2lwYWwgcXVlc3Rpb24g YWJvdXQgcnRjcC1tdXgtb25seS4gSXMgaXQgbmVlZGVkIG9ubHkgYXMgYSBoaW50IHRvIFNCQyB3 aGlsZSBjb25uZWN0aW9uIGlzIGJlaW5nIGVzdGFibGlzaGVkPw0KDQpJdCBpdCBpcyBhIGhpbnQg dG8gU0JDLCBpdCBkb2VzIG5vdCBtYXR0ZXIgdGhhdCB0aGUgYW5zd2VyaW5nIGVuZCBwb2ludCBk b2VzIG5vdCBzdXBwb3J0IGl0LiBBbGwgaXQgc2F5cyBpcyB0aGF0IG9mZmVyaW5nIGVuZCBwb2lu dCBpcyBub3QgZXhwZWN0aW5nIGFueSBtZWRpYSBvbiBydHAgcG9ydCArIDEgYW5kIHdpbGwgcmVm dXNlIGFueSBjb25uZWN0aW9uIHdoaWNoIHNlbmRzIGl0LCBzbyBTQkMgZG9lcyBub3QgbmVlZCB0 byBhbGxvY2F0ZSBhbiBleHRyYSBwb3J0IGR1cmluZyBzZXR1cC4gSWYgdGhpcyBpcyBhbGwsIHdl IHNob3VsZCBub3QgaW5zZXJ0IHJ0Y3AtbXV4LW9ubHkgaW4gdGhlIGFuc3dlciBhbmQgYWx3YXlz IG11c3QgaW5jbHVkZSBib3RoIHJ0Y3AtbXV4LW9ubHkgYW5kIHJ0Y3AtbXV4IGluIHRoZSBvZmZl ci4NCg0KSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCBJIGFncmVlIHdpdGggRXJpYydz IGxvZ2ljIGFuZCB3ZSBzaG91bGQgdGlnaHRlbiB1cCB0aGUgbXV4LWV4Y2x1c2l2ZSBkcmFmdC4N Cg0KUmVnYXJkcywNCg0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQpPbiBUdWUsIEZl YiA3LCAyMDE3IGF0IDg6MTUgUE0sIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86 ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQpJdCBzZWVtcyBsaWtlIHRoYXQganVzdCBtb3ZlcyB0aGUg bG9hZCBvbnRvIGV2ZXJ5b25lIGVsc2Ugd2hvIGhhcyB0byBwcm9jZXNzIGJvdGggdGhlDQpjYXNl IHdoZXJlIHlvdSBoYXZlIGE9cnRjcC1tdXggYW5kIHRoZSBvbmUgd2hlcmUgeW91IGRvIG5vdC4N Cg0KLUVrcg0KDQpPbiBUdWUsIEZlYiA3LCAyMDE3IGF0IDQ6MjYgUE0sIFJvbWFuIFNocG91bnQg PHJvbWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdyb3RlOg0KRXNz ZW50aWFsbHkgYSBmZXcgdGVzdCBjYXNlcyBsZXNzIHRvIHRlc3QuDQoNClJlZ2FyZHMsDQpfX19f X19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCk9uIFR1ZSwgRmViIDcsIDIwMTcgYXQgNjo1MiBQ TSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90 ZToNCk9uIFR1ZSwgRmViIDcsIDIwMTcgYXQgMTI6MzggUE0sIFJvbWFuIFNocG91bnQgPHJvbWFu QHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdyb3RlOg0KSSB3YW50IHRv IGJlIGFibGUgdG8gc2VuZCBydGNwLW11eC1vbmx5LiBJIHNlZSBwbGVudHkgb2Ygc2NlbmFyaW9z IHdoZXJlIG15IHNvbHV0aW9uIGNvbW11bmljYXRlcyBleGNsdXNpdmVseSB3aXRoIFdlYiBicm93 c2Vycy4gT25jZSB0aGV5IGltcGxlbWVudCBydGNwLW11eC1vbmx5LCBnaXZlbiB0aGUgcmF0ZSB3 aXRoIHdoaWNoIGJyb3dzZXJzIGFyZSB1cGRhdGVkLCBJIHdvdWxkIGxpa2UsIGF0IHNvbWUgcG9p bnQsIHN0b3AgdXNpbmcgcnRjcC1tdXggaW5zdGVhZCBvZiBpbnNlcnRpbmcgbGVnYWN5IGZsYWcg aW5kZWZpbml0ZWx5Lg0KDQpXaGF0IHJlc291cmNlIGFyZSB5b3UgY29uc2VydmluZyBoZXJlPyBJ dCdzIG5vdCBleGFjdGx5IGNvbnN1bWluZyBhIGxvdCBvZiBzcGFjZSBpbiB0aGUgU0RQLg0KDQot RWtyDQoNCg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQpPbiBU dWUsIEZlYiA3LCAyMDE3IGF0IDM6MzMgUE0sIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxt YWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQoNCg0KT24gVHVlLCBGZWIgNywgMjAxNyBhdCA5 OjQwIEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQo+ PiBXZSBoYWQgYSBsb25nIGRpc2N1c3Npb24gYWJvdXQgdGhpcywgd2l0aCBtYW55IGRpZmZlcmVu dCBvcGluaW9ucywgYW5kIGl0IHdvdWxkIHRha2Ugc29tZSB0aW1lIHRvDQo+PiBnbyB0aHJvdWdo IHRoZSBhcmNoaXZlIGFuZCBjaGVjayBldmVyeXRoaW5nLiBCdXQsIG9uZSBvcGluaW9uIHdhcyB0 aGF0IGl0IElTIHVzZWZ1bCB0byBzZW5kIHRoZQ0KPj4gYXR0cmlidXRlLCBhcyBpdCBpbmRpY2F0 ZXMgc3VwcG9ydCBvZiB0aGUgbWVjaGFuaXNtLg0KPg0KPiBXaGF0IGRvZXMgdGhlIG90aGVyIHNp ZGUgZG8gd2l0aCB0aGF0Pw0KDQpXZWxsLCBpdCBrbm93cyB0aGF0IGl0IGRvZXNuJ3QgaGF2ZSB0 byBpbmNsdWRlIGE9cnRjcC1tdXggdGhlIG5leHQgdGltZSBpdCB3YW50cyB0byBkbyBtdXgtb25s eS4NCg0KT2J2aW91c2x5LCBhcyB5b3Ugc3VnZ2VzdGVkIGluIHlvdXIgb3JpZ2luYWwgZS1tYWls LCBpZiB3ZSB3b3VsZG4ndCBhbGxvdyBhPXJ0Y3AtbXV4LW9ubHkgd2l0aG91dCBhPXJ0Y3AtbXV4 IChhbHQgIzQpIGluIGFuIG9mZmVyIHRvIGJlZ2luIHdpdGgsIGl0IGRvZXNuJ3QgbWF0dGVyLg0K DQpZZWFoLCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYSBwbGF1c2libGUgb3B0aW9uLg0KDQpBdCB0 aGlzIHBvaW50IGl0IHdvdWxkIGJlIGdyZWF0IHRvIGhlYXIgZnJvbSBhbnlvbmUgd2hvIHRoaW5r cyB0aGF0IHdlIHNob3VsZCBhbGxvdw0KYT1ydGNwLW11eC1vbmx5IHdpdGhvdXQgYT1ydGNwLW11 eC4uLi4NCg0KLUVrcg0KDQoNCj4gSXMgdGhlcmUgYW55IHByZWNlZGVudCBmb3IgdGhpcyBpbiBT RFA/DQoNCk5vdCBhbnl0aGluZyBJIGNhbiB0aGluayBvZi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KDQpGcm9tOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZt LmNvbT4+DQpEYXRlOiBNb25kYXkgNiBGZWJydWFyeSAyMDE3IGF0IDE2OjMyDQpUbzogQ2hyaXN0 ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NCkNjOiAibW11c2ljQGlldGYub3JnPG1haWx0bzpt bXVzaWNAaWV0Zi5vcmc+IiA8bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIFNlbmRpbmcgYT1ydGNwLW11eC1vbmx5IHcvbyBhPXJ0 Y3AtbXV4DQoNCg0KDQpPbiBNb24sIEZlYiA2LCAyMDE3IGF0IDU6NTcgQU0sIENocmlzdGVyIEhv bG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNCj4+PiBGb2xsb3dpbmcgdXAgdG8g bXlzZWxmLCBJIGRvbid0IHRoaW5rIGl0J3Mgc2Vuc2libGUgZm9yIGFuc3dlcnMgdG8NCj4+PmNv bnRhaW4gYT1ydGNwLW11eC1vbmx5LCBiZWNhdXNlIGVpdGhlciB5b3UgYWNjZXB0ZWQgbXV4LCBp biB3aGljaCBjYXNlDQo+Pj5hbGwgaXMgZ29vZCwgb3IgeW91IHJlamVjdGVkIGl0LCBpbiB3aGlj aCBjYXNlIGl0IHdhcyByZWplY3RlZC4NCj4+DQo+PiBXaGlsZSBJIGFncmVlIHRoYXQgYT1ydGNw LW11eCB3b3VsZCBiZSBlbm91Z2ggaW4gdGhlIEFuc3dlciBhcyBmYXIgYXMNCj4+aW5kaWNhdGlu ZyBtdXggaXMgY29uY2VybmVkLCBpbmNsdWRpbmcgYT1ydGNwLW11eC1vbmx5IGluIHRoZSBBbnN3 ZXINCj4+ZG9lcyBpbmRpY2F0ZSB0aGF0IHRoZSBBbnN3ZXJlciBzdXBwb3J0cyB0aGUgbXV4LWV4 Y2x1c2l2ZSBtZWNoYW5pc20uDQo+DQo+IEkgZG9uJ3Qgc2VlIGhvdyB0aGF0J3MgcmVhbGx5IHRo YXQgdXNlZnVsDQoNCkJ1dCB3aGF0IGhhcm0gZG9lcyBpdCBjYXVzZT8NCg0KSSBkb24ndCB0aGlu ayB0aGF0J3MgdGhlIHN0YW5kYXJkIGhlcmUuIFdlIHNob3VsZCBvbmx5IHNlbmQgaW5kaWNhdG9y cyBpbiBTRFAgd2hlbiB0aGV5DQpkbyBzb21ldGhpbmcgdXNlZnVsLg0KDQotRWtyDQoNCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KT24gRnJpLCBGZWIgMywgMjAxNyBhdCA5OjM4IEFN LCBFcmljIFJlc2NvcmxhDQo8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90 ZToNCg0KSSBoYXZlIGJlZW4gcmVhZGluZyB0aGUgbXV4LWV4Y2x1c2l2ZSBkb2N1bWVudCBhbmQg SSdtIG5vdCBzdXJlIGl0IHNheXMNCnF1aXRlIHdoYXQgd2Ugd2FudC4gU3BlY2lmaWNhbGx5LCBT IDQuMiBzYXlzOg0KDQogICBXaGVuIGFuIG9mZmVyZXIgc2VuZHMgdGhlIGluaXRpYWwgb2ZmZXIs IGlmIHRoZSBvZmZlcmVyIHdhbnRzIHRvDQogICBpbmRpY2F0ZSBleGNsdXNpdmUgUlRQL1JUQ1Ag bXVsdGlwbGV4aW5nIGZvciBSVFAtYmFzZWQgbWVkaWEsIHRoZQ0KICAgb2ZmZXJlciBNVVNUIGFz c29jaWF0ZSBhbiBTRFAgJ3J0Y3AtbXV4LW9ubHknIGF0dHJpYnV0ZSB3aXRoIHRoZQ0KICAgYXNz b2NpYXRlZCBTRFAgbWVkaWEgZGVzY3JpcHRpb24gKCJtPSIgbGluZSkuDQoNCiAgIEluIGFkZGl0 aW9uLCBpZiB0aGUgb2ZmZXJlciBhc3NvY2lhdGVzIGFuIFNEUCAncnRjcC1tdXgtb25seScNCiAg IGF0dHJpYnV0ZSB3aXRoIGFuIFNEUCBtZWRpYSBkZXNjcmlwdGlvbiAoIm09IiBsaW5lKSwgdGhl IG9mZmVyZXIgTUFZDQogICBhbHNvIGFzc29jaWF0ZSBhbiBTRFAgJ3J0Y3AtbXV4JyBhdHRyaWJ1 dGUgd2l0aCB0aGUgc2FtZSBTRFAgbWVkaWENCiAgIGRlc2NyaXB0aW9uICgibT0iIGxpbmUpLCBm b2xsb3dpbmcgdGhlIHByb2NlZHVyZXMgaW4gW1JGQzU3NjFdLg0KDQpBcyBJIHVuZGVyc3RhbmQg dGhpcyB0ZXh0LCB0aGUgb2ZmZXJlciBtYXkgc2F5IHRoZSBmb2xsb3dpbmcgdGhpbmdzOg0KDQog MS4gTm8gYT1ydGNwLW11eDogTm8gbXV4aW5nLg0KIDIuIGE9cnRjcC1tdXg6IEkgYW0gb2ZmZXJp bmcgUlRDUCBtdXgNCiAzLiBhPXJ0Y3AtbXV4LW9ubHkgKyBhPXJ0Y3AtbXV4OiBJIHdpbGwgb25s eSBkbyBSVENQIG11eA0KIDQuIGE9cnRjcC1tdXgtb25seTogSSB3aWxsIG9ubHkgZG8gUlRDUCBt dXggKHNhbWUgYXMgIzMpLg0KDQpJIGRvbid0IHRoaW5rIHRoZSBsYXN0IG9mIHRoZXNlIGlzIHNl bnNpYmxlLiBObyBjdXJyZW50IGltcGxlbWVudGF0aW9uDQp3aWxsIGtub3cgd2hhdCB0byBkbyB3 aXRoIGE9cnRjcC1tdXgtb25seSB3L28gYT1ydGNwLW11eCwgc28gdGhpcyB3aWxsDQpyZXN1bHQg aW4gaW50ZXJvcCBmYWlsdXJlcy4gVGh1cyB0aGUgTUFZIGluIHRoZSBzZWNvbmQgZ3JhZiBuZWVk cyB0byBiZQ0KYSBNVVNULg0KDQotRWtyDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNp YyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KDQoNCg0KDQoN Cg== --_000_7594FB04B1934943A5C02806D1A2204B4BFFEF88ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLm0tNjg1Nzc1OTE2MTUx ODQ0MDIwNW01MzE0NjcwODY5ODE0NDA1ODAxbS05MDE3NjQwMjk0NTA0NzM5Njg3aG9lbnpiDQoJ e21zby1zdHlsZS1uYW1lOm1fLTY4NTc3NTkxNjE1MTg0NDAyMDVtXzUzMTQ2NzA4Njk4MTQ0MDU4 MDFtXy05MDE3NjQwMjk0NTA0NzM5Njg3aG9lbnpiO30NCnNwYW4ubS02ODU3NzU5MTYxNTE4NDQw MjA1bTUzMTQ2NzA4Njk4MTQ0MDU4MDFtLTkwMTc2NDAyOTQ1MDQ3Mzk2ODdtNjcxMDY0NDI3NjIx NTA1OTE5bS0yNzk0MTg4MDM5NDU4ODYyMzIxaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOm1fLTY4 NTc3NTkxNjE1MTg0NDAyMDVtXzUzMTQ2NzA4Njk4MTQ0MDU4MDFtXy05MDE3NjQwMjk0NTA0NzM5 Njg3bV82NzEwNjQ0Mjc2MjE1MDU5MTltXy0yNzk0MTg4MDM5NDU4ODYyMzIxaG9lbnpiO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhp LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QmVuLCB3aGF0IGlzIHRo ZSBwcm9jZWR1cmUgZm9yIG1ha2luZyBhIGNoYW5nZSBpbiB0aGUgZHJhZnQ/IEl04oCZcyBjdXJy ZW50bHkgaW4gdGhlIFJGQyBlZGl0b3JzIHF1ZXVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9h PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9tYW4g U2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE0 IEZlYnJ1YXJ5IDIwMTcgMTk6MzA8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnICZs dDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBFcmlj IFJlc2NvcmxhICZsdDtla3JAcnRmbS5jb20mZ3Q7OyBtbXVzaWMgV0cgJmx0O21tdXNpY0BpZXRm Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIFNlbmRpbmcgYT1ydGNw LW11eC1vbmx5IHcvbyBhPXJ0Y3AtbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjEuIEluIHRoZSBvZmZlciBCT1RIIHJ0Y3AtbXV4IGFuZCBydGNwLW11eC1vbmx5IE1V U1RiZSBpbmNsdWRlZDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjIuIEluIHRoZSBhbnN3ZXIgcnRjcC1tdXggTVVTVCBiZSBpbmNsdWRlZCBvciB0aGUgc2Vzc2lv biBzaG91bGQgYmUgdGVybWluYXRlZC4gcnRjcC1tdXgtb25seSBNVVNUIE5PVCBiZSBpbmNsdWRl ZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhpcyByZW1vdmVzIGFueSB2YXJpYXRpb24gb24gd2hhdCBjYW4gYW5kIGNhbm5vdCBiZSBpbmNs dWRlZCBpbiB0aGUgb2ZmZXIgb3IgdGhlIGFuc3dlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19f X19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIgMTQsIDIwMTcgYXQgNDoyNyBBTSwgQ2hyaXN0ZXIg SG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SGksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPkp1c3QgdG8gbWFrZSBzdXJlIEkgdW5kZXJzdGFuZC4gWW91IGFyZSBzdWdnZXN0aW5nOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4xLiBJbiB0aGUgb2ZmZXIsIHRoZSBvZmZlcmVyIGluY2x1ZGVzIEJPVEggcnRj cC1tdXgtb25seSBhbmQgcnRjcC1tdXguIE9yLCBpcyBpbmNsdWRpbmcgcnRjcC1tdXggc3RpbGwg YSBNQVk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPjIuIEluIHRoZSBhbnN3ZXJlciwgdGhlIGFuc3dlcmVyIGluY2x1 ZGVzIE9OTFkgcnRjcC1tdXguIHJ0Y3AtbXV4LW9ubHkgaXMgbmV2ZXIgdXNlZCBpbiBhbiBhbnN3 ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNocmlzdGVyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5Sb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVs dXJpeC5jb20iIHRhcmdldD0iX2JsYW5rIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7PGJyPg0K PGI+RGF0ZTogPC9iPlR1ZXNkYXkgMTQgRmVicnVhcnkgMjAxNyBhdCAwMDowMjxicj4NCjxiPlRv OiA8L2I+RXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5DaHJpc3Rl ciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4m Z3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bW11c2ljQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT4mZ3Q7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW01NVVNJQ10g U2VuZGluZyBhPXJ0Y3AtbXV4LW9ubHkgdy9vIGE9cnRjcC1tdXg8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5IaSBBbGwsDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgZ290 IHRoZSBwcmluY2lwYWwgcXVlc3Rpb24gYWJvdXQgcnRjcC1tdXgtb25seS4gSXMgaXQgbmVlZGVk IG9ubHkgYXMgYSBoaW50IHRvIFNCQyB3aGlsZSBjb25uZWN0aW9uIGlzIGJlaW5nIGVzdGFibGlz aGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5JdCBpdCBpcyBhIGhpbnQgdG8gU0JDLCBpdCBkb2VzIG5vdCBtYXR0 ZXIgdGhhdCB0aGUgYW5zd2VyaW5nIGVuZCBwb2ludCBkb2VzIG5vdCBzdXBwb3J0IGl0LiBBbGwg aXQgc2F5cyBpcyB0aGF0IG9mZmVyaW5nIGVuZCBwb2ludCBpcyBub3QgZXhwZWN0aW5nIGFueSBt ZWRpYSBvbg0KIHJ0cCBwb3J0ICYjNDM7IDEgYW5kIHdpbGwgcmVmdXNlIGFueSBjb25uZWN0aW9u IHdoaWNoIHNlbmRzIGl0LCBzbyBTQkMgZG9lcyBub3QgbmVlZCB0byBhbGxvY2F0ZSBhbiBleHRy YSBwb3J0IGR1cmluZyBzZXR1cC4gSWYgdGhpcyBpcyBhbGwsIHdlIHNob3VsZCBub3QgaW5zZXJ0 IHJ0Y3AtbXV4LW9ubHkgaW4gdGhlIGFuc3dlciBhbmQgYWx3YXlzIG11c3QgaW5jbHVkZSBib3Ro IHJ0Y3AtbXV4LW9ubHkgYW5kIHJ0Y3AtbXV4IGluIHRoZSBvZmZlci48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SWYg bXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCBJIGFncmVlIHdpdGggRXJpYydzIGxvZ2ljIGFu ZCB3ZSBzaG91bGQgdGlnaHRlbiB1cCB0aGUgbXV4LWV4Y2x1c2l2ZSBkcmFmdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGJyIGNs ZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPl9fX19fX19fX19fX188 YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+T24gVHVlLCBGZWIgNywgMjAxNyBhdCA4OjE1IFBNLCBF cmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9i bGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5JdCBzZWVtcyBsaWtlIHRoYXQganVzdCBtb3ZlcyB0aGUgbG9h ZCBvbnRvIGV2ZXJ5b25lIGVsc2Ugd2hvIGhhcyB0byBwcm9jZXNzIGJvdGggdGhlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5jYXNlIHdoZXJlIHlvdSBoYXZlIGE9cnRjcC1tdXggYW5k IHRoZSBvbmUgd2hlcmUgeW91IGRvIG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LUVrcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5PbiBUdWUsIEZlYiA3LCAyMDE3IGF0IDQ6MjYgUE0sIFJvbWFu IFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPkVzc2VudGlhbGx5IGEgZmV3IHRlc3QgY2FzZXMgbGVzcyB0byB0 ZXN0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5SZWdhcmRzLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5fX19fX19fX19fX19fPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojODg4ODg4Ij48YnI+ DQo8c3BhbiBjbGFzcz0ibS02ODU3NzU5MTYxNTE4NDQwMjA1bTUzMTQ2NzA4Njk4MTQ0MDU4MDFt LTkwMTc2NDAyOTQ1MDQ3Mzk2ODdob2VuemIiPlJvbWFuIFNocG91bnQ8L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PbiBUdWUsIEZl YiA3LCAyMDE3IGF0IDY6NTIgUE0sIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpl a3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PbiBUdWUs IEZlYiA3LCAyMDE3IGF0IDEyOjM4IFBNLCBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWls dG86cm9tYW5AdGVsdXJpeC5jb20iIHRhcmdldD0iX2JsYW5rIj5yb21hbkB0ZWx1cml4LmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JIHdhbnQg dG8gYmUgYWJsZSB0byBzZW5kIHJ0Y3AtbXV4LW9ubHkuIEkgc2VlIHBsZW50eSBvZiBzY2VuYXJp b3Mgd2hlcmUgbXkgc29sdXRpb24gY29tbXVuaWNhdGVzIGV4Y2x1c2l2ZWx5IHdpdGggV2ViIGJy b3dzZXJzLiBPbmNlIHRoZXkgaW1wbGVtZW50IHJ0Y3AtbXV4LW9ubHksDQogZ2l2ZW4gdGhlIHJh dGUgd2l0aCB3aGljaCBicm93c2VycyBhcmUgdXBkYXRlZCwgSSB3b3VsZCBsaWtlLCBhdCBzb21l IHBvaW50LCBzdG9wIHVzaW5nIHJ0Y3AtbXV4IGluc3RlYWQgb2YgaW5zZXJ0aW5nIGxlZ2FjeSBm bGFnIGluZGVmaW5pdGVseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+V2hhdCByZXNvdXJj ZSBhcmUgeW91IGNvbnNlcnZpbmcgaGVyZT8gSXQncyBub3QgZXhhY3RseSBjb25zdW1pbmcgYSBs b3Qgb2Ygc3BhY2UgaW4gdGhlIFNEUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LUVrcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlJlZ2FyZHMs DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPl9fX19fX19fX19fX188L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJtLTY4 NTc3NTkxNjE1MTg0NDAyMDVtNTMxNDY3MDg2OTgxNDQwNTgwMW0tOTAxNzY0MDI5NDUwNDczOTY4 N202NzEwNjQ0Mjc2MjE1MDU5MTltLTI3OTQxODgwMzk0NTg4NjIzMjFob2VuemIiPlJvbWFuIFNo cG91bnQ8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5PbiBUdWUsIEZlYiA3LCAyMDE3IGF0IDM6MzMgUE0sIEVyaWMgUmVzY29ybGEg Jmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRm bS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+T24gVHVlLCBGZWIgNywgMjAxNyBhdCA5 OjQwIEFNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhp LDxicj4NCjxicj4NCiZndDsmZ3Q7IFdlIGhhZCBhIGxvbmcgZGlzY3Vzc2lvbiBhYm91dCB0aGlz LCB3aXRoIG1hbnkgZGlmZmVyZW50IG9waW5pb25zLCBhbmQgaXQgd291bGQgdGFrZSBzb21lIHRp bWUgdG88YnI+DQomZ3Q7Jmd0OyBnbyB0aHJvdWdoIHRoZSBhcmNoaXZlIGFuZCBjaGVjayBldmVy eXRoaW5nLiBCdXQsIG9uZSBvcGluaW9uIHdhcyB0aGF0IGl0IElTIHVzZWZ1bCB0byBzZW5kIHRo ZTxicj4NCiZndDsmZ3Q7IGF0dHJpYnV0ZSwgYXMgaXQgaW5kaWNhdGVzIHN1cHBvcnQgb2YgdGhl IG1lY2hhbmlzbS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaGF0IGRvZXMgdGhlIG90aGVyIHNpZGUg ZG8gd2l0aCB0aGF0Pzxicj4NCjxicj4NCldlbGwsIGl0IGtub3dzIHRoYXQgaXQgZG9lc24ndCBo YXZlIHRvIGluY2x1ZGUgYT1ydGNwLW11eCB0aGUgbmV4dCB0aW1lIGl0IHdhbnRzIHRvIGRvIG11 eC1vbmx5Ljxicj4NCjxicj4NCk9idmlvdXNseSwgYXMgeW91IHN1Z2dlc3RlZCBpbiB5b3VyIG9y aWdpbmFsIGUtbWFpbCwgaWYgd2Ugd291bGRuJ3QgYWxsb3cgYT1ydGNwLW11eC1vbmx5IHdpdGhv dXQgYT1ydGNwLW11eCAoYWx0ICM0KSBpbiBhbiBvZmZlciB0byBiZWdpbiB3aXRoLCBpdCBkb2Vz bid0IG1hdHRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlllYWgsIEkgZG9uJ3QgdGhpbmsgdGhpcyBp cyBhIHBsYXVzaWJsZSBvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkF0IHRoaXMgcG9pbnQgaXQgd291bGQg YmUgZ3JlYXQgdG8gaGVhciBmcm9tIGFueW9uZSB3aG8gdGhpbmtzIHRoYXQgd2Ugc2hvdWxkIGFs bG93PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5hPXJ0Y3AtbXV4LW9ubHkgd2l0aG91 dCBhPXJ0Y3AtbXV4Li4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4tRWtyPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+PGJyPg0KJmd0OyBJcyB0aGVyZSBhbnkgcHJlY2VkZW50IGZvciB0aGlzIGluIFNE UD88YnI+DQo8YnI+DQpOb3QgYW55dGhpbmcgSSBjYW4gdGhpbmsgb2YuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGJyPg0KUmVnYXJk cyw8YnI+DQo8YnI+DQpDaHJpc3Rlcjxicj4NCjxicj4NCjxicj4NCkZyb206IEVyaWMgUmVzY29y bGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JA cnRmbS5jb208L2E+Jmd0Ozxicj4NCkRhdGU6IE1vbmRheSA2IEZlYnJ1YXJ5IDIwMTcgYXQgMTY6 MzI8YnI+DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCkNjOiAmcXVvdDs8YSBocmVmPSJtYWlsdG86bW11 c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNp Y0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIFNlbmRpbmcgYT1y dGNwLW11eC1vbmx5IHcvbyBhPXJ0Y3AtbXV4PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gTW9u LCBGZWIgNiwgMjAxNyBhdCA1OjU3IEFNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCkhpLDxicj4N Cjxicj4NCiZndDsmZ3Q7Jmd0OyBGb2xsb3dpbmcgdXAgdG8gbXlzZWxmLCBJIGRvbid0IHRoaW5r IGl0J3Mgc2Vuc2libGUgZm9yIGFuc3dlcnMgdG88YnI+DQomZ3Q7Jmd0OyZndDtjb250YWluIGE9 cnRjcC1tdXgtb25seSwgYmVjYXVzZSBlaXRoZXIgeW91IGFjY2VwdGVkIG11eCwgaW4gd2hpY2gg Y2FzZTxicj4NCiZndDsmZ3Q7Jmd0O2FsbCBpcyBnb29kLCBvciB5b3UgcmVqZWN0ZWQgaXQsIGlu IHdoaWNoIGNhc2UgaXQgd2FzIHJlamVjdGVkLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg V2hpbGUgSSBhZ3JlZSB0aGF0IGE9cnRjcC1tdXggd291bGQgYmUgZW5vdWdoIGluIHRoZSBBbnN3 ZXIgYXMgZmFyIGFzPGJyPg0KJmd0OyZndDtpbmRpY2F0aW5nIG11eCBpcyBjb25jZXJuZWQsIGlu Y2x1ZGluZyBhPXJ0Y3AtbXV4LW9ubHkgaW4gdGhlIEFuc3dlcjxicj4NCiZndDsmZ3Q7ZG9lcyBp bmRpY2F0ZSB0aGF0IHRoZSBBbnN3ZXJlciBzdXBwb3J0cyB0aGUgbXV4LWV4Y2x1c2l2ZSBtZWNo YW5pc20uPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBkb24ndCBzZWUgaG93IHRoYXQncyByZWFsbHkg dGhhdCB1c2VmdWw8YnI+DQo8YnI+DQpCdXQgd2hhdCBoYXJtIGRvZXMgaXQgY2F1c2U/PGJyPg0K PGJyPg0KSSBkb24ndCB0aGluayB0aGF0J3MgdGhlIHN0YW5kYXJkIGhlcmUuIFdlIHNob3VsZCBv bmx5IHNlbmQgaW5kaWNhdG9ycyBpbiBTRFAgd2hlbiB0aGV5PGJyPg0KZG8gc29tZXRoaW5nIHVz ZWZ1bC48YnI+DQo8YnI+DQotRWtyPGJyPg0KPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+ DQpDaHJpc3Rlcjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCk9uIEZyaSwgRmViIDMsIDIw MTcgYXQgOTozOCBBTSwgRXJpYyBSZXNjb3JsYTxicj4NCiZsdDs8YSBocmVmPSJtYWlsdG86ZWty QHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PGJy Pg0KPGJyPg0KSSBoYXZlIGJlZW4gcmVhZGluZyB0aGUgbXV4LWV4Y2x1c2l2ZSBkb2N1bWVudCBh bmQgSSdtIG5vdCBzdXJlIGl0IHNheXM8YnI+DQpxdWl0ZSB3aGF0IHdlIHdhbnQuIFNwZWNpZmlj YWxseSwgUyA0LjIgc2F5czo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7V2hlbiBhbiBvZmZlcmVy IHNlbmRzIHRoZSBpbml0aWFsIG9mZmVyLCBpZiB0aGUgb2ZmZXJlciB3YW50cyB0bzxicj4NCiZu YnNwOyAmbmJzcDtpbmRpY2F0ZSBleGNsdXNpdmUgUlRQL1JUQ1AgbXVsdGlwbGV4aW5nIGZvciBS VFAtYmFzZWQgbWVkaWEsIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtvZmZlcmVyIE1VU1QgYXNzb2Np YXRlIGFuIFNEUCAncnRjcC1tdXgtb25seScgYXR0cmlidXRlIHdpdGggdGhlPGJyPg0KJm5ic3A7 ICZuYnNwO2Fzc29jaWF0ZWQgU0RQIG1lZGlhIGRlc2NyaXB0aW9uICgmcXVvdDttPSZxdW90OyBs aW5lKS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7SW4gYWRkaXRpb24sIGlmIHRoZSBvZmZlcmVy IGFzc29jaWF0ZXMgYW4gU0RQICdydGNwLW11eC1vbmx5Jzxicj4NCiZuYnNwOyAmbmJzcDthdHRy aWJ1dGUgd2l0aCBhbiBTRFAgbWVkaWEgZGVzY3JpcHRpb24gKCZxdW90O209JnF1b3Q7IGxpbmUp LCB0aGUgb2ZmZXJlciBNQVk8YnI+DQombmJzcDsgJm5ic3A7YWxzbyBhc3NvY2lhdGUgYW4gU0RQ ICdydGNwLW11eCcgYXR0cmlidXRlIHdpdGggdGhlIHNhbWUgU0RQIG1lZGlhPGJyPg0KJm5ic3A7 ICZuYnNwO2Rlc2NyaXB0aW9uICgmcXVvdDttPSZxdW90OyBsaW5lKSwgZm9sbG93aW5nIHRoZSBw cm9jZWR1cmVzIGluIFtSRkM1NzYxXS48YnI+DQo8YnI+DQpBcyBJIHVuZGVyc3RhbmQgdGhpcyB0 ZXh0LCB0aGUgb2ZmZXJlciBtYXkgc2F5IHRoZSBmb2xsb3dpbmcgdGhpbmdzOjxicj4NCjxicj4N CiZuYnNwOzEuIE5vIGE9cnRjcC1tdXg6IE5vIG11eGluZy48YnI+DQombmJzcDsyLiBhPXJ0Y3At bXV4OiBJIGFtIG9mZmVyaW5nIFJUQ1AgbXV4PGJyPg0KJm5ic3A7My4gYT1ydGNwLW11eC1vbmx5 ICYjNDM7IGE9cnRjcC1tdXg6IEkgd2lsbCBvbmx5IGRvIFJUQ1AgbXV4PGJyPg0KJm5ic3A7NC4g YT1ydGNwLW11eC1vbmx5OiBJIHdpbGwgb25seSBkbyBSVENQIG11eCAoc2FtZSBhcyAjMykuPGJy Pg0KPGJyPg0KSSBkb24ndCB0aGluayB0aGUgbGFzdCBvZiB0aGVzZSBpcyBzZW5zaWJsZS4gTm8g Y3VycmVudCBpbXBsZW1lbnRhdGlvbjxicj4NCndpbGwga25vdyB3aGF0IHRvIGRvIHdpdGggYT1y dGNwLW11eC1vbmx5IHcvbyBhPXJ0Y3AtbXV4LCBzbyB0aGlzIHdpbGw8YnI+DQpyZXN1bHQgaW4g aW50ZXJvcCBmYWlsdXJlcy4gVGh1cyB0aGUgTUFZIGluIHRoZSBzZWNvbmQgZ3JhZiBuZWVkcyB0 byBiZTxicj4NCmEgTVVTVC48YnI+DQo8YnI+DQotRWtyPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2lj IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bXVzaWM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4BFFEF88ESESSMB209erics_-- From nobody Tue Feb 14 10:14:38 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C811296DE for ; Tue, 14 Feb 2017 10:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCxA6rmq2PRf for ; Tue, 14 Feb 2017 10:14:35 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981CF129689 for ; Tue, 14 Feb 2017 10:14:35 -0800 (PST) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-03v.sys.comcast.net with SMTP id dhcNcCd1VyXuHdhcYcKV6x; Tue, 14 Feb 2017 18:14:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1487096075; bh=n0ycFctO2Vu95pnvkaE2k5QXP/QeIDJn7aSfIguz0jo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=BifkSG/d6FTwauHFsIsS/EEvHZ1N6RNd5giMXyqgcNeront3oEd91/r3w2DKT0Abw rh7pDrdET/hvizu+i1qPACHHn3iN7CAw88mYPSCqCNbt/CmbHSnbZ5mFy5FKZleyVC UjSwmYHnP5zHcaM4d++QUOjUqXsIUeSdOJylHpHtIomWqzwkvcz7i0jlKuxBBPejU7 qjDrZ4vOL95JpDkjc6mrGy6/zzSzJYWpKNDXKvVn7bJK1KY8xTewG/sGjlZhbCVPyL ZN4VI8swJ3wzGesEw9UTIH5Xp10jT9d+qJhgz6sEnnatramrfdsONITaHlaFVCf/NY rGwnsCoBx9hKA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-01v.sys.comcast.net with SMTP id dhcXcYkrffrQWdhcYcJJDN; Tue, 14 Feb 2017 18:14:34 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4BFEF197@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <0db4d135-fbd1-7051-ab65-c76cf8ca6488@comcast.net> Date: Tue, 14 Feb 2017 13:14:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfBK+YCFsxXqDKVr7sYpbdSa1iTi8CLUhx9dVT59unHq2/wkLJAYleTNm4ecGoW5Zuo3E1UEbCzchdWXt4Bj2kfYY48yEfBjriVMM6YJRp2lF2qaZR9Lh 2u+kA7keApfRKGHnlTebEXl/lecVs2ombQk39JO75ZWzmbbiW3YJ+/Qvna0zXMTcDYzz/kvrUTivig== Archived-At: Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 18:14:36 -0000 On 2/14/17 12:29 PM, Roman Shpount wrote: > Hi, > > 1. In the offer BOTH rtcp-mux and rtcp-mux-only MUSTbe included > 2. In the answer rtcp-mux MUST be included or the session should be > terminated. rtcp-mux-only MUST NOT be included. Do you mean the RTP session must be terminated, or the *signaling* session? Requiring the signaling session to be terminated is overreaching. But I would agree that refusing the m-line (with port=0) is the proper alternative to accepting the rtcp-mux. Thanks, Paul From nobody Tue Feb 14 10:45:13 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3051294A0 for ; Tue, 14 Feb 2017 10:45:11 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDfpQsrvKo3S for ; Tue, 14 Feb 2017 10:45:10 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5000E1294DC for ; Tue, 14 Feb 2017 10:45:10 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id u25so131321221qki.2 for ; Tue, 14 Feb 2017 10:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ciU5oJgXno4meg1aDaYJIzXuEpOkVOncXp2X0Y3fnyY=; b=fykH4NwPXb6h4WnJTC5YPWwxJltJgrar00Nghw2O8X4H4gAybJdhlCF3wOUgIgrFSG Mep3Ih5MeNVxrUCxt3wmkM7NPYTVHuMGECHWiK09wBPG50BvHv0+WmKt33MGzxOnLUGy 07ojeoD4K8iJnX1ZxCOz/Q+spJRMWsvXyfUtnwFq6h+awz1UgAq2vMm/PdgWDku5Sx54 eX99gMsYvv3PZ18/NBVrjnx2rsjVdAzs/RkBmtANIW8vXHCq1rG2GKafQDgavobXF42j FPgb6j/tVlW5uubCVuGVKno9cpyd5zuGPIXK5E1Dx0z3XRQGQK1tvg6D7V3XuyH7xgM9 mWzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ciU5oJgXno4meg1aDaYJIzXuEpOkVOncXp2X0Y3fnyY=; b=bWLFKnYYSyP8CRcU17eSPcGBceSeRucN6LCF31VWPPJD8o1/BNeqmrBhFiLZz+zJuQ jv3RVf36T+1xDiMwSIV8nUMkXUNsSJkB6sIrskClaHxc631Mt3aofQSmVr4EYHB37a9h XiMRrYiyuMJl2FKnauqpzqmvvEbGPl9Pn1LVPngDH1fZKMMBzEueTp/pnDzcLIoi1L3H gkiM0M4vlSmTU4rqbhqpHD1FjKWTMkHPLzNzLujWO62raUanpW4x16BQu6CKLjHCUBfq kaDzRIpcVRtUvCtkyyLOmFQfIeOsygX2nePngVxg5qqbz9uw019QXcLWiHY3ngBha3Jg wE2w== X-Gm-Message-State: AMke39kd4bzUHBlbqUHaAKXKhM0OChci+S5IiC807IhYyANHkBO5rlkr/IV/wYW8mTd5UA== X-Received: by 10.55.48.140 with SMTP id w134mr27489000qkw.253.1487097909082; Tue, 14 Feb 2017 10:45:09 -0800 (PST) Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com. [209.85.220.180]) by smtp.gmail.com with ESMTPSA id p46sm803953qta.33.2017.02.14.10.45.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 10:45:08 -0800 (PST) Received: by mail-qk0-f180.google.com with SMTP id s186so131696351qkb.1 for ; Tue, 14 Feb 2017 10:45:08 -0800 (PST) X-Received: by 10.55.47.69 with SMTP id v66mr28269918qkh.222.1487097908450; Tue, 14 Feb 2017 10:45:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Tue, 14 Feb 2017 10:45:07 -0800 (PST) In-Reply-To: <0db4d135-fbd1-7051-ab65-c76cf8ca6488@comcast.net> References: <7594FB04B1934943A5C02806D1A2204B4BFEF197@ESESSMB209.ericsson.se> <0db4d135-fbd1-7051-ab65-c76cf8ca6488@comcast.net> From: Roman Shpount Date: Tue, 14 Feb 2017 13:45:07 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a114f4ec4946a87054881f6cc Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 18:45:11 -0000 --001a114f4ec4946a87054881f6cc Content-Type: text/plain; charset=UTF-8 On Tue, Feb 14, 2017 at 1:14 PM, Paul Kyzivat wrote: > On 2/14/17 12:29 PM, Roman Shpount wrote: > >> Hi, >> >> 1. In the offer BOTH rtcp-mux and rtcp-mux-only MUSTbe included >> 2. In the answer rtcp-mux MUST be included or the session should be >> terminated. rtcp-mux-only MUST NOT be included. >> > > Do you mean the RTP session must be terminated, or the *signaling* session? > > Requiring the signaling session to be terminated is overreaching. But I > would agree that refusing the m-line (with port=0) is the proper > alternative to accepting the rtcp-mux. > This should be handled the same way as getting back unexpected or error answer for a specific m= line. Either RTP session associated with the specific m= line needs to be terminated with port=0 or the whole signaling session should be terminated. Most importantly, RTP session associated with m= line MUST not continue to run expecting RTCP on rtp port + 1. Essentially, rtcp-mux-only should be treated as a promise by the offering party that it will not accept an answer without rtcp-mux. Regards, _____________ Roman Shpount --001a114f4ec4946a87054881f6cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 14, 2017 at 1:14 PM, Paul Kyzivat <paul.kyzivat@co= mcast.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On = 2/14/17 12:29 PM, Roman Shpount wrote:
Hi,

1. In the offer BOTH rtcp-mux and rtcp-mux-only MUSTbe included
2. In the answer rtcp-mux MUST be included or the session should be
terminated. rtcp-mux-only MUST NOT be included.

 Do you mean the RTP session must be terminated, or the *signaling* session?=

Requiring the signaling session to be terminated is overreaching. But I wou= ld agree that refusing the m-line (with port=3D0) is the proper alternative= to accepting the rtcp-mux.

This should= be handled the same way as getting back unexpected or error answer for a s= pecific m=3D line. Either RTP session associated with the specific m=3D lin= e needs to be terminated with port=3D0 or the whole signaling session shoul= d be terminated. Most importantly, RTP session associated with m=3D line MU= ST not continue to run expecting RTCP on rtp port + 1. Essentially, rtcp-mu= x-only should be treated as a promise by the offering party that it will no= t accept an answer without rtcp-mux.

Regards,
_____________
Roman Shpount
=C2=A0
--001a114f4ec4946a87054881f6cc-- From nobody Tue Feb 14 11:17:53 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B1A129603 for ; Tue, 14 Feb 2017 11:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 sOc72E9x2yd8 for ; Tue, 14 Feb 2017 11:17:51 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D0E1296B2 for ; Tue, 14 Feb 2017 11:17:50 -0800 (PST) X-AuditID: c1b4fb2d-eb3ff70000001743-c0-58a357dbd6ee Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 7C.BC.05955.BD753A85; Tue, 14 Feb 2017 20:17:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0319.002; Tue, 14 Feb 2017 20:17:47 +0100 From: Christer Holmberg To: Roman Shpount , Paul Kyzivat Thread-Topic: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux Thread-Index: AQHSfkR3UhfsVBhEwUWv5/2Z0yKCVaFXfBcAgASHPoD//+NbAIAAMCIA///nooCAAVZKgIAAF9KAgABohoCAACCTAIAAAV4AgAA2PgCAAAmMAIAADWsAgAk4I4CAAOGbAIAAZJMAgAAMiICAAAiKgIAAGYwA Date: Tue, 14 Feb 2017 19:17:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFFF47A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BFEF197@ESESSMB209.ericsson.se> <0db4d135-fbd1-7051-ab65-c76cf8ca6488@comcast.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BFFF47AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7iu7d8MURBjt/8FtMXf6YxeLBj142 ixkXpjI7MHtMfjyH0WPJkp9MHremFAQwR3HZpKTmZJalFunbJXBl/Dz9jKXgWWDFvos9jA2M R/y7GDk5JARMJFbOvsoIYgsJrGOUOL87BcJezChx/Hd5FyMHB5uAhUT3P22QsIiAn8TpidtZ QMLMAuoSVxcHgYSFBWwk1p1exgxRYivxdPthIJsLyF7FKDFp2392kASLgKrErEPrWUFsXgFf iYNLbrKBFAkJvOGQuP1pOgtIglMgUGJdx0uwBkYBMYnvp9YwgdjMAuISt57MZ4K4WUBiyZ7z zBC2qMTLx/9YIWwliUW3P0PV50tM/PGDBWKZoMTJmU9YJjCKzEIyahaSsllIymaB/aYpsX6X PkSJosSU7ofsELaGROucuezI4gsY2VcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBEbZwS2/ dXcwrn7teIhRgINRiYe3QHpxhBBrYllxZe4hRgkOZiURXg0HoBBvSmJlVWpRfnxRaU5q8SFG aQ4WJXFes5X3w4UE0hNLUrNTUwtSi2CyTBycUg2MHWXzu4xlN5QvNIy8azgndDZL2+xYZbeM ZT4lJ1Y8Yl7Qwa85Sfnz942LIifZHy2/KNhR/3KbumHrwfmMXlILK3ni/HYq9pkfNtqYyGrX s2zm4tfP78aGRWYKb+Rewx233S2Bf7LEq/ez9X5Ma5DZ0e7zvfGZiZHrnqqbr072Oy749LlQ vqhOiaU4I9FQi7moOBEAzJSr364CAAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 19:17:53 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BFFF47AESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFsc28sIGlmIHRoZSBvZmZlcmVyIHJlY2VpdmVzIGFuIGFuc3dlciwgd2l0aG91dCBh PXJ0Y3AtbXV4LCBpdCBtdXN0IHRha2UgcHJvcGVyIGFjdGlvbiBmb3IgZGlzYWJsaW5nIHRoZSBS VFAgc2Vzc2lvbiBhc3NvY2lhdGVkIHdpdGggdGhlIG0tIGxpbmUuDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCkZyb206IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgUm9tYW4gU2hwb3VudA0KU2VudDogMTQgRmVicnVhcnkgMjAxNyAyMDo0NQ0K VG86IFBhdWwgS3l6aXZhdCA8cGF1bC5reXppdmF0QGNvbWNhc3QubmV0Pg0KQ2M6IG1tdXNpY0Bp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtNTVVTSUNdIFNlbmRpbmcgYT1ydGNwLW11eC1vbmx5IHcv byBhPXJ0Y3AtbXV4DQoNCk9uIFR1ZSwgRmViIDE0LCAyMDE3IGF0IDE6MTQgUE0sIFBhdWwgS3l6 aXZhdCA8cGF1bC5reXppdmF0QGNvbWNhc3QubmV0PG1haWx0bzpwYXVsLmt5eml2YXRAY29tY2Fz dC5uZXQ+PiB3cm90ZToNCk9uIDIvMTQvMTcgMTI6MjkgUE0sIFJvbWFuIFNocG91bnQgd3JvdGU6 DQpIaSwNCg0KMS4gSW4gdGhlIG9mZmVyIEJPVEggcnRjcC1tdXggYW5kIHJ0Y3AtbXV4LW9ubHkg TVVTVGJlIGluY2x1ZGVkDQoyLiBJbiB0aGUgYW5zd2VyIHJ0Y3AtbXV4IE1VU1QgYmUgaW5jbHVk ZWQgb3IgdGhlIHNlc3Npb24gc2hvdWxkIGJlDQp0ZXJtaW5hdGVkLiBydGNwLW11eC1vbmx5IE1V U1QgTk9UIGJlIGluY2x1ZGVkLg0KDQpEbyB5b3UgbWVhbiB0aGUgUlRQIHNlc3Npb24gbXVzdCBi ZSB0ZXJtaW5hdGVkLCBvciB0aGUgKnNpZ25hbGluZyogc2Vzc2lvbj8NCg0KUmVxdWlyaW5nIHRo ZSBzaWduYWxpbmcgc2Vzc2lvbiB0byBiZSB0ZXJtaW5hdGVkIGlzIG92ZXJyZWFjaGluZy4gQnV0 IEkgd291bGQgYWdyZWUgdGhhdCByZWZ1c2luZyB0aGUgbS1saW5lICh3aXRoIHBvcnQ9MCkgaXMg dGhlIHByb3BlciBhbHRlcm5hdGl2ZSB0byBhY2NlcHRpbmcgdGhlIHJ0Y3AtbXV4Lg0KDQpUaGlz IHNob3VsZCBiZSBoYW5kbGVkIHRoZSBzYW1lIHdheSBhcyBnZXR0aW5nIGJhY2sgdW5leHBlY3Rl ZCBvciBlcnJvciBhbnN3ZXIgZm9yIGEgc3BlY2lmaWMgbT0gbGluZS4gRWl0aGVyIFJUUCBzZXNz aW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUgc3BlY2lmaWMgbT0gbGluZSBuZWVkcyB0byBiZSB0ZXJt aW5hdGVkIHdpdGggcG9ydD0wIG9yIHRoZSB3aG9sZSBzaWduYWxpbmcgc2Vzc2lvbiBzaG91bGQg YmUgdGVybWluYXRlZC4gTW9zdCBpbXBvcnRhbnRseSwgUlRQIHNlc3Npb24gYXNzb2NpYXRlZCB3 aXRoIG09IGxpbmUgTVVTVCBub3QgY29udGludWUgdG8gcnVuIGV4cGVjdGluZyBSVENQIG9uIHJ0 cCBwb3J0ICsgMS4gRXNzZW50aWFsbHksIHJ0Y3AtbXV4LW9ubHkgc2hvdWxkIGJlIHRyZWF0ZWQg YXMgYSBwcm9taXNlIGJ5IHRoZSBvZmZlcmluZyBwYXJ0eSB0aGF0IGl0IHdpbGwgbm90IGFjY2Vw dCBhbiBhbnN3ZXIgd2l0aG91dCBydGNwLW11eC4NCg0KUmVnYXJkcywNCl9fX19fX19fX19fX18N ClJvbWFuIFNocG91bnQNCg0K --_000_7594FB04B1934943A5C02806D1A2204B4BFFF47AESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmdtYWlsLQ0KCXttc28t c3R5bGUtbmFtZTpnbWFpbC07fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5BbHNvLCBpZiB0aGUgb2ZmZXJlciByZWNlaXZlcyBhbiBhbnN3ZXIsIHdpdGhvdXQg YT1ydGNwLW11eCwgaXQgbXVzdCB0YWtlIHByb3BlciBhY3Rpb24gZm9yIGRpc2FibGluZyB0aGUg UlRQIHNlc3Npb24gYXNzb2NpYXRlZCB3aXRoDQogdGhlIG0tIGxpbmUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+Um9tYW4gU2hwb3VudDxicj4NCjxiPlNlbnQ6PC9iPiAxNCBGZWJydWFyeSAyMDE3 IDIwOjQ1PGJyPg0KPGI+VG86PC9iPiBQYXVsIEt5eml2YXQgJmx0O3BhdWwua3l6aXZhdEBjb21j YXN0Lm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IG1tdXNpY0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW01NVVNJQ10gU2VuZGluZyBhPXJ0Y3AtbXV4LW9ubHkgdy9vIGE9cnRjcC1t dXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUdWUsIEZlYiAxNCwgMjAxNyBhdCAxOjE0IFBNLCBQYXVsIEt5eml2YXQgJmx0Ozxh IGhyZWY9Im1haWx0bzpwYXVsLmt5eml2YXRAY29tY2FzdC5uZXQiIHRhcmdldD0iX2JsYW5rIj5w YXVsLmt5eml2YXRAY29tY2FzdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSJnbWFpbC0iPk9uIDIvMTQvMTcgMTI6MjkgUE0sIFJvbWFuIFNocG91bnQgd3Jv dGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhpLDxicj4NCjxicj4NCjEuIEluIHRoZSBvZmZlciBCT1RIIHJ0Y3AtbXV4IGFuZCBydGNw LW11eC1vbmx5IE1VU1RiZSBpbmNsdWRlZDxicj4NCjIuIEluIHRoZSBhbnN3ZXIgcnRjcC1tdXgg TVVTVCBiZSBpbmNsdWRlZCBvciB0aGUgc2Vzc2lvbiBzaG91bGQgYmU8YnI+DQp0ZXJtaW5hdGVk LiBydGNwLW11eC1vbmx5IE1VU1QgTk9UIGJlIGluY2x1ZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KRG8geW91IG1lYW4gdGhlIFJU UCBzZXNzaW9uIG11c3QgYmUgdGVybWluYXRlZCwgb3IgdGhlICpzaWduYWxpbmcqIHNlc3Npb24/ PGJyPg0KPGJyPg0KUmVxdWlyaW5nIHRoZSBzaWduYWxpbmcgc2Vzc2lvbiB0byBiZSB0ZXJtaW5h dGVkIGlzIG92ZXJyZWFjaGluZy4gQnV0IEkgd291bGQgYWdyZWUgdGhhdCByZWZ1c2luZyB0aGUg bS1saW5lICh3aXRoIHBvcnQ9MCkgaXMgdGhlIHByb3BlciBhbHRlcm5hdGl2ZSB0byBhY2NlcHRp bmcgdGhlIHJ0Y3AtbXV4LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzaG91bGQgYmUgaGFuZGxlZCB0aGUgc2FtZSB3YXkg YXMgZ2V0dGluZyBiYWNrIHVuZXhwZWN0ZWQgb3IgZXJyb3IgYW5zd2VyIGZvciBhIHNwZWNpZmlj IG09IGxpbmUuIEVpdGhlciBSVFAgc2Vzc2lvbiBhc3NvY2lhdGVkIHdpdGggdGhlIHNwZWNpZmlj IG09IGxpbmUgbmVlZHMgdG8gYmUgdGVybWluYXRlZCB3aXRoIHBvcnQ9MCBvciB0aGUgd2hvbGUg c2lnbmFsaW5nIHNlc3Npb24gc2hvdWxkIGJlIHRlcm1pbmF0ZWQuDQogTW9zdCBpbXBvcnRhbnRs eSwgUlRQIHNlc3Npb24gYXNzb2NpYXRlZCB3aXRoIG09IGxpbmUgTVVTVCBub3QgY29udGludWUg dG8gcnVuIGV4cGVjdGluZyBSVENQIG9uIHJ0cCBwb3J0ICYjNDM7IDEuIEVzc2VudGlhbGx5LCBy dGNwLW11eC1vbmx5IHNob3VsZCBiZSB0cmVhdGVkIGFzIGEgcHJvbWlzZSBieSB0aGUgb2ZmZXJp bmcgcGFydHkgdGhhdCBpdCB3aWxsIG5vdCBhY2NlcHQgYW4gYW5zd2VyIHdpdGhvdXQgcnRjcC1t dXguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4BFFF47AESESSMB209erics_-- From nobody Wed Feb 15 02:06:12 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D881294E6 for ; Wed, 15 Feb 2017 02:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 VzfimwNG11qn for ; Wed, 15 Feb 2017 02:06:09 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82B91296F4 for ; Wed, 15 Feb 2017 02:06:08 -0800 (PST) X-AuditID: c1b4fb25-93e1698000001738-6b-58a4280e4edb Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id E5.5E.05944.E0824A85; Wed, 15 Feb 2017 11:06:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Wed, 15 Feb 2017 11:05:54 +0100 From: Christer Holmberg To: Christer Holmberg , Roman Shpount , Paul Kyzivat Thread-Topic: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux - PULL REQUEST Thread-Index: AdKHcuC1xYQpruYZQ2SVzns00hTRWg== Date: Wed, 15 Feb 2017 10:05:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C000021@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.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4C000021ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbHdVZdfY0mEwaHPrBZTlz9msXjwo5fN YsaFqcwOzB6TH89h9Fiy5CeTx60pBQHMUVw2Kak5mWWpRfp2CVwZ2649YS3YV13x4M561gbG KRVdjBwcEgImEodvOnUxcnEICaxjlFg0tYUdwlnMKLHg4A82kCI2AQuJ7n/aIHERgRZGieaW S2BxZgF1iauLg7oYOTmEBbwl7j1ZwQRiiwj4SGydvZcdwtaTaFv2mRHEZhFQldi3fSUzSCuv gK/EiTcaIGFGATGJ76fWgLUyC4hL3HoyH8yWEBCQWLLnPDOELSrx8vE/VghbSWLF9kuMEPX5 EjefzmQBsXkFBCVOznzCMoFRaBaSUbOQlM1CUjYL7AFNifW79CFKFCWmdD9kh7A1JFrnzGVH Fl/AyL6KUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzBmDm75rbqD8fIbx0OMAhyMSjy8BdKL I4RYE8uKK3MPMUpwMCuJ8B4TWBIhxJuSWFmVWpQfX1Sak1p8iFGag0VJnNds5f1wIYH0xJLU 7NTUgtQimCwTB6dUA6PJacN56VsOrOK9rGQQueLKq6APDJ+f2cZx1p/niSo18536p1Lm25Wv i1buzy8WOel4LGineZxY7dlJ9g/3MqY+OPW5hJW74HktW9hyjk7vRce3ctl7qm7M97my3EX/ QlTWyXu39GtONPVIXMuxcbMKT9ru+KVfQWFmxw7urJp1xy/s/iO78bISS3FGoqEWc1FxIgC3 6i51lQIAAA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux - PULL REQUEST X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 10:06:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4C000021ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSBjcmVhdGVkIGEgcHVsbCByZXF1ZXN0IHdpdGggdGhlIHN1Z2dlc3RlZCBj aGFuZ2VzOg0KDQpodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtbXV4LWV4Y2x1c2l2ZS9w dWxsLzINCg0KQXQgdGhpcyBwb2ludCBJIHRoaW5rIHdlIHNob3VsZCBPTkxZIGZvY3VzIG9uIHRo aXMgcGFydGljdWxhciBjaGFuZ2UuIEFueSBvdGhlciBjb21tZW50cyBwZW9wbGUgbWF5IGhhdmUg c2hvdWxkIGhhdmUgYmVlbiBnaXZlbiBhIGxvbmcgdGltZSBhZ2/igKYNCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2VudDogMTQgRmVicnVhcnkgMjAxNyAy MToxNw0KVG86IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPjsgUGF1bCBLeXppdmF0 IDxwYXVsLmt5eml2YXRAY29tY2FzdC5uZXQ+DQpDYzogbW11c2ljQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW01NVVNJQ10gU2VuZGluZyBhPXJ0Y3AtbXV4LW9ubHkgdy9vIGE9cnRjcC1tdXgNCg0K SGksDQoNCkFsc28sIGlmIHRoZSBvZmZlcmVyIHJlY2VpdmVzIGFuIGFuc3dlciwgd2l0aG91dCBh PXJ0Y3AtbXV4LCBpdCBtdXN0IHRha2UgcHJvcGVyIGFjdGlvbiBmb3IgZGlzYWJsaW5nIHRoZSBS VFAgc2Vzc2lvbiBhc3NvY2lhdGVkIHdpdGggdGhlIG0tIGxpbmUuDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCkZyb206IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgUm9tYW4gU2hwb3VudA0KU2VudDogMTQgRmVicnVhcnkgMjAxNyAyMDo0NQ0K VG86IFBhdWwgS3l6aXZhdCA8cGF1bC5reXppdmF0QGNvbWNhc3QubmV0PG1haWx0bzpwYXVsLmt5 eml2YXRAY29tY2FzdC5uZXQ+Pg0KQ2M6IG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIFNlbmRpbmcgYT1ydGNwLW11eC1vbmx5IHcv byBhPXJ0Y3AtbXV4DQoNCk9uIFR1ZSwgRmViIDE0LCAyMDE3IGF0IDE6MTQgUE0sIFBhdWwgS3l6 aXZhdCA8cGF1bC5reXppdmF0QGNvbWNhc3QubmV0PG1haWx0bzpwYXVsLmt5eml2YXRAY29tY2Fz dC5uZXQ+PiB3cm90ZToNCk9uIDIvMTQvMTcgMTI6MjkgUE0sIFJvbWFuIFNocG91bnQgd3JvdGU6 DQpIaSwNCg0KMS4gSW4gdGhlIG9mZmVyIEJPVEggcnRjcC1tdXggYW5kIHJ0Y3AtbXV4LW9ubHkg TVVTVGJlIGluY2x1ZGVkDQoyLiBJbiB0aGUgYW5zd2VyIHJ0Y3AtbXV4IE1VU1QgYmUgaW5jbHVk ZWQgb3IgdGhlIHNlc3Npb24gc2hvdWxkIGJlDQp0ZXJtaW5hdGVkLiBydGNwLW11eC1vbmx5IE1V U1QgTk9UIGJlIGluY2x1ZGVkLg0KDQpEbyB5b3UgbWVhbiB0aGUgUlRQIHNlc3Npb24gbXVzdCBi ZSB0ZXJtaW5hdGVkLCBvciB0aGUgKnNpZ25hbGluZyogc2Vzc2lvbj8NCg0KUmVxdWlyaW5nIHRo ZSBzaWduYWxpbmcgc2Vzc2lvbiB0byBiZSB0ZXJtaW5hdGVkIGlzIG92ZXJyZWFjaGluZy4gQnV0 IEkgd291bGQgYWdyZWUgdGhhdCByZWZ1c2luZyB0aGUgbS1saW5lICh3aXRoIHBvcnQ9MCkgaXMg dGhlIHByb3BlciBhbHRlcm5hdGl2ZSB0byBhY2NlcHRpbmcgdGhlIHJ0Y3AtbXV4Lg0KDQpUaGlz IHNob3VsZCBiZSBoYW5kbGVkIHRoZSBzYW1lIHdheSBhcyBnZXR0aW5nIGJhY2sgdW5leHBlY3Rl ZCBvciBlcnJvciBhbnN3ZXIgZm9yIGEgc3BlY2lmaWMgbT0gbGluZS4gRWl0aGVyIFJUUCBzZXNz aW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUgc3BlY2lmaWMgbT0gbGluZSBuZWVkcyB0byBiZSB0ZXJt aW5hdGVkIHdpdGggcG9ydD0wIG9yIHRoZSB3aG9sZSBzaWduYWxpbmcgc2Vzc2lvbiBzaG91bGQg YmUgdGVybWluYXRlZC4gTW9zdCBpbXBvcnRhbnRseSwgUlRQIHNlc3Npb24gYXNzb2NpYXRlZCB3 aXRoIG09IGxpbmUgTVVTVCBub3QgY29udGludWUgdG8gcnVuIGV4cGVjdGluZyBSVENQIG9uIHJ0 cCBwb3J0ICsgMS4gRXNzZW50aWFsbHksIHJ0Y3AtbXV4LW9ubHkgc2hvdWxkIGJlIHRyZWF0ZWQg YXMgYSBwcm9taXNlIGJ5IHRoZSBvZmZlcmluZyBwYXJ0eSB0aGF0IGl0IHdpbGwgbm90IGFjY2Vw dCBhbiBhbnN3ZXIgd2l0aG91dCBydGNwLW11eC4NCg0KUmVnYXJkcywNCl9fX19fX19fX19fX18N ClJvbWFuIFNocG91bnQNCg0K --_000_7594FB04B1934943A5C02806D1A2204B4C000021ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmdtYWlsLQ0KCXttc28t c3R5bGUtbmFtZTpnbWFpbC07fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+SSBoYXZlIGNyZWF0ZWQgYSBwdWxsIHJlcXVlc3Qgd2l0aCB0aGUgc3VnZ2VzdGVkIGNo YW5nZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YSBocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtbXV4LWV4Y2x1c2l2ZS9wdWxsLzIiPmh0dHBz Oi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1tdXgtZXhjbHVzaXZlL3B1bGwvMjwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkF0IHRoaXMgcG9pbnQgSSB0aGluayB3 ZSBzaG91bGQgT05MWSBmb2N1cyBvbiB0aGlzIHBhcnRpY3VsYXIgY2hhbmdlLiBBbnkgb3RoZXIg Y29tbWVudHMgcGVvcGxlIG1heSBoYXZlIHNob3VsZCBoYXZlIGJlZW4gZ2l2ZW4gYSBsb25nDQog dGltZSBhZ2/igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5k Q29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+Q2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQo8Yj5TZW50OjwvYj4gMTQgRmVicnVh cnkgMjAxNyAyMToxNzxicj4NCjxiPlRvOjwvYj4gUm9tYW4gU2hwb3VudCAmbHQ7cm9tYW5AdGVs dXJpeC5jb20mZ3Q7OyBQYXVsIEt5eml2YXQgJmx0O3BhdWwua3l6aXZhdEBjb21jYXN0Lm5ldCZn dDs8YnI+DQo8Yj5DYzo8L2I+IG1tdXNpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW01NVVNJQ10gU2VuZGluZyBhPXJ0Y3AtbXV4LW9ubHkgdy9vIGE9cnRjcC1tdXg8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BbHNvLCBpZiB0aGUgb2ZmZXJlciByZWNlaXZl cyBhbiBhbnN3ZXIsIHdpdGhvdXQgYT1ydGNwLW11eCwgaXQgbXVzdCB0YWtlIHByb3BlciBhY3Rp b24gZm9yIGRpc2FibGluZyB0aGUgUlRQIHNlc3Npb24gYXNzb2NpYXRlZCB3aXRoDQogdGhlIG0t IGxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBtbXVz aWMgWzxhIGhyZWY9Im1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm1tdXNp Yy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9tYW4gU2hwb3Vu dDxicj4NCjxiPlNlbnQ6PC9iPiAxNCBGZWJydWFyeSAyMDE3IDIwOjQ1PGJyPg0KPGI+VG86PC9i PiBQYXVsIEt5eml2YXQgJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVsLmt5eml2YXRAY29tY2FzdC5u ZXQiPnBhdWwua3l6aXZhdEBjb21jYXN0Lm5ldDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBo cmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBTZW5kaW5nIGE9cnRjcC1tdXgtb25seSB3L28gYT1y dGNwLW11eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFR1ZSwgRmViIDE0LCAyMDE3IGF0IDE6MTQgUE0sIFBhdWwgS3l6aXZhdCAm bHQ7PGEgaHJlZj0ibWFpbHRvOnBhdWwua3l6aXZhdEBjb21jYXN0Lm5ldCIgdGFyZ2V0PSJfYmxh bmsiPnBhdWwua3l6aXZhdEBjb21jYXN0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJnbWFp bC0iPk9uIDIvMTQvMTcgMTI6MjkgUE0sIFJvbWFuIFNocG91bnQgd3JvdGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8YnI+DQo8YnI+DQoxLiBJbiB0aGUgb2ZmZXIg Qk9USCBydGNwLW11eCBhbmQgcnRjcC1tdXgtb25seSBNVVNUYmUgaW5jbHVkZWQ8YnI+DQoyLiBJ biB0aGUgYW5zd2VyIHJ0Y3AtbXV4IE1VU1QgYmUgaW5jbHVkZWQgb3IgdGhlIHNlc3Npb24gc2hv dWxkIGJlPGJyPg0KdGVybWluYXRlZC4gcnRjcC1tdXgtb25seSBNVVNUIE5PVCBiZSBpbmNsdWRl ZC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCkRvIHlvdSBtZWFuIHRoZSBSVFAgc2Vzc2lvbiBtdXN0IGJlIHRlcm1pbmF0ZWQsIG9yIHRo ZSAqc2lnbmFsaW5nKiBzZXNzaW9uPzxicj4NCjxicj4NClJlcXVpcmluZyB0aGUgc2lnbmFsaW5n IHNlc3Npb24gdG8gYmUgdGVybWluYXRlZCBpcyBvdmVycmVhY2hpbmcuIEJ1dCBJIHdvdWxkIGFn cmVlIHRoYXQgcmVmdXNpbmcgdGhlIG0tbGluZSAod2l0aCBwb3J0PTApIGlzIHRoZSBwcm9wZXIg YWx0ZXJuYXRpdmUgdG8gYWNjZXB0aW5nIHRoZSBydGNwLW11eC48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgc2hvdWxkIGJl IGhhbmRsZWQgdGhlIHNhbWUgd2F5IGFzIGdldHRpbmcgYmFjayB1bmV4cGVjdGVkIG9yIGVycm9y IGFuc3dlciBmb3IgYSBzcGVjaWZpYyBtPSBsaW5lLiBFaXRoZXIgUlRQIHNlc3Npb24gYXNzb2Np YXRlZCB3aXRoIHRoZSBzcGVjaWZpYyBtPSBsaW5lIG5lZWRzIHRvIGJlIHRlcm1pbmF0ZWQgd2l0 aCBwb3J0PTAgb3IgdGhlIHdob2xlIHNpZ25hbGluZyBzZXNzaW9uIHNob3VsZCBiZSB0ZXJtaW5h dGVkLg0KIE1vc3QgaW1wb3J0YW50bHksIFJUUCBzZXNzaW9uIGFzc29jaWF0ZWQgd2l0aCBtPSBs aW5lIE1VU1Qgbm90IGNvbnRpbnVlIHRvIHJ1biBleHBlY3RpbmcgUlRDUCBvbiBydHAgcG9ydCAm IzQzOyAxLiBFc3NlbnRpYWxseSwgcnRjcC1tdXgtb25seSBzaG91bGQgYmUgdHJlYXRlZCBhcyBh IHByb21pc2UgYnkgdGhlIG9mZmVyaW5nIHBhcnR5IHRoYXQgaXQgd2lsbCBub3QgYWNjZXB0IGFu IGFuc3dlciB3aXRob3V0IHJ0Y3AtbXV4LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21h biBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4C000021ESESSMB209erics_-- From nobody Wed Feb 15 05:10:06 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5437D1294CD; Wed, 15 Feb 2017 05:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-FNYM_nhWVd; Wed, 15 Feb 2017 05:10:00 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E16127071; Wed, 15 Feb 2017 05:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7670; q=dns/txt; s=iport; t=1487164199; x=1488373799; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NHv1n8NpTpuTjLxCXOI5pa6vR/FBAq533q+29/kzS34=; b=Ub9bJtOOWUmCcuR8JawxcU3unbtOPI9c4fYyzeAGXMXu157MonY4sJA+ HOYoQq05XgHDFZXvlzoomhxdf7pWSU6K5qafORqniy0KPpuC/DQM+hWcI HZqojxms703UAjmbzWusbwyf4D9sn+N7rcwQuywJzWAKsYa2IA4Q+BrgT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AgAHUqRY/4cNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1KBageDDEaKCJFxH5Mngg+CDIYiAhqBcj8YAQIBAQEBAQEBYii?= =?us-ascii?q?EcAEBAQMBDBcRRQUJAgIBBgIYAgIfBAMCAgIZFxQBEAIEDgWJYwiSEp1OgiWLY?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FgQaHRwiCYoRrgm8ugjEFiQ2SagGJR0e?= =?us-ascii?q?IBYF7jwuILYppAR84PUNRFU4BhDMdGYFIdYh7gQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,166,1484006400"; d="scan'208";a="385802434" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Feb 2017 13:09:58 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1FD9v0V009221 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Feb 2017 13:09:57 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Feb 2017 08:09:56 -0500 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Wed, 15 Feb 2017 08:09:56 -0500 From: "Cullen Jennings (fluffy)" To: Magnus Westerlund Thread-Topic: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSfaJ5sVd9K8JGDU+bnDtTRZpMhaFo86YAgAF+fAA= Date: Wed, 15 Feb 2017 13:09:56 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> <0e84fe0e-8e50-7b9f-bede-76ebf293a0d8@ericsson.com> In-Reply-To: <0e84fe0e-8e50-7b9f-bede-76ebf293a0d8@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="utf-8" Content-ID: <0E7CBD95D90AC6459E638937E116BEC2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , "mmusic \(E-mail\)" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 13:10:01 -0000 DQpUbyB0cnkgYW5kIGhlbHAgZ2V0IHlvdSB0ZXh0IG1lcmdlZCBpbiwgSSBzZXBhcmF0ZWQgeW91 ciB0ZXh0IHVwIGludG8gYSBidW5jaCBvZiBQUnMgc28gdGhhdCB0aGUgZGlmZnMgd2VyZSBhbGwg Y2xlYXIgYW5kIGVhY2ggUFIgdHJpZWQgdG8gZGVhbCB3aXRoIG9uZSBpc3N1ZS4gVGhlcmUgYXJl IGFsbCBpbiBnaXRodWIgbm93IGFuZCBjb21tZW50aW5nIG9uIHRoZXNlcyB3b3VsZCBwcm9iYWJs eSBiZSB0aGUgZWFzaWVzIHdheSB0byBnZXQgdG8gc29tZSBjb21iaW5lZCB0ZXh0LiANCg0KDQo+ IE9uIEZlYiAxNCwgMjAxNywgYXQgNzoyMCBBTSwgTWFnbnVzIFdlc3Rlcmx1bmQgPG1hZ251cy53 ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+IFRoYW5rcyBm b3IgdGhlIGZlZWRiYWNrLiBTb3JyeSBmb3IgbXkgZGVsYXkgaW4gcmVzcG9uZGluZywgYSBjb2xk IGhhdmUNCj4ga2VwdCBmcm9tIHdvcmsuDQo+IA0KPiBEZW4gMjAxNy0wMi0wMiBrbC4gMjM6MTks IHNrcmV2IEN1bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5KToNCj4+IA0KPj4gU28gSSBtdWNoIHByZWZl ciB0aGUgY3VycmVudCB0ZXh0IGFuZCB0aGluayB0aGVyZSBhcmUgYSBidW5jaCBvZg0KPj4gcHJv YmxlbXMgd2l0aCB0aGlzIHRleHQuIElmIHdlIGFjdHVhbGx5IGhhZCBlbWFpbHMgZXhwbGFpbmlu ZyB3aGF0DQo+PiBwcm9ibGVtcyBpbiB0aGUgY3VycmVudCB0ZXh0IHRoaXMgd2FzIHRyeWluZyB0 byBmaXgsIHdpdGggaW5kaXZpZHVhbA0KPj4gUFJzIGZvciB0aG9zZSwgdGhpcyB3b3VsZCBiZSBt dWNoIGVhc2llciB0byByZXNvbHZlIGVhY2ggb2YgdGhlbSBhbmQNCj4+IGdldCB0aGVtIGZpeGVk Lg0KPj4gDQo+PiAxKSB3ZSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGF2b2lkIHRoZSB1c2Ugb2YgIlJU UCBzZXNzaW9uIiBhcyBpdCBoYXMNCj4+IGJlZW4gdmVyeSB1bmNsZWFyIHRvIGltcGxlbWVudG9y cyB3aGF0IGl0IGlzLiBJIHRoaW5rIHRoaXMgd291bGQgYmUNCj4+IGJldHRlciBpZiB3ZSBjb3Vs ZCByZXBocmFzZSB0byBub3QgdXNlIHRoYXQNCj4gDQo+IE9rYXksIGJ1dCB0aGUgUlRQIHNlc3Np b24gaXMgdmVyeSBlYXN5IHRvIG1ha2UgY2xlYXIgaW4gdGhlIGNvbnRleHQgaW4NCj4gb2YgQlVO RExFLCB3aGVyZSB0aGlzIHRleHQgaXMgaW50ZW5kZWQgdG8gYmUuIEkgY2FuIGltcHJvdmUgdGhh dC4NCj4gDQo+PiANCj4+IDIpIGJvdGggdGhlIHByb3Bvc2VkIGFuZCBjdXJyZW50IHRleHQgc2Vl bSBsYWNraW5nIGluIGRlYWxpbmcgd2l0aA0KPj4gbXVsdGlwbGUgYnVuZGxlIGdyb3Vwcw0KPiAN Cj4gT2theSwgdGhhdCBjYW4gYmUgZml4ZWQgYnkgY2xhcmlmeWluZyB0aGF0IGVhY2ggYnVuZGxl IGdyb3VwIHJlc3VsdHMgaW4NCj4gaXRzIG93biBSVFAgc2Vzc2lvbiwgdGh1cyB0aGUgcHJvY2Vk dXJlcyBpbiB0aGlzIGlzIHBlciBidW5kbGUgZ3JvdXAuDQo+IA0KPj4gDQo+PiAzKSBTdGF0cyBh cmUgdHlwaWNhbGx5IG1haW50YWluZWQgYnkgdGhpbmdzIGFmdGVyIHRoZSBwYWNrZXQgaXMNCj4+ IHJvdXRlZCAtIG5vdCBiZWZvcmUuDQo+IA0KPiBTbyB0aGlzIGNvbWVzIGEgcXVlc3Rpb24gb2Yg b25lcyB2aWV3IG9mIFJUUCBzdGFjayBhbmQgdGhlIHF1ZXN0aW9uIG9mDQo+IGxheWVyaW5nLiBB bmQgdGhpcyBpcyBleGFjdGx5IHdoeSBJIHRoaW5rIHRoZSBjdXJyZW50IHRleHQgaXMNCj4gcHJv YmxlbWF0aWMuIEl0IHRha2VzIG9uZSB2ZXJ5IHBhcnRpY3VsYXIgdmlldywgd2h5IEkgYXR0ZW1w dGVkIHRvIGJlDQo+IG11Y2ggbW9yZSBuZXV0cmFsIG9uIHdoaWNoIG9yZGVyIHRoaW5ncyBoYXBw ZW5zLiBUaGVyZSBhcmUgYSBudW1iZXIgb2YNCj4gZnVuY3Rpb25zIHRoYXQgYXJlIGluIHRoZSBS VFAgcHJvdG9jb2wgbGF5ZXIsIG5vdCBpbiB0aGUgaGlnaGVyIGxheWVycy4NCj4gVGhlcmUgYXJl IGhvd2V2ZXIgc29tZSB0aGluZ3MsIGxpa2UgWFIgVm9JUCBtZXRyY2lzIHRoYXQgYXJlIG1ldHJp Y3MgaW4NCj4gdGhlIGhpZ2hlciBsYXllcnMuIFNvLCB5ZXMgdGhpcyBpcyBub3QgY2xlYXIgY3V0 LiBJIHRoaW5rIG9uZXMgdmlldyBvZg0KPiB0aGlzIGRlcGVuZHMgb24gaWYgb25lIGhhdmUgYSB2 ZXJ5IGludGVncmF0ZWQgUlRQIGltcGxlbWVudGF0aW9uLCB0aGVuDQo+IHdoYXQgeW91IHNheSBt YWtlcyBzZW5zZSwgYnV0IGlmIG9uZSBoYXMgYSB2ZXJ5IGxheWVyZWQgYW5kIG1vZHVsYXJpemVk DQo+IGRlc2lnbiwgdGhlbiBteSB2aWV3cG9pbnQgbWFrZXMgbW9yZSBzZW5zZS4NCj4gDQo+IEZy b20gbXkgcGVyc3BlY3RpdmUgdGhlIG1vc3QgaW1wb3J0YW50IHRoaW5nIGhlcmUgaXMgdGhhdCB0 aGlzIHRleHQgaWYNCj4gaXQgY29udGFpbnMgYW55IFJGQyAyMTE5IHdvcmRzIGNhbid0IHByZXZl bnQgc29tZSBwb3NzaWJsZQ0KPiBpbXBsZW1lbnRhdGlvbiBjaG9pY2VzIG9mIHRoZSBSVFAgc3Rh Y2suDQo+IA0KPj4gDQo+PiA0KSBOZWVkIHRvIGV4cGxhaW4gaG93IHRoZSBTREVTIGluIGNvbXBv dW5kIFJUQ1AgY2F1c2VzIHVwZGF0ZXMNCj4+IA0KPiANCj4gSSBjYW4gYXR0ZW1wdCB0byBjbGFy aWZ5IHRoaXMuIEhvd2V2ZXIsIHRoZXJlIGlzIGEgcG90ZW50aWFsIGlzc3VlIGhlcmUNCj4gaW4g dGhhdCBzb21lIGltcGxlbWVudGF0aW9ucyBtYXkgbm90IGJlIGFibGUgdG8gZm9yY2UgdGhlIHJl Y2VpdmVyIHRvDQo+IHByb2Nlc3MgdGhlIGNvbnRlbnQgb2YgdGhlIFNERVMgUlRDUCBwYWNrZXQg cHJpb3IgdG8gc29tZSBvciBldmVuIGFsbA0KPiB0aGUgb3RoZXIgUlRDUCBwYWNrZXRzIGluIGEg Y29tcG91bmQgcGFja2V0Lg0KPiANCj4gV2hhdCBpbiB0aGUgY3VycmVudCB0ZXh0Og0KPiANCj4g ICAgT24gcmVjZXB0aW9uIG9mIGFueSBjb21wb3VuZCBSVENQIHBhY2tldCBwcmlvciB0byBkaXNw YXRjaGluZyB0aGUNCj4gICAgcmVjZWl2ZWQgaW5mb3JtYXRpb24gYW5kIGRhdGEsIGlmIHRoZXJl IGlzIGFuIFJUQ1AgU0RFUyBwYWNrZXQNCj4gICAgaW5jbHVkZWQgdGhhdCBTSE9VTEQgYmUgcHJv Y2Vzc2VkIGZpcnN0LiAgSWYgdGhhdCBTREVTIHBhY2tldA0KPiAgICBjb250YWlucyBTREVTIE1J RCBlbnRyaWVzLCB0aGlzIGNhbiByZXN1bHRzIGluIHVwZGF0ZXMgYW5kIGFkZGl0aW9ucw0KPiAg ICB0byB0aGUgUlRQIHN0cmVhbSB0byAibT0iIGxpbmUgbWFwcGluZyB0YWJsZS4gIFRodXMgZWFj aCBvZiB0aGUgU0RFUw0KPiAgICBNSUQgaXRlbXMgYXJlIHByb2Nlc3NlZCBhbmQgdGhlIGN1cnJl bnQgdGFibGUgZW50cmllcyBhcmUgY2hlY2tlZCBpZg0KPiAgICB0aGUgY29ycmVzcG9uZGluZyBN SUQgdmFsdWUgbWF0Y2hlcyB0aGUgY3VycmVudCBSVFAgc3RyZWFtIHRvICJtPSINCj4gICAgbGlu ZSBtYXBwaW5nLCBlbHNlIHRoZSBlbnRyeSBpcyB1cGRhdGVkLiAgSWYgdGhlcmUgaXMgbm8gUlRQ IHN0cmVhbQ0KPiAgICB0byAibT0iIGxpbmUgdGFibGUgbWFwcGluZyBlbnRyeSBmb3IgdGhlIHJl Y2VpdmVkIFNERVMgaXRlbSdzIFNTUkMsDQo+ICAgIHN1Y2ggYW4gZW50cnkgaXMgY3JlYXRlZC4g IE5vdGUsIHRoYXQgaW4gdGhlIHByb2Nlc3Mgb2YgdXBkYXRpbmcgdGhlDQo+ICAgIHRhYmxlIGVu dHJpZXMsIHVwZGF0ZSBmbGFwIHN1cHByZXNzaW9uIGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDQu Mi42DQo+ICAgIG9mIFtSRkM3OTQxXSBzaG91bGQgYmUgY29uc2lkZXJlZC4NCj4gDQo+IElzIGlu c3VmZmljaWVudCBpbiB0aGF0IHJlZ2FyZHMuIElzIGl0IG9ubHkgdGhlIHBsYWNlbWVudCBwcmlv ciB0byB0aGUNCj4gaW5kaXZpZHVhbCBSVENQIHBhY2tldCB0eXBlcyB0aGF0IGlzIHRoZSBpc3N1 ZT8gU2hvdWxkIHdpdGggdGhlDQo+IGV4Y2VwdGlvbiBvZiB0aGUgZmlyc3Qgc2VudGVuY2UgYmUg bW92ZWQgdW5kZXIgdGhlIFNERVMgdGV4dD8NCj4gDQo+PiA1KSBnaXZlbiB0aGlzIHJlbW92ZXMg dGhlIG91dGdvaW5nIFNTUkMgdGFibGUsIG5vdCBjbGVhciBob3cgaXQNCj4+IHJvdXRlcyBSVENQ IHJlcG9ydHMuIEkgdGhpbmsgdGhpcyBuZWVkcyB0byBiZSBjbGFyaWZpZWQuDQo+PiANCj4gDQo+ IE9rYXksIEkgdGhpbmsgSSB1bmRlcnN0YW5kIHRoYXQuIEkgaGF2ZSBhbiBpbXBsaWNpdCBhc3N1 bXB0aW9uIHRoYXQgdGhlDQo+IGltcGxlbWVudGF0aW9uIGtub3dzIGhvdyBpdHMgbG9jYWwgKG91 dGdvaW5nKSBSVFAgU3RyZWFtcyBhcmUgcmVsYXRlZCB0bw0KPiB0aGUgbWVkaWEgc291cmNlcyBh bmQgdGh1cyB0aGUgcmVsYXRlZCBSVFBzZW5kZXIuIEkgY2FuIHVwZGF0ZSB0aGUgdGV4dA0KPiB0 byBhZGRyZXNzIHRoaXMuDQo+IA0KPj4gNikgSSBkb24ndCB0aGluayBtb3N0IGltcGxlbWVudGVy cyBhcmUgZ29pbmcgdG8gaGF2ZSBhIGNsdWUgd2hhdCB0bw0KPj4gZG8gZm9yIHRoZSAiVGhpcmQg UGFydHkgVGFyZ2V0ZWQgUmVwb3J0cyBvciBGZWVkYmFjayIgc2VjdGlvbg0KPj4gDQo+IA0KPiBJ IGNhbiB1bmRlcnN0YW5kIHRoYXQsIGJ1dCBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBjYWxs IG91dCB0aGF0IHRoaXMNCj4gYnVja2V0IGRvIGV4aXN0LCBhbmQgaWYgeW91IGRvbid0IGtub3cg d2hhdCB0byBkbyBJIHRoaW5rIGl0IGlzIGZpbmUgdG8NCj4gaWdub3JlIHRoZXNlLg0KPiANCj4+ IEkgd2lsbCB0cnkgYW5kIHRha2UgeW91ciBQUiBhbmQgYnJlYWsgaXQgdXAgaW50byBzb21lIGJp dCBzaXplIHBpZWNlcw0KPj4gc28gd2UgY2FuIHRyeSBhbmQgc2VlIGlmIHdlIGNhbiBnZXQgdGhl IGVhc3kgb25lcyBvdXQgb2YgdGhlIHdheSBhbmQNCj4+IGZvY3VzIG9uIHRoZSBwYXJ0cyB0aGF0 IGFyZSBrZXkgY2hhbmdlcy4NCj4+IA0KPiANCj4gT2ssIEkgaGF2ZSBzZWVuIHRoYXQgeW91IGdl bmVyYXRlZCBhIGxvdCBvZiBpbmRpdmlkdWFsIGlzc3VlcywgSSB3aWxsIGF0dGVtcHQgdG8gbG9v ayB0aHJvdWdoIHRoZW0gYW5kIGNvbW1lbnQgaWYgdGhlcmUgYXJlIHRoaW5ncyB0aGF0IHdhcyB1 bmludGVudGlvbmFsIG9yIHdoZXJlIEkgaGF2ZSBhZGRpdGlvbmFsIGFzcGVjdHMgdG8gYWRkLg0K PiANCj4gSSBpbnRlbmQgdG8gdXBkYXRlIG15IFBSIGJhc2VkIG9uIHRoZSBmZWVkYmFjayBJIHJl Y2VpdmVkLg0KPiANCj4gQ2hlZXJzDQo+IA0KPiBNYWdudXMgV2VzdGVybHVuZA0KPiANCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiBTZXJ2aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsgZmVhdHVyZXMsIEVyaWNz c29uIFJlc2VhcmNoIEVBQi9UWE0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBFcmljc3NvbiBBQiAgICAg ICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCj4gRsOkcsO2Z2F0YW4gNiAgICAg ICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNCj4gU0UtMTY0IDgwIFN0b2NraG9s bSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiANCg0K From nobody Wed Feb 15 22:53:14 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E95341295E5; Wed, 15 Feb 2017 22:53:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148722798894.31519.17789704317049787038.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 22:53:08 -0800 Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-sctp-sdp@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Spencer Dawkins' Yes on draft-ietf-mmusic-sctp-sdp-23: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 06:53:09 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-mmusic-sctp-sdp-23: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This spec is really well-done. Thanks to the authors and working group for that. From nobody Wed Feb 15 22:57:02 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B671295E9; Wed, 15 Feb 2017 22:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 G_u1p3dyIgaT; Wed, 15 Feb 2017 22:56:56 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28266129549; Wed, 15 Feb 2017 22:56:51 -0800 (PST) X-AuditID: c1b4fb30-eabff70000002c77-64-58a54d3108cd Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id A7.30.11383.13D45A85; Thu, 16 Feb 2017 07:56:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 07:56:49 +0100 From: Christer Holmberg To: Spencer Dawkins , The IESG Thread-Topic: Spencer Dawkins' Yes on draft-ietf-mmusic-sctp-sdp-23: (with COMMENT) Thread-Index: AQHSiCFWORZ9U41WIEaQ61pNHefHbKFrM03w Date: Thu, 16 Feb 2017 06:56:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C0036BA@ESESSMB209.ericsson.se> References: <148722798894.31519.17789704317049787038.idtracker@ietfa.amsl.com> In-Reply-To: <148722798894.31519.17789704317049787038.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.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7hK6R79IIg9f75CxerZvPbPH+gq7F jD8TmS3O71zPZDF1+WMWi2VT9jA7sHlM+b2R1WPnrLvsHkuW/GQKYI7isklJzcksSy3St0vg yrjypZW54BZPxcLuO4wNjBt4uhg5OSQETCT+Pl3G2MXIxSEksI5R4mbzJGaQhJDAYkaJbX1y XYwcHGwCFhLd/7RBwiICvhJXJi9lA6lnFrjBKNF2+AkbSEJYIERi2ZsDTBBFoRIXTn9ihrCN JN71rGcFsVkEVCV29O0Gs3mBBn2f+g1ql59ER/cKdpBdnAL+El/mJ4OEGQXEJL6fWgM2kllA XOLWk/lMEDcLSCzZc54ZwhaVePn4HyuErSSxYvslRpAxzAKaEut36UO0KkpM6X7IDrFVUOLk zCcsExhFZyGZOguhYxaSjllIOhYwsqxiFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIyog1t+ G+xgfPnc8RCjAAejEg/vh5wlEUKsiWXFlbmHGCU4mJVEeFd5LY0Q4k1JrKxKLcqPLyrNSS0+ xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgVHq1f9lzKbPbFiPPJ7RuevfcqcFz5d+ mV7lfebIvwCB/b/D/2WeuWgzRbrQ8Ll6zONd6rPmBt/yM5BcGr3Da1bHwx9LHKOOH6h+XqJl c37fbT6N73fSPp9ui1K7ELFO8/88ufdRmxe65yjvcLmyeoOuod77OW+TT85pWfYz69FpqRA9 x29TH3QtUmIpzkg01GIuKk4EAMXhwC+kAgAA Archived-At: Cc: "fandreas@cisco.com" , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-sctp-sdp@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Spencer Dawkins' Yes on draft-ietf-mmusic-sctp-sdp-23: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 06:56:57 -0000 VGhhbmtzLCBTcGVuY2VyISA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3BlbmNlciBEYXdraW5zIFttYWlsdG86c3BlbmNlcmRh d2tpbnMuaWV0ZkBnbWFpbC5jb21dIA0KU2VudDogMTYgRmVicnVhcnkgMjAxNyAwODo1Mw0KVG86 IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtbW11c2ljLXNjdHAtc2Rw QGlldGYub3JnOyBtbXVzaWMtY2hhaXJzQGlldGYub3JnOyBmYW5kcmVhc0BjaXNjby5jb207IG1t dXNpY0BpZXRmLm9yZw0KU3ViamVjdDogU3BlbmNlciBEYXdraW5zJyBZZXMgb24gZHJhZnQtaWV0 Zi1tbXVzaWMtc2N0cC1zZHAtMjM6ICh3aXRoIENPTU1FTlQpDQoNClNwZW5jZXIgRGF3a2lucyBo YXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYt bW11c2ljLXNjdHAtc2RwLTIzOiBZZXMNCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0 aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBp bmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGlu dHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRw czovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlv bnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMs IGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHAvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQpUaGlzIHNwZWMgaXMgcmVhbGx5IHdlbGwtZG9uZS4gVGhhbmtzIHRv IHRoZSBhdXRob3JzIGFuZCB3b3JraW5nIGdyb3VwIGZvciB0aGF0Lg0KDQoNCg== From nobody Thu Feb 16 03:20:37 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D381294BD; Thu, 16 Feb 2017 03:20:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 03:20:33 -0800 Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-sctp-sdp@ietf.org, mmusic@ietf.org Subject: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 11:20:33 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-mmusic-sctp-sdp-23: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP? From nobody Thu Feb 16 04:45:33 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D941299E9; Thu, 16 Feb 2017 04:45:32 -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, RP_MATCHES_RCVD=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham autolearn_force=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 Q1muk9JJp1kO; Thu, 16 Feb 2017 04:45:31 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 55BC6129595; Thu, 16 Feb 2017 04:45:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AD7E92CEB1; Thu, 16 Feb 2017 14:45:30 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fX6OYejIBaHh; Thu, 16 Feb 2017 14:45:30 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 3E0112CCBA; Thu, 16 Feb 2017 14:45:30 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_418A98C5-A853-405B-BEF9-7DAB71234614"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <9007DD69-14A7-4B15-9F2C-A8CB0223E817@ericsson.com> Date: Thu, 16 Feb 2017 14:45:29 +0200 Message-Id: <5C1211FA-A82D-42AB-9AFE-0A56AF0B6827@piuha.net> References: <148676797054.29317.17761463000129345942.idtracker@ietfa.amsl.com> <9007DD69-14A7-4B15-9F2C-A8CB0223E817@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "gen-art@ietf.org" , Brian Carpenter , "mmusic@ietf.org" , "draft-ietf-mmusic-sctp-sdp.all@ietf.org" Subject: Re: [MMUSIC] [Gen-art] Review of draft-ietf-mmusic-sctp-sdp-23 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 12:45:32 -0000 --Apple-Mail=_418A98C5-A853-405B-BEF9-7DAB71234614 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Brian, Christer: thanks. Jari --Apple-Mail=_418A98C5-A853-405B-BEF9-7DAB71234614 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYpZ7pAAoJEM80gCTQU46ql6QQALcxEP9o/y+gqrZCH6nZbuLa sljywMpkCVIqfft5zD6kSsrX/UWz61AZse8AJfTBhXdFNP7AOLGeF7mmha5tdoIl cnJIBMHwyH6r4AKHgJB9YmPcLLBL9WqKg6W6Gi3cNBytgM+MjsKex4kWuEekD6O9 uVJ8aOxI6zQZ1Hk+nuZnnVOwor16mG7WRSVrNneRtdIQGgVQ5so7Vufyn6uonar2 9idhyyWg1+8+WfgbwAqduluq/28ZFe2aI5xG6mVq+vsbwcp5tlzweoQEAGD8eZ21 yvx96sUu5/FetvZTLc7Btdm6urzdnqCDJT6K12wUEgivm/DQKKu3up4pJRLoaAOc KSUpdxYEHe06ndch6bJaC74yTGBFUHi7aVffjsEHtjgC4UZWaVghfFM2rCWPfKEe p3FoYnxQBVOFN5NBmSvJTXcRrH+hN9WORv15AQszzqhBu5XFxGW8osls38bwp7Fq 2hH5phUwdeP0VnOHC0yYhV6Jg1ASn7TiUPUBl7VZ3jraBAG9jyn1yLLBa4kA9Kyf Gd4CPdw+PhZNOv/oYujqVbznMzg8wIbv6TjMRaNWeyaRF700U3JLjx7oSGsdGxiD CIK4jeBTjollU+VBFbF/HcCNh4UCOhJ9VSSOJGvfswGcLpv+xeaJw+RNXds1N5PU JyA9sBGZD39RTpqJy6GG =F5wj -----END PGP SIGNATURE----- --Apple-Mail=_418A98C5-A853-405B-BEF9-7DAB71234614-- From nobody Thu Feb 16 06:19:45 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00A31294B4 for ; Thu, 16 Feb 2017 06:19:43 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIWwTuJXZsZB for ; Thu, 16 Feb 2017 06:19:43 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C40821294AD for ; Thu, 16 Feb 2017 06:13:41 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id 32so11648562oth.3 for ; Thu, 16 Feb 2017 06:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=T40Kiv4Q+iHruGo5gspZjmEFYzinOFigco+UawJWlzA=; b=SWRU6PZ/Ho24fIAew6F+3ubSr/vW3VJqCr1lWf9Kt8JUoCqCMUszFuKIGtQ3sozVOn EcCEPjms7rW3Srl+XVUg0jPWSu1RbM6/WQDgAKxQffyQakAsLyy2W8fafa19+1VT9aJw Wqi4Crmu2RFdTUaibCoVks/Qid3xa2aW09aVYQGf5gwxmu/DKZVzstvRduJIgvXPkdby nbnpIv4RcqzEZavfQvBsBfWC1l/xhFBGgWjdmVfYhmZLeLXMj66hKqOCkCjtQXR74haW FDrD4KFyAI6zQPR/dJ8hhiNDxEeE0h40izgRyJ3elhehIFU4gv6MOUgaii6q5aED0cx3 DmFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=T40Kiv4Q+iHruGo5gspZjmEFYzinOFigco+UawJWlzA=; b=gMv0bX+H1cUVesRj1/bp7JWERRtyw/ViOIF5/PdPhqTncaQs658Ok4cAqRsLMvDlC0 mgID7B8TPd9D6gkM76MgyFSmOmz+v8eeV4GCrc/wRFcHHREr3HjTFLShezYNvjtGHc9G LZA9XcSEsOgRizZIo5jNX+/BOlCbflOqGPytla0xnAG9OUYklFLnrUgj4EeDm5Ry2yN/ IJy7UZNCeF0Dqtzh3vMJ+C4EIzYaIpCqHVULRDMf80BbUHBPlUJithuLcGni//HvdwFW jo+AHZZyEqNaOJ1HuJI7iTuQAc67iFHRomSV5ZQIZ1iB/v03dwEpHrV9Ds06Xb74fkii RWHQ== X-Gm-Message-State: AMke39kRcD6Ga2KfGjZuLYAHbR39lYHpPWIDyvZm6dCKhH53LtJn4SZkbZG92lxwq/h9Ykcq4Sx+i6uP4YZucw== X-Received: by 10.157.46.228 with SMTP id w91mr1201315ota.31.1487254421054; Thu, 16 Feb 2017 06:13:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.33.245 with HTTP; Thu, 16 Feb 2017 06:11:50 -0800 (PST) From: Eric Rescorla Date: Thu, 16 Feb 2017 06:11:50 -0800 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary=001a113d05807539300548a667c1 Archived-At: Subject: [MMUSIC] Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:19:44 -0000 --001a113d05807539300548a667c1 Content-Type: text/plain; charset=UTF-8 See: https://github.com/cdh4u/draft-sdp-bundle/issues/27 https://github.com/rtcweb-wg/jsep/issues/528 The basic issue is that it's possible to have a situation where you have both media and data m= sections but the BUNDLE tag is associated with the data m= section and now you need to put the TRANSPORT and IDENTICAL attributes somewhere. The JSEP editors discussed this and came to the conclusion that it should go with the BUNDLE tag (i.e., in the data m= section) and that BUNDLE should forbid this, but it requires a change to BUNDLE. -Ekr --001a113d05807539300548a667c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
See:
https://github.com/cdh4u/draft-sdp-bundle/issues/27

The basic= issue is that it's possible to have a situation where you have both
media and data m=3D sections but the BUNDLE tag is associated with = the data
m=3D section and now you need to put the TRANSPORT and I= DENTICAL
attributes somewhere. The JSEP editors discussed this an= d came to the
conclusion that it should go with the BUNDLE tag (i= .e., in the data m=3D section)
and that BUNDLE should forbid this= , but it requires a change to BUNDLE.

-Ekr

--001a113d05807539300548a667c1-- From nobody Thu Feb 16 06:37:06 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15085129618 for ; Thu, 16 Feb 2017 06:37:00 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUB74Cf84xAH for ; Thu, 16 Feb 2017 06:36:59 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98F512961A for ; Thu, 16 Feb 2017 06:36:57 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id 32so12106134oth.3 for ; Thu, 16 Feb 2017 06:36:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7+JGhZuG7e0omL78DeubqNm1S+zXEps7u2sCBRoCGF0=; b=te3FyEd7KxfI1aU/UZ1oD9JXXulNlsb4LGHFUfF+Ft+87wpgvIFmC2tNiKSOOfEaG5 c4aUB1Gb+8bfK8q+Pm0nT4mjzuV8filLCSzXN9b5cUbPUe49OteWsUIrN1Se22ywZKzq XlaGTGJnyMD17wdYD6yfrQ1z4XmXwLMYKxyf74xN3T/kV8nY+CT/0LqRhj425LDG3AsR vpznNwWQabeP0oA0HBiM4ZC6Ql73oF1ncV8O/qZN6UcH/sbqA5IzZpozgiOJlWACqZZJ kOWGIz18EsZGdf/Q0j+EEZCIyFlFiV6OciFXV4IxP9FKQ7JmFUxene5VSBxmBOrVonsS qdbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7+JGhZuG7e0omL78DeubqNm1S+zXEps7u2sCBRoCGF0=; b=mSs99YY8g5mB80UsfTpIIdU2EM2gTIt4Y7XwRvtgDkfwla1rw/85ATxTfOsG/F7vAH QzuRxLTuLcZUyhSNJ7KW7VE2n/E2ONo3Ahif/VhCobq6ob9CVQCc0tZ8m+/a+QU4qrMr y6xC4uOR8Jgxnld2mNJtSboenCgUtigvKxBnjwkxa/RJ4FvEwj5fONKv8y89Z/eIZU1G eerKBbPcItYNH3DGxmQ/+NdqMlBaks3j/Uig+t59T3ZNImafok5t/TDGvCE4S0u5bosc +iiNrGnfRr7qfg1Ejga/k/EVnQoI/0xNVDWNm9oIHBLaL+xKqMdPt7F+f3LTjtJfFjDv bEtg== X-Gm-Message-State: AMke39kfUYYjyDn3jUpWd23HtpDU04yIDdgOWLODfspuwWOhKp/i3cNMGdkrgZkkCq3DGlnhQR8KKSNVY4mfoQ== X-Received: by 10.157.63.188 with SMTP id r57mr1226006otc.78.1487255816991; Thu, 16 Feb 2017 06:36:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.230 with HTTP; Thu, 16 Feb 2017 06:36:16 -0800 (PST) In-Reply-To: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Thu, 16 Feb 2017 06:36:16 -0800 Message-ID: To: Mirja Kuehlewind Content-Type: multipart/alternative; boundary=001a11459e14a98e450548a6bab6 Archived-At: Cc: Flemming Andreasen , mmusic-chairs@ietf.org, draft-ietf-mmusic-sctp-sdp@ietf.org, The IESG , mmusic WG Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:37:01 -0000 --001a11459e14a98e450548a6bab6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Because it's always DTLS, just over a different transport. On Thu, Feb 16, 2017 at 3:20 AM, Mirja Kuehlewind wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-mmusic-sctp-sdp-23: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP? > > > > > --001a11459e14a98e450548a6bab6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Because it's always DTLS, just over a different transp= ort.

On Thu,= Feb 16, 2017 at 3:20 AM, Mirja Kuehlewind <ietf@kuehlewind.net><= /span> wrote:
Mirja K=C3=BChlewind has en= tered the following ballot position for
draft-ietf-mmusic-sctp-sdp-23: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dr= aft-ietf-mmusic-sctp-sdp/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP?





--001a11459e14a98e450548a6bab6-- From nobody Thu Feb 16 06:38:13 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED9F127A90; Thu, 16 Feb 2017 06:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 OXVguwmzMG_N; Thu, 16 Feb 2017 06:38:08 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E070C129610; Thu, 16 Feb 2017 06:38:07 -0800 (PST) X-AuditID: c1b4fb30-2868b98000002c77-60-58a5b94db1e8 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 34.4B.11383.D49B5A85; Thu, 16 Feb 2017 15:38:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 15:37:33 +0100 From: Christer Holmberg To: Mirja Kuehlewind , The IESG Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1tbXVz?= =?utf-8?Q?ic-sctp-sdp-23:_(with_DISCUSS)?= Thread-Index: AQHSiEaxS+qNKsn/A0y+WNY+OfKww6Frs1fQ Date: Thu, 16 Feb 2017 14:37:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> In-Reply-To: <148724403323.15929.1432579178871938006.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.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7rq7vzqURBh/2Wlm8Wjef2eL9BV2L GX8mMlu8uP6R2eL8zvVMFlOXP2ZxYPOY8nsjq8eSJT+ZPFo+LmQNYI7isklJzcksSy3St0vg ytgy9SNzwRuWig0vnrI2MN5h6WLk5JAQMJH4ufgUkM3FISSwjlHi1rQVjBDOYkaJeSt+AWU4 ONgELCS6/2mDmCICLhKzv3KClDAL3GCUaDv8hA3EERZoYpRYt7iFFcQREWhmlDi94QHYChEB I4nJiy4ygnSzCKhKrO9nBQnzCvhKPF03hxHEFgKy/7UdZwKxOQX8JLZsvM0OYjMKiEl8P7UG LM4sIC5x68l8JoirBSSW7DnPDGGLSrx8/I8VwlaSWHT7MxPIKmYBTYn1u/QhWhUlpnQ/ZIdY KyhxcuYTlgmMorOQTJ2F0DELSccsJB0LGFlWMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgRG 1cEtvw12ML587niIUYCDUYmH90POkggh1sSy4srcQ4wSHMxKIrwZa5dGCPGmJFZWpRblxxeV 5qQWH2KU5mBREuc1W3k/XEggPbEkNTs1tSC1CCbLxMEp1cBovG0Rz+nqS69XBxpzMnQ/9fuU PuN8+q0LMfMfBM5a/Uuc4WNU1O2E7y9UA29a9G7ijHs+m9vSTKfV0OiUgNGFzAsexWe+qr78 pan8pZX7UrtrQVfanxlhD7JPrBSasmZryYvD9jH+UwPkWdzfOcff7/zZqdiUOq3mqJO/4cVZ 4geTLzPXyjxSYinOSDTUYi4qTgQAtr4GgqYCAAA= Archived-At: Cc: "fandreas@cisco.com" , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-sctp-sdp@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:38:12 -0000 SGkgTWlyamEsDQoNCi4uLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQo+IFdoeSBpcyB0aGlzIHVzaW5nIFRDUC9EVExTL1NDVFAgaW5zdGVhZCBvZiBUQ1AvVExT L1NDVFA/CQ0KDQpCZWNhdXNlIHRoZSB3YXkgaXQgaXMgcmVhbGl6ZWQgaXMgYnkgdHJhbnNwb3J0 aW5nIFNDVFAgb24gdG9wIG9mIERUTFMgKGFzIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi10c3Z3Zy1z Y3RwLWR0bHMtZW5jYXBzKSBhbmQgdHJhbnNwb3J0aW5nIERUTFMgb24gdG9wIG9mIFRDUCAoZGVm aW5lZCBpbiBSRkMgNDU3MSkuDQoNClJlZ2FyZHMuDQoNCkNocmlzdGVyDQoNCg0KDQoNCg== From nobody Thu Feb 16 06:40:23 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C85129ACD for ; Thu, 16 Feb 2017 06:40:23 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYnVYXycPCFv for ; Thu, 16 Feb 2017 06:40:21 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E3F129CFB for ; Thu, 16 Feb 2017 06:39:55 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id u143so9120523oif.3 for ; Thu, 16 Feb 2017 06:39:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KgaMbma91B4K1IZdPnkoGrnlbAzkKng2/58GNwS7aBo=; b=JPeM6bhHjT+WOPBVjtx4qoXxfjNva5avI3kL8ZL1cMU7abfsrG00EqWJQ2u+YpEfcp +BSJIjG2tWD0Glr0B8Sgnkhn0wRDxbszjwH5eTom09ebHGY9EipFzzmqdPP1jiPfbTBG zVq+DrqRLasbHQak3hadbxClLn/6UoxvNubtUACpYI/9fgS0uCVJ+8xIfCebnsnFsO/C ff7OS868+gCwTPWyeAzeibarhGHT0+yZnFwG8PMyyjNUYG+1mh83aUt48QWRCQvPKAea 33axLwlqbQfRiT4UDSvo6TT0UPWpak8rkpz2elnin9U3NX3IaICFC6OvrO/dScjnUK+s y+/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KgaMbma91B4K1IZdPnkoGrnlbAzkKng2/58GNwS7aBo=; b=nHmXpNJyYpsyoflQ7zk6J+Y6MRexCan22unxci3MMQvh4pJ2qrdbEbY61A3H5C/aqh UxD/oVXDPrtqsrLp/b4mhcl09OPHgm+Q1PyGZJ7ehzZpR0ruopAFNRD1FwwTqRcLAUBQ s9MkrYcOMJvoTwqH4UUiXvSUYKoMrDgSU7qvHi6e/1m/AG1OeSoIHZxhI4QwWPCRkoRs K4Gj5R9oYLCAxdizRaRWUxF2EYIa46ec8aTFmDUd8Pfx0RDM+rHN0tPt1JZcx/HjIzjU xAEey+7f5J5clVjxptG6NWlZJIK96Wvaj+jPZAh18Wf3JgE7n4tDKw3ZxDEuN7UV/72l 8BBQ== X-Gm-Message-State: AMke39lrISBXf7cymi4A9vj9PH8VPlJxOtJMVkR+mX+e/n3gtMGOMB6cHEhxxJ2ga5FhlVt9HpnnZesW0AgJTA== X-Received: by 10.202.239.132 with SMTP id n126mr1203182oih.186.1487255994476; Thu, 16 Feb 2017 06:39:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.230 with HTTP; Thu, 16 Feb 2017 06:39:14 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Thu, 16 Feb 2017 06:39:14 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c092f6c3dc6f60548a6c587 Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , Mirja Kuehlewind , The IESG , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:40:23 -0000 --94eb2c092f6c3dc6f60548a6c587 Content-Type: text/plain; charset=UTF-8 With that said, why are we registering TCP/DTLS/TCP at all? Is anyone really going to use this without ICE? -Ekr On Thu, Feb 16, 2017 at 6:37 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Mirja, > > ... > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP? > > Because the way it is realized is by transporting SCTP on top of DTLS (as > defined in draft-ietf-tsvwg-sctp-dtls-encaps) and transporting DTLS on > top of TCP (defined in RFC 4571). > > Regards. > > Christer > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c092f6c3dc6f60548a6c587 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
With that said, why are we registering TCP/DTLS/TCP at all= ? Is anyone really going to use this without ICE?

-Ekr


On Thu, Feb 16, 2017 at 6:37 AM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:
Hi Mirja,

...

-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP?

Because the way it is realized is by transporting SCTP on top of DTL= S (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and transporting D= TLS on top of TCP (defined in RFC 4571).

Regards.

Christer




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

--94eb2c092f6c3dc6f60548a6c587-- From nobody Thu Feb 16 06:56:48 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302A8129638 for ; Thu, 16 Feb 2017 06:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 SU46abTDVdno for ; Thu, 16 Feb 2017 06:56:43 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07CD71296E1 for ; Thu, 16 Feb 2017 06:56:42 -0800 (PST) Received: (qmail 5305 invoked from network); 16 Feb 2017 15:56:41 +0100 Received: from public-docking-pat-etx-mapped-0012.ethz.ch (HELO ?10.2.118.92?) (195.176.110.237) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Feb 2017 15:56:41 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> Date: Thu, 16 Feb 2017 15:56:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "fandreas@cisco.com" , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-sctp-sdp@ietf.org" , The IESG , "mmusic@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:56:45 -0000 Hi, > Am 16.02.2017 um 15:37 schrieb Christer Holmberg = : >=20 > Hi Mirja, >=20 > ... >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP?=09 >=20 > Because the way it is realized is by transporting SCTP on top of DTLS = (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and transporting DTLS = on top of TCP (defined in RFC 4571). I got this but DTLS is a mapping to use TLS with UDP because UDP is an = unreliable datagram transport. If you use TCP, you should use TLS. And = rfc4571 is not a mapping of DTLS to TCP. Mirja >=20 > Regards. >=20 > Christer >=20 >=20 >=20 >=20 From nobody Thu Feb 16 07:01:40 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6222129536; Thu, 16 Feb 2017 07:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xHN4_zzU0lmZ; Thu, 16 Feb 2017 07:01:33 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5495A129509; Thu, 16 Feb 2017 07:01:32 -0800 (PST) X-AuditID: c1b4fb25-93e1698000001738-66-58a5beca92af Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id 17.CE.05944.ACEB5A85; Thu, 16 Feb 2017 16:01:30 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 16:00:43 +0100 From: Christer Holmberg To: "Mirja Kuehlewind (IETF)" Thread-Topic: =?iso-8859-1?Q?Mirja_K=FChlewind's_Discuss_on_draft-ietf-mmusic-sctp-sdp-?= =?iso-8859-1?Q?23:_(with_DISCUSS)?= Thread-Index: AQHSiEaxS+qNKsn/A0y+WNY+OfKww6Frs1fQ///1IwCAABFeUA== Date: Thu, 16 Feb 2017 15:00:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> In-Reply-To: <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7se6pfUsjDG7/0bd4tW4+s8X7C7oW M/5MZLZ4cf0js8X5neuZLKYuf8ziwOYx5fdGVo8lS34yebR8XMgawBzFZZOSmpNZllqkb5fA lbFy0mKWgg+sFQffCzQwvmDpYuTkkBAwkWhvWcPWxcjFISSwjlFizpa9rBDOYkaJ/zOWMncx cnCwCVhIdP/TBmkQETCWODz5O1gNs8AnRolVd7azgtQIC9RJnJuqCFFTL/F60Vt2kLCIgJPE 5dulIGEWAVWJLYcXgO3lFfCV2LFyKjPEqpOMEkceHmYCqecEqr/akQBSwyggJvH91BomEJtZ QFzi1pP5TBA3C0gs2XOeGcIWlXj5+B8rhK0ksej2Z6h6PYkbU6ewQdjaEssWvmaG2CsocXLm E5YJjKKzkIydhaRlFpKWWUhaFjCyrGIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjKmDW36r 7mC8/MbxEKMAB6MSD28BMNaEWBPLiitzDzFKcDArifBmrAUK8aYkVlalFuXHF5XmpBYfYpTm YFES5zVbeT9cSCA9sSQ1OzW1ILUIJsvEwSnVwChx4P6cQ8t58zfO5pL2DZn30umJpYd9o4zv fq+flxPcf4YciG6Qai3oaGQT+d/+1f33NqW+R5GNLaY1vfVzBA/f1ul7vs7lU8f9VdXLTzEL eZYvtVMtOpJm8DBk0hX7XwlLendN7iv5lKDfExM+Q/uPE18331yD91Ybt6audm6YXtyz1uyO kRJLcUaioRZzUXEiANICnoulAgAA Archived-At: Cc: "fandreas@cisco.com" , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-sctp-sdp@ietf.org" , The IESG , "mmusic@ietf.org" Subject: Re: [MMUSIC] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:01:34 -0000 Hi, ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- =20 >>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP?=09 >>>=20 >> Because the way it is realized is by transporting SCTP on top of DTLS (a= s defined in draft-ietf-tsvwg-sctp-dtls-encaps) and=20 >> transporting DTLS on top of TCP (defined in RFC 4571). > > I got this but DTLS is a mapping to use TLS with UDP because UDP is an un= reliable datagram transport. If you use TCP, you=20 > should use TLS. And rfc4571 is not a mapping of DTLS to TCP. The framing mechanism of RFC 4571 is used, with DTLS packets sent instead o= f RTP packets. Regards, Christer From nobody Thu Feb 16 07:03:29 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CEB129A30 for ; Thu, 16 Feb 2017 07:03:23 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KzSwLhFLsDE for ; Thu, 16 Feb 2017 07:03:17 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2800129509 for ; Thu, 16 Feb 2017 07:03:17 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id l19so9309191ywc.2 for ; Thu, 16 Feb 2017 07:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ewtVM0ibbD9RP2dGJ4sLPDTmpZQYsFvz/ShIJ4aUM6M=; b=aA2elORnlhZT9RneI/dcwkz/+YwUZz4LoJ8ualjYXChtaR69yA3W3IR5xPcV6zFfBn JW87FnYP8+fqSu9zTWP7w/gDVvvd+RtnO2KAPXJLiYa2F+gjvFqCNGw6eqHVk2I11lFy 25HF0uijvvwWcvzO/n7CGoUJz56AVsX4qRlOZSaoLMoeKPwbmkEoUAA6PN1vQtMS3CAu bG9X3nL6PWIF4L2E3nm9UY3g+rvd7HL7ByEvtzqDq8YhTMcb2VxRurvhXg7xK+ru0jan CE/+GYOGgMXEVKmUFDyAcqgTuyqVi49CvYbhs+pEM2i31uihVC6yP/jNMSuAI58WrspW KVpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ewtVM0ibbD9RP2dGJ4sLPDTmpZQYsFvz/ShIJ4aUM6M=; b=asR//EOawJR4tzFZF4I28jAxUgCnPnDBW+V/NWRCSbIfQsTIv5pQ6oZpnwOfkPBOH/ aDeMwHnNWOIrbWbOO76ZfmNXJGFfpRHJM99FyPfKDmXxoA/Wtpym963tScBcFnybUiW0 fAWM/6FBm6dzHlWH55rUdiegyN1xwsyqLwpEHrEWYQuv3A22zJ0i4VVWxaSOf0FAUfUE L3apS7JQ9lz3I43vR+GR8MjgvGC4JOlmAGOUafhfebjtQKgTLDLG+HnWMgC9SLmOkmv8 I4HD/Opkcnlt+aGUnlqvmy8PF7xYbYZeAPIFeVqeziT3YHvCjack2fEBYsfFzq07Htex kTjw== X-Gm-Message-State: AMke39kUhCeTiBoie+4QOGSlZBvYoUOB463dUQGcPUgR8M+XRC2yo+8ug/TlUjQODNjSTnRMPvAyeriXSBIMuA== X-Received: by 10.129.162.130 with SMTP id z124mr2040136ywg.276.1487257396727; Thu, 16 Feb 2017 07:03:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Thu, 16 Feb 2017 07:02:36 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Thu, 16 Feb 2017 07:02:36 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c129292d2b46d0548a71827 Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , "Mirja Kuehlewind \(IETF\)" , The IESG , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:03:23 -0000 --94eb2c129292d2b46d0548a71827 Content-Type: text/plain; charset=UTF-8 As Christer says. This design is optimized for making the media stack simpler, which using TLS here would not do. -Ekr On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > >>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP? > >>> > >> Because the way it is realized is by transporting SCTP on top of DTLS > (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and > >> transporting DTLS on top of TCP (defined in RFC 4571). > > > > I got this but DTLS is a mapping to use TLS with UDP because UDP is an > unreliable datagram transport. If you use TCP, you > > should use TLS. And rfc4571 is not a mapping of DTLS to TCP. > > The framing mechanism of RFC 4571 is used, with DTLS packets sent instead > of RTP packets. > > Regards, > > Christer > > --94eb2c129292d2b46d0548a71827 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As Christer says. This design is optimized for making the = media stack simpler, which
using TLS here would not do.

<= /div>
-Ekr




On Thu, Feb 16, 2017 = at 7:00 AM, Christer Holmberg <christer.holmberg@ericsson.com= > wrote:
Hi,

-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

>>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP?
>>>
>> Because the way it is realized is by transporting SCTP on top of D= TLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and
>> transporting DTLS on top of TCP (defined in RFC 4571).
>
> I got this but DTLS is a mapping to use TLS with UDP because UDP is an= unreliable datagram transport. If you use TCP, you
> should use TLS. And rfc4571 is not a mapping of DTLS to TCP.

The framing mechanism of RFC 4571 is used, with DTLS packets sent in= stead of RTP packets.

Regards,

Christer


--94eb2c129292d2b46d0548a71827-- From nobody Thu Feb 16 07:12:30 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A12129611 for ; Thu, 16 Feb 2017 07:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 Hu5yCnTsy8Em for ; Thu, 16 Feb 2017 07:12:21 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF94129626 for ; Thu, 16 Feb 2017 07:12:21 -0800 (PST) Received: (qmail 5603 invoked from network); 16 Feb 2017 16:05:38 +0100 Received: from public-docking-pat-etx-mapped-0012.ethz.ch (HELO ?10.2.118.92?) (195.176.110.237) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Feb 2017 16:05:38 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Thu, 16 Feb 2017 16:05:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> To: Eric Rescorla X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , The IESG , Christer Holmberg , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:12:22 -0000 By making the transport stack overly complicated? That really gives me = headache=E2=80=A6 But let me get back the the other question you asked: Is the TCP variant = really needed here? Is this implemented or are there any plans to = implement that? Mirja > Am 16.02.2017 um 16:02 schrieb Eric Rescorla : >=20 > As Christer says. This design is optimized for making the media stack = simpler, which > using TLS here would not do. >=20 > -Ekr >=20 >=20 >=20 >=20 > On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg = wrote: > Hi, >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > >>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP? > >>> > >> Because the way it is realized is by transporting SCTP on top of = DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and > >> transporting DTLS on top of TCP (defined in RFC 4571). > > > > I got this but DTLS is a mapping to use TLS with UDP because UDP is = an unreliable datagram transport. If you use TCP, you > > should use TLS. And rfc4571 is not a mapping of DTLS to TCP. >=20 > The framing mechanism of RFC 4571 is used, with DTLS packets sent = instead of RTP packets. >=20 > Regards, >=20 > Christer >=20 >=20 From nobody Thu Feb 16 07:13:34 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F05129626 for ; Thu, 16 Feb 2017 07:13:32 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78kvteNHZhIk for ; Thu, 16 Feb 2017 07:13:31 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D184129A1A for ; Thu, 16 Feb 2017 07:13:30 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id l19so9472139ywc.2 for ; Thu, 16 Feb 2017 07:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1JDcYZUOegPcAXyD3TwyGxOR9OgBnBwoP1R2dv+CX/o=; b=HqzHNwnzOiQaskLEkoR6JaUNDfpTDoXjcq1kw/ghNXK5uwP0ZX/Ok4ARJzDmm8fcyy PMdxcmL2416/AvG1ynisBXY8/nIb49kg8WLIYQBx7wiZlISa4488rmBPUHWbmWLhvVw+ 0xTVc7zLqlBxiN2VRNLtfl2CqGAEGOVhojh7M7Icij7mO//6rdky8YdDSauLbBR9Kf8z c4z0qpbRDQQTr4ROU9z+LBYeG+URP9Y/QeqaB5KxMQmhqwSCCUv7lfyM4eTvf6D5V3sy ZyI8YkFac9flyuyYDFfzw7CadZg89VVPeg0VuXBQRgbfQj+53uYxIr1z+wQN/BU9ro+y lOKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1JDcYZUOegPcAXyD3TwyGxOR9OgBnBwoP1R2dv+CX/o=; b=ehotKZJgRn1G04dAqX0vL7HJX8uI2hV8eMc127s4QaHnb5wW3R8+RNa2iK35SrHsBb 17c/9l/CGTR2ff8Bs5oB4ndx2R5svY40uhakAb8K2RDxaJ5o+o7+6p//JJXPzf98mNuF aB029sC8D6/RFEpZZ+C/uu7y2D87J32a+2HH8Hc7epSM39JcNsohYFJ1w8kSj3MIHyxl BLTCF64gB1x4kuT1YA7vcSI/FV3vR0pSCW2cdDSJFmOUKXu7SLHYhJRdjeuHcHxQqdHG U+0QGeHWNHBTwoH/eRmQ3x3bpgxDgjgIxht38fBO6d6Ur3kyGHQIIf2PdNZelTZR/0Ws GmtQ== X-Gm-Message-State: AMke39m/voQAyLBXTIt4sR5hVtpAi5Dzzs4NsSxZKMQNwcjvEtZIri3tQ4aaB+M64J64sQFVv/dtUlmyny7BiA== X-Received: by 10.129.132.77 with SMTP id u74mr1857672ywf.125.1487258009229; Thu, 16 Feb 2017 07:13:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.224.131 with HTTP; Thu, 16 Feb 2017 07:12:47 -0800 (PST) In-Reply-To: <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> From: Eric Rescorla Date: Thu, 16 Feb 2017 07:12:47 -0800 Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: multipart/alternative; boundary=001a114f0996548c280548a73d56 Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , The IESG , Christer Holmberg , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:13:32 -0000 --001a114f0996548c280548a73d56 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2017 at 7:05 AM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > By making the transport stack overly complicated? That really gives me > headache=E2=80=A6 > It doesn't make the transport stack overly complicated. It makes it modular. The way that this works is that the transport system (typically ICE) provides a generic transport that appears to be a datagram transport, even if it's actually TCP, and so the thing on top of it just acts as it if were datagram. This is necessary because you may actually switch between TCP and UDP during the life of the connection. But let me get back the the other question you asked: Is the TCP variant > really needed here? Is this implemented or are there any plans to impleme= nt > that? > I think you misunderstood me. People absolutely intend to carry this data over TCP (it's basically the best scenario when you have (a) a centralized service and (b) a UDP-blocking Firewall). We in fact implement this with Firefox. The only question is what should appear in the m=3D proto line. -Ekr > Mirja > > > > > Am 16.02.2017 um 16:02 schrieb Eric Rescorla : > > > > As Christer says. This design is optimized for making the media stack > simpler, which > > using TLS here would not do. > > > > -Ekr > > > > > > > > > > On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > >>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP? > > >>> > > >> Because the way it is realized is by transporting SCTP on top of DTL= S > (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and > > >> transporting DTLS on top of TCP (defined in RFC 4571). > > > > > > I got this but DTLS is a mapping to use TLS with UDP because UDP is a= n > unreliable datagram transport. If you use TCP, you > > > should use TLS. And rfc4571 is not a mapping of DTLS to TCP. > > > > The framing mechanism of RFC 4571 is used, with DTLS packets sent > instead of RTP packets. > > > > Regards, > > > > Christer > > > > > > --001a114f0996548c280548a73d56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 16, 2017 at 7:05 AM, Mirja Kuehlewind (IETF) <ietf@kuehl= ewind.net> wrote:
By makin= g the transport stack overly complicated? That really gives me headache=E2= =80=A6

It doesn't make the transpor= t stack overly complicated. It makes it modular. The way
that thi= s works is that the transport system (typically ICE) provides a generic
transport that appears to be a datagram transport, even if it's = actually TCP, and
so the thing on top of it just acts as it if we= re datagram. This is necessary because
you may actually switch be= tween TCP and UDP during the life of the connection.


But let me get back the the other question you asked: Is the TCP variant re= ally needed here? Is this implemented or are there any plans to implement t= hat?

I think you misunderstood me. Peop= le absolutely intend to carry this data over
TCP (it's basica= lly the best scenario when you have (a) a centralized service
and= (b) a UDP-blocking Firewall). We in fact implement this with Firefox.
The only question is what should appear in the m=3D proto line.
=

-Ekr


Mirja



> Am 16.02.2017 um 16:02 schrieb Eric Rescorla <ekr@rtfm.com>:
>
> As Christer says. This design is optimized for making the media stack = simpler, which
> using TLS here would not do.
>
> -Ekr
>
>
>
>
> On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg <christer.holmberg@ericsson.com&= gt; wrote:
> Hi,
>
> ------------------------------------------------------------= ----------
> DISCUSS:
> ------------------------------------------------------------= ----------
>
> >>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP?<= br> > >>>
> >> Because the way it is realized is by transporting SCTP on top= of DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and
> >> transporting DTLS on top of TCP (defined in RFC 4571).
> >
> > I got this but DTLS is a mapping to use TLS with UDP because UDP = is an unreliable datagram transport. If you use TCP, you
> > should use TLS. And rfc4571 is not a mapping of DTLS to TCP.
>
> The framing mechanism of RFC 4571 is used, with DTLS packets sent inst= ead of RTP packets.
>
> Regards,
>
> Christer
>
>


--001a114f0996548c280548a73d56-- From nobody Thu Feb 16 07:16:28 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A5612962F; Thu, 16 Feb 2017 07:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Rs_Cy8VrdlbT; Thu, 16 Feb 2017 07:16:21 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105D012943F; Thu, 16 Feb 2017 07:16:20 -0800 (PST) X-AuditID: c1b4fb2d-18e0e98000005112-f9-58a5c243e8eb Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 6C.DE.20754.342C5A85; Thu, 16 Feb 2017 16:16:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 16:14:57 +0100 From: Christer Holmberg To: "Mirja Kuehlewind (IETF)" , Eric Rescorla Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1tbXVz?= =?utf-8?Q?ic-sctp-sdp-23:_(with_DISCUSS)?= Thread-Index: AQHSiEaxS+qNKsn/A0y+WNY+OfKww6Frs1fQ///1IwCAABFeUP//8EEAgAAA4YCAABIiwA== Date: Thu, 16 Feb 2017 15:14:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C0043DA@ESESSMB209.ericsson.se> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> In-Reply-To: <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2K7lq7zoaURBrP7RSxerZvPbLHi9Tl2 i/cXdC1m/JnIbPHi+kdmi/M71zNZTF3+mMWB3WPK742sHkuW/GTyaPm4kNVj8uM25gCWKC6b lNSczLLUIn27BK6MXc9OsxUcEag42HyJsYGxR6CLkZNDQsBE4tbPBqYuRi4OIYF1jBIre3ZD OYsZJX5OvsnaxcjBwSZgIdH9TxukQUQgWOLc05vMIDXMAp8YJf693csK4ggLNDFKrFvcAuaI CDQzSpze8IAFoiVMom3/HnYQm0VAVeLbopOMIDavgK/ElvaZLBDrepglHnftZgNJcAo4SVw8 d4UVxGYUEJP4fmoNE4jNLCAucevJfCaIwwUkluw5zwxhi0q8fPyPFcJWklh0+zMTyNnMApoS 63fpQ7QqSkzpfsgOsVdQ4uTMJywTGEVnIZk6C6FjFpKOWUg6FjCyrGIULU4tLs5NNzLWSy3K TC4uzs/Ty0st2cQIjLeDW37r7mBc/drxEKMAB6MSD2/BvqURQqyJZcWVuYcYJTiYlUR4M9YC hXhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamDsbvbP/6fb +MRx+Vxllr+n2K5rdB1pUp/FNWv/PPUHOvvzJ/DUzVvJKhY9le9m00Hzq9L+G27IbIq2uTxN 9b+WacrNowa18vySBr/vT/285ceOZ1Zz03d+mnRw+6KFx5xXHzXSEvt/z3J/dbm7twvrLZkM votVzqdk8q9mttzfd16DUbcgnHOHEktxRqKhFnNRcSIAYDxCqLMCAAA= Archived-At: Cc: "fandreas@cisco.com" , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-sctp-sdp@ietf.org" , "mmusic@ietf.org" , The IESG Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:16:23 -0000 SGksDQoNCj5CeSBtYWtpbmcgdGhlIHRyYW5zcG9ydCBzdGFjayBvdmVybHkgY29tcGxpY2F0ZWQ/ IFRoYXQgcmVhbGx5IGdpdmVzIG1lIGhlYWRhY2hl4oCmDQo+DQo+QnV0IGxldCBtZSBnZXQgYmFj ayB0aGUgdGhlIG90aGVyIHF1ZXN0aW9uIHlvdSBhc2tlZDogSXMgdGhlIFRDUCB2YXJpYW50IHJl YWxseSBuZWVkZWQgaGVyZT8gSXMgdGhpcyBpbXBsZW1lbnRlZCBvciBhcmUgdGhlcmUgYW55IHBs YW5zIHRvIGltcGxlbWVudCB0aGF0Pw0KDQpJJ2QgaGF2ZSB0byBkb3VibGUgY2hlY2sgd2hldGhl ciBlLmcuLCB0aGUgV2ViUlRDIGRhdGEgY2hhbm5lbCBtYW5kYXRlcyBzdXBwb3J0IG9mIFRDUCwg YnV0IGluIGFueSBjYXNlIGRyYWZ0LXNjdHAtc2RwIHJlY29tbWVuZHMgdG8gb25seSB1c2UgaXQg d2hlbiBVRFAgZG9lcyBub3Qgd29yay4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0K PiBBbSAxNi4wMi4yMDE3IHVtIDE2OjAyIHNjaHJpZWIgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0u Y29tPjoNCj4gDQo+IEFzIENocmlzdGVyIHNheXMuIFRoaXMgZGVzaWduIGlzIG9wdGltaXplZCBm b3IgbWFraW5nIHRoZSBtZWRpYSBzdGFjayANCj4gc2ltcGxlciwgd2hpY2ggdXNpbmcgVExTIGhl cmUgd291bGQgbm90IGRvLg0KPiANCj4gLUVrcg0KPiANCj4gDQo+IA0KPiANCj4gT24gVGh1LCBG ZWIgMTYsIDIwMTcgYXQgNzowMCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IEhpLA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBE SVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiA+Pj4gV2h5IGlzIHRoaXMgdXNpbmcgVENQ L0RUTFMvU0NUUCBpbnN0ZWFkIG9mIFRDUC9UTFMvU0NUUD8NCj4gPj4+DQo+ID4+IEJlY2F1c2Ug dGhlIHdheSBpdCBpcyByZWFsaXplZCBpcyBieSB0cmFuc3BvcnRpbmcgU0NUUCBvbiB0b3Agb2Yg DQo+ID4+IERUTFMgKGFzIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi10c3Z3Zy1zY3RwLWR0bHMtZW5j YXBzKSBhbmQgdHJhbnNwb3J0aW5nIERUTFMgb24gdG9wIG9mIFRDUCAoZGVmaW5lZCBpbiBSRkMg NDU3MSkuDQo+ID4NCj4gPiBJIGdvdCB0aGlzIGJ1dCBEVExTIGlzIGEgbWFwcGluZyB0byB1c2Ug VExTIHdpdGggVURQIGJlY2F1c2UgVURQIGlzIA0KPiA+IGFuIHVucmVsaWFibGUgZGF0YWdyYW0g dHJhbnNwb3J0LiBJZiB5b3UgdXNlIFRDUCwgeW91IHNob3VsZCB1c2UgVExTLiBBbmQgcmZjNDU3 MSBpcyBub3QgYSBtYXBwaW5nIG9mIERUTFMgdG8gVENQLg0KPiANCj4gVGhlIGZyYW1pbmcgbWVj aGFuaXNtIG9mIFJGQyA0NTcxIGlzIHVzZWQsIHdpdGggRFRMUyBwYWNrZXRzIHNlbnQgaW5zdGVh ZCBvZiBSVFAgcGFja2V0cy4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiANCj4g DQoNCg== From nobody Thu Feb 16 07:19:31 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CEA129D03 for ; Thu, 16 Feb 2017 07:19:26 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q85MNzlZwuZ4 for ; Thu, 16 Feb 2017 07:19:25 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77872129D08 for ; Thu, 16 Feb 2017 07:19:23 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id v200so9520153ywc.3 for ; Thu, 16 Feb 2017 07:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P/dVOxwyXemFBZLYduYlrLR2A5UrtiClCNlOAlJTrEE=; b=srSKsFG7Zp7aU+C5GceSshTX5915DyIsFG+2CHd5KE84Sgk6HApHXsXCLG9ogeWL4T TbKzDsmWzWVvFVdaspvm3pxROZmDYmseedOtAlpUJ0hE+MCpm3BmSRYwg0xlFpB4xikp HXTKTxjU7P8X+qFw9Pqbgy1ivSUJ3AggXZq9r6vPyU//bndlfqEyAyLdfYLE9kmAPdGy u6bizrtlM+YujZEbutF4Inu2ejuZ61UejNNEjC5fzMLKd6IHPPvxgQEPx3AfWSn5cmkP wPujBqyFqO/0GoD6NooBZ/yYJK9vnMK6l21IFVUUTZDZaDftXmVTr/nYqp6T6YM/dAZ6 VNPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P/dVOxwyXemFBZLYduYlrLR2A5UrtiClCNlOAlJTrEE=; b=VevgSkjrgyHDxyU/SqmKzU263T+WVhN4YhaMSnhYdHewd+rN9Vu3JQvBLdOpgLOqKZ zAEW1kaOkogieGq1TvSNRurWBBiO8prDcAWw/5bwouTErIShZYmCiai59Vn0hoBCXgfl KRW+AP2QlwGhSIPXwSoyHcT5UlyfM10yYEgV1ZSBnDuzNKlZG4lLU+j+DsKFaeIvBpR5 aR6LLHjU1lyNaglkUv1vYECQJP6NsSTKpK2rXQ/t2ExI6vGx41LzfrkV+Gt0wpF5o22l k086tuo6i/4q0ytxsmOkVDCMDEXCgmPaS8ccQ7CUEnKLGzCa+/Gy8xH1haR9SejyFEn4 VA4w== X-Gm-Message-State: AMke39m58wCm90lRPlx4Ni0dPnLm5wjMEf2Yult4foRWfUN6ztzo1MZCmlmH11qyRxCl+ICag8qJdirAkmTBOA== X-Received: by 10.129.137.129 with SMTP id z123mr2029065ywf.327.1487258362702; Thu, 16 Feb 2017 07:19:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.224.131 with HTTP; Thu, 16 Feb 2017 07:18:42 -0800 (PST) In-Reply-To: References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> From: Eric Rescorla Date: Thu, 16 Feb 2017 07:18:42 -0800 Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: multipart/alternative; boundary=94eb2c06bf386614900548a75243 Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , The IESG , Christer Holmberg , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:19:27 -0000 --94eb2c06bf386614900548a75243 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable P.S. I am very familiar with the Firefox implementation of this, and I can tell you that it would be very painful to use TLS when TCP was used and DTLS when UDP is used, and the modest network overhead for using DTLS is, IMO, a better choice. -Ekr On Thu, Feb 16, 2017 at 7:12 AM, Eric Rescorla wrote: > > > On Thu, Feb 16, 2017 at 7:05 AM, Mirja Kuehlewind (IETF) < > ietf@kuehlewind.net> wrote: > >> By making the transport stack overly complicated? That really gives me >> headache=E2=80=A6 >> > > It doesn't make the transport stack overly complicated. It makes it > modular. The way > that this works is that the transport system (typically ICE) provides a > generic > transport that appears to be a datagram transport, even if it's actually > TCP, and > so the thing on top of it just acts as it if were datagram. This is > necessary because > you may actually switch between TCP and UDP during the life of the > connection. > > > But let me get back the the other question you asked: Is the TCP variant >> really needed here? Is this implemented or are there any plans to implem= ent >> that? >> > > I think you misunderstood me. People absolutely intend to carry this data > over > TCP (it's basically the best scenario when you have (a) a centralized > service > and (b) a UDP-blocking Firewall). We in fact implement this with Firefox. > The only question is what should appear in the m=3D proto line. > > -Ekr > > >> Mirja >> >> >> >> > Am 16.02.2017 um 16:02 schrieb Eric Rescorla : >> > >> > As Christer says. This design is optimized for making the media stack >> simpler, which >> > using TLS here would not do. >> > >> > -Ekr >> > >> > >> > >> > >> > On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> > Hi, >> > >> > ---------------------------------------------------------------------- >> > DISCUSS: >> > ---------------------------------------------------------------------- >> > >> > >>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP? >> > >>> >> > >> Because the way it is realized is by transporting SCTP on top of >> DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and >> > >> transporting DTLS on top of TCP (defined in RFC 4571). >> > > >> > > I got this but DTLS is a mapping to use TLS with UDP because UDP is >> an unreliable datagram transport. If you use TCP, you >> > > should use TLS. And rfc4571 is not a mapping of DTLS to TCP. >> > >> > The framing mechanism of RFC 4571 is used, with DTLS packets sent >> instead of RTP packets. >> > >> > Regards, >> > >> > Christer >> > >> > >> >> > --94eb2c06bf386614900548a75243 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
P.S. I am very familiar with the Firefox implementation of= this, and I can tell you
that it would be very painful to use TLS when= TCP was used and DTLS when
UDP is used, and the modest network o= verhead for using DTLS is, IMO,
a better choice.

-Ekr



On Thu, Feb 16, 2017 at 7:= 12 AM, Eric Rescorla <ekr@rtfm.com> wrote:


On Thu, Feb 16, 2017 at 7:05 AM, Mirja K= uehlewind (IETF) <ietf@kuehlewind.net> wrote:
By making the transport stack overly complicated? Tha= t really gives me headache=E2=80=A6

<= div>It doesn't make the transport stack overly complicated. It makes it= modular. The way
that this works is that the transport system (t= ypically ICE) provides a generic
transport that appears to be a d= atagram transport, even if it's actually TCP, and
so the thin= g on top of it just acts as it if were datagram. This is necessary because<= /div>
you may actually switch between TCP and UDP during the life of th= e connection.


But let me get back the the other question you asked: Is the TCP variant re= ally needed here? Is this implemented or are there any plans to implement t= hat?

I think you misunderstood m= e. People absolutely intend to carry this data over
TCP (it's= basically the best scenario when you have (a) a centralized service
<= div>and (b) a UDP-blocking Firewall). We in fact implement this with Firefo= x.
The only question is what should appear in the m=3D proto line= .

-Ekr


Mirja



> Am 16.02.2017 um 16:02 schrieb Eric Rescorla <ekr@rtfm.com>:
>
> As Christer says. This design is optimized for making the media stack = simpler, which
> using TLS here would not do.
>
> -Ekr
>
>
>
>
> On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg <christer.holmberg@eric= sson.com> wrote:
> Hi,
>
> ------------------------------------------------------------= ----------
> DISCUSS:
> ------------------------------------------------------------= ----------
>
> >>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP?<= br> > >>>
> >> Because the way it is realized is by transporting SCTP on top= of DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and
> >> transporting DTLS on top of TCP (defined in RFC 4571).
> >
> > I got this but DTLS is a mapping to use TLS with UDP because UDP = is an unreliable datagram transport. If you use TCP, you
> > should use TLS. And rfc4571 is not a mapping of DTLS to TCP.
>
> The framing mechanism of RFC 4571 is used, with DTLS packets sent inst= ead of RTP packets.
>
> Regards,
>
> Christer
>
>



--94eb2c06bf386614900548a75243-- From nobody Thu Feb 16 07:25:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F6D129665; Thu, 16 Feb 2017 07:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 XP8IZsJLEHlS; Thu, 16 Feb 2017 07:25:43 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B9B12943F; Thu, 16 Feb 2017 07:25:41 -0800 (PST) X-AuditID: c1b4fb3a-b9bff700000021e0-b6-58a5c473a4a5 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by (Symantec Mail Security) with SMTP id 2E.CF.08672.374C5A85; Thu, 16 Feb 2017 16:25:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 16:24:36 +0100 From: Christer Holmberg To: Eric Rescorla , "Mirja Kuehlewind (IETF)" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1tbXVz?= =?utf-8?Q?ic-sctp-sdp-23:_(with_DISCUSS)?= Thread-Index: AQHSiEaxS+qNKsn/A0y+WNY+OfKww6Frs1fQ///1IwCAABFeUP//8EEAgAAA4YCAAAH3gIAAE4kg Date: Thu, 16 Feb 2017 15:24:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4C00443CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyM+JvjW7JkaURBgfmiFq8Wjef2WLF63Ps Fu8v6FrM+DOR2eLF9Y/MFud3rmeymLr8MYsDu8eU3xtZPZYs+cnk0fJxIavH5MdtzAEsUVw2 Kak5mWWpRfp2CVwZ/943sxa88q+Y3LmRtYHxgm8XIyeHhICJxKy2d8xdjFwcQgLrGSU2zr3O AuEsZpSYvOIMUIaDg03AQqL7nzaIKSIQLLHjpSNICbPAJ0aJf2/3soI4wgJNjBLrFreAOSIC zYwSpzc8YAFZISIQJdE6o5MNxGYRUJX4tO8OI4jNK+ArMbd7FyPEtsvMEk39c8GKOAUCJZ42 XAArYhQQk/h+ag0TiM0sIC5x68l8Joi7BSSW7DnPDGGLSrx8/I8VwlaSWHT7M1R9vsSLO/PZ IJYJSpyc+YRlAqPILCSjZiEpm4WkbBbQp8wCmhLrd+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9 FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgfB7c8ttqB+PB546HGAU4GJV4eAv2LY0QYk0s K67MPcQowcGsJMKbsRYoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNds5f1wIYH0xJLU7NTUgtQi mCwTB6dUA+PaBw63vVUdRAp7XtQ8s79d2B2sZfHxZaKkUt/d8h9ztL4tmZZpITJ7gc2v08cX 7Hv1g2Xpt6trpjMEFRtdmXjo8J05KkXBFRVsS089f3ZQUPPW8XduiqEzHaK+xVd8Xnfv3Xr/ mOA7xrc2npuy4dmxZkkJu7q/xTHxpq8q3v6beNDwYWk+Z66GEktxRqKhFnNRcSIAGTEx98sC AAA= Archived-At: Cc: "fandreas@cisco.com" , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-sctp-sdp@ietf.org" , "mmusic@ietf.org" , The IESG Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:25:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4C00443CESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCuKApg0KDQo+VGhlIG9ubHkgcXVlc3Rpb24gaXMgd2hhdCBzaG91bGQgYXBwZWFyIGlu IHRoZSBtPSBwcm90byBsaW5lLg0KDQpFdmVuIGlmIG5vYm9keSBwdXRzIGl0IGluIHRoZSBtPSBs aW5lLCBJIHRoaW5rIGl04oCZcyB1c2VmdWwgdG8ga2VlcCBpdCBpbiB0aGUgZG9jdW1lbnQsIGFz IGl0IGdpdmVzIGFuIG92ZXJ2aWV3IGhvdyBpdOKAmXMgcmVhbGl6ZWQgZXRjLg0KDQpJdCBkb2Vz buKAmXQgY2F1c2UgYW55IGhhcm0gdG8ga2VlcCBpdCwgYW5kIGl04oCZcyDigJxmdXR1cmUgcHJv b2bigJ0gSUYgc29tZW9uZSB3YW50cyB0byB1c2UgaXQgd2l0aG91dCBJQ0UgYXQgc29tZSBwb2lu dC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQo+IEFtIDE2LjAyLjIwMTcgdW0gMTY6MDIg c2NocmllYiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+ Og0KPg0KPiBBcyBDaHJpc3RlciBzYXlzLiBUaGlzIGRlc2lnbiBpcyBvcHRpbWl6ZWQgZm9yIG1h a2luZyB0aGUgbWVkaWEgc3RhY2sgc2ltcGxlciwgd2hpY2gNCj4gdXNpbmcgVExTIGhlcmUgd291 bGQgbm90IGRvLg0KPg0KPiAtRWtyDQo+DQo+DQo+DQo+DQo+IE9uIFRodSwgRmViIDE2LCAyMDE3 IGF0IDc6MDAgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KPiBI aSwNCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+ ID4+PiBXaHkgaXMgdGhpcyB1c2luZyBUQ1AvRFRMUy9TQ1RQIGluc3RlYWQgb2YgVENQL1RMUy9T Q1RQPw0KPiA+Pj4NCj4gPj4gQmVjYXVzZSB0aGUgd2F5IGl0IGlzIHJlYWxpemVkIGlzIGJ5IHRy YW5zcG9ydGluZyBTQ1RQIG9uIHRvcCBvZiBEVExTIChhcyBkZWZpbmVkIGluIGRyYWZ0LWlldGYt dHN2d2ctc2N0cC1kdGxzLWVuY2FwcykgYW5kDQo+ID4+IHRyYW5zcG9ydGluZyBEVExTIG9uIHRv cCBvZiBUQ1AgKGRlZmluZWQgaW4gUkZDIDQ1NzEpLg0KPiA+DQo+ID4gSSBnb3QgdGhpcyBidXQg RFRMUyBpcyBhIG1hcHBpbmcgdG8gdXNlIFRMUyB3aXRoIFVEUCBiZWNhdXNlIFVEUCBpcyBhbiB1 bnJlbGlhYmxlIGRhdGFncmFtIHRyYW5zcG9ydC4gSWYgeW91IHVzZSBUQ1AsIHlvdQ0KPiA+IHNo b3VsZCB1c2UgVExTLiBBbmQgcmZjNDU3MSBpcyBub3QgYSBtYXBwaW5nIG9mIERUTFMgdG8gVENQ Lg0KPg0KPiBUaGUgZnJhbWluZyBtZWNoYW5pc20gb2YgUkZDIDQ1NzEgaXMgdXNlZCwgd2l0aCBE VExTIHBhY2tldHMgc2VudCBpbnN0ZWFkIG9mIFJUUCBwYWNrZXRzLg0KPg0KPiBSZWdhcmRzLA0K Pg0KPiBDaHJpc3Rlcg0KPg0KPg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B4C00443CESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21w b3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ 4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7VGhlIG9ubHkgcXVlc3Rpb24gaXMgd2hhdCBzaG91bGQgYXBwZWFy IGluIHRoZSBtPSBwcm90byBsaW5lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkV2ZW4gaWYgbm9ib2R5IHB1dHMgaXQgaW4g dGhlIG09IGxpbmUsIEkgdGhpbmsgaXTigJlzIHVzZWZ1bCB0byBrZWVwIGl0IGluIHRoZSBkb2N1 bWVudCwgYXMgaXQgZ2l2ZXMgYW4gb3ZlcnZpZXcgaG93IGl04oCZcyByZWFsaXplZCBldGMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkl0IGRvZXNu4oCZdCBjYXVzZSBhbnkgaGFybSB0byBrZWVwIGl0LCBhbmQg aXTigJlzIOKAnGZ1dHVyZSBwcm9vZuKAnSBJRiBzb21lb25lIHdhbnRzIHRvIHVzZSBpdCB3aXRo b3V0IElDRSBhdCBzb21lIHBvaW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCiZndDsgQW0gMTYuMDIuMjAxNyB1bSAxNjowMiBzY2hy aWViIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBy dGZtLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDs8YnI+DQomZ3Q7IEFzIENocmlzdGVyIHNheXMuIFRo aXMgZGVzaWduIGlzIG9wdGltaXplZCBmb3IgbWFraW5nIHRoZSBtZWRpYSBzdGFjayBzaW1wbGVy LCB3aGljaDxicj4NCiZndDsgdXNpbmcgVExTIGhlcmUgd291bGQgbm90IGRvLjxicj4NCiZndDs8 YnI+DQomZ3Q7IC1Fa3I8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBPbiBUaHUsIEZlYiAxNiwgMjAxNyBhdCA3OjAwIEFNLCBDaHJpc3RlciBIb2xtYmVy ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBIaSw8 YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBESVNDVVNTOjxicj4N CiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBXaHkg aXMgdGhpcyB1c2luZyBUQ1AvRFRMUy9TQ1RQIGluc3RlYWQgb2YgVENQL1RMUy9TQ1RQPzxicj4N CiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBCZWNhdXNlIHRoZSB3YXkgaXQg aXMgcmVhbGl6ZWQgaXMgYnkgdHJhbnNwb3J0aW5nIFNDVFAgb24gdG9wIG9mIERUTFMgKGFzIGRl ZmluZWQgaW4gZHJhZnQtaWV0Zi10c3Z3Zy1zY3RwLWR0bHMtZW5jYXBzKSBhbmQ8YnI+DQomZ3Q7 ICZndDsmZ3Q7IHRyYW5zcG9ydGluZyBEVExTIG9uIHRvcCBvZiBUQ1AgKGRlZmluZWQgaW4gUkZD IDQ1NzEpLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJIGdvdCB0aGlzIGJ1dCBEVExT IGlzIGEgbWFwcGluZyB0byB1c2UgVExTIHdpdGggVURQIGJlY2F1c2UgVURQIGlzIGFuIHVucmVs aWFibGUgZGF0YWdyYW0gdHJhbnNwb3J0LiBJZiB5b3UgdXNlIFRDUCwgeW91PGJyPg0KJmd0OyAm Z3Q7IHNob3VsZCB1c2UgVExTLiBBbmQgcmZjNDU3MSBpcyBub3QgYSBtYXBwaW5nIG9mIERUTFMg dG8gVENQLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBmcmFtaW5nIG1lY2hhbmlzbSBvZiBSRkMg NDU3MSBpcyB1c2VkLCB3aXRoIERUTFMgcGFja2V0cyBzZW50IGluc3RlYWQgb2YgUlRQIHBhY2tl dHMuPGJyPg0KJmd0Ozxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBDaHJp c3Rlcjxicj4NCiZndDs8YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4C00443CESESSMB209erics_-- From nobody Thu Feb 16 07:44:40 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9600129A5F for ; Thu, 16 Feb 2017 07:44: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPkFSh8GgTDk for ; Thu, 16 Feb 2017 07:44:30 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E892129D1F for ; Thu, 16 Feb 2017 07:44:30 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id w75so9957184ywg.1 for ; Thu, 16 Feb 2017 07:44:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=sMhcKjr7xck9bESLMtoyVymumahVoK6dLiU3PSmrRvc=; b=HvdNTbmuSplB+TH1M/ZKoMILngp10zPzTU66yxGAVZ4ik+bo0WZAfuBN9MGypKipW7 6yPKRNPUdEPlmcadfbg5g4Jmb4ouCAk8lPF814aFN1sYBMxlCpMzbeEqX5NG5q0PGQwn DNfVe+aM1VraKArzBzWMnPR+vms5qsoR8oFFe066wPMotknzRt/ZIXZeGNJL3lIdgPlP 22+0H6r5ZIvmbCN1SzFDC0wJP2Dki29sX3GngPqnEvgUlN9pKjdo5aUo5jFOWieG7sIN YuXbH99WuEH/3ruomkaVSg1XQFPxlyaEsYONucV63gLR7amnf7zxGZrC9yW8fFens3nf va0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sMhcKjr7xck9bESLMtoyVymumahVoK6dLiU3PSmrRvc=; b=LPFWGRNIknyH9JoVYjhwuKNir7tOdROob7rTfKHdfE4TYjptG2a/7V5/OPi93C1/2n rsDH6yO1jyoseRuHUr7cbeowEcWfl7amgjoVv0patR4FGrVpUIcb+sHi3ZLFfshsxS2j YO7Bk39KxgfOC46EB8+d3thD3IZzVEOHRGCuKz+urDVaRHv0+e5tSBLHHBgdODsWHVxT 1gbWJiOUfKxmgAn84nLhD4lOqX9VRcQki5CQwYWNj2+4ybkZZKNmBcybcx7r5Mfn3Ykv 3x0mgje/biDLR9b3+vE4hnEJ/c7DUUGRPN0V5CUpZPVw7Fz8HHzplHuCRkn9t0fuwvl2 ydAA== X-Gm-Message-State: AMke39lLJLO/qR+aLGqzN7u8v4F3eD8sS+TKLeyG+JGOBVDejeq7BaaoxOLXP+4IYsPl7fVuTFgCWZiQYrCp3Q== X-Received: by 10.129.162.130 with SMTP id z124mr2227245ywg.276.1487259869616; Thu, 16 Feb 2017 07:44:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Thu, 16 Feb 2017 07:43:49 -0800 (PST) From: Eric Rescorla Date: Thu, 16 Feb 2017 07:43:49 -0800 Message-ID: To: mmusic WG , Ben Campbell Content-Type: multipart/alternative; boundary=94eb2c12929237cc8f0548a7ace3 Archived-At: Subject: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:44:31 -0000 --94eb2c12929237cc8f0548a7ace3 Content-Type: text/plain; charset=UTF-8 I raised this with the authors, but maybe it is worth asking the mailing list. It seems like we are trending towards a world where we just ignore the transport component of the proto field and let ICE work things out. In that vein, I wonder do we really need to register/define TCP/DTLS/SCTP. It's only really useful if we think people will do SCTP over DTLS with TCP without ICE. Is that actually likely. I note that per previous discussions, JSEP already requires that you use UDP/DTLS/SCTP all the time: http://rtcweb-wg.github.io/jsep/#rfc.section.5.1.2 -Ekr --94eb2c12929237cc8f0548a7ace3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I raised this with the authors, but maybe it is worth aski= ng the mailing list.

It seems like we are trending towar= ds a world where we just ignore the transport
component of the pr= oto field and let ICE work things out. In that vein, I wonder
do = we really need to register/define TCP/DTLS/SCTP. It's only really usefu= l if
we think people will do SCTP over DTLS with TCP without ICE.= Is that actually
likely. I note that per previous discussions, J= SEP already requires that you use
UDP/DTLS/SCTP all the time:=C2= =A0http://rt= cweb-wg.github.io/jsep/#rfc.section.5.1.2

-Ekr

--94eb2c12929237cc8f0548a7ace3-- From nobody Thu Feb 16 07:51:14 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE851294C1 for ; Thu, 16 Feb 2017 07:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6gf5FpX85MNI for ; Thu, 16 Feb 2017 07:51:10 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A54212948D for ; Thu, 16 Feb 2017 07:51:10 -0800 (PST) X-AuditID: c1b4fb3a-f72d4980000021e0-b9-58a5ca6cc06e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 73.B4.08672.C6AC5A85; Thu, 16 Feb 2017 16:51:08 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 16:51:02 +0100 From: Christer Holmberg To: Eric Rescorla , mmusic WG , Ben Campbell Thread-Topic: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? Thread-Index: AQHSiGuZ0ghkIgIFz0iRXtxKyN1pOqFrx8/w Date: Thu, 16 Feb 2017 15:51:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C004492@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4C004492ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbE9RDfn1NIIg+v3DC3md55mt1jx+hy7 xdTlj1kcmD2WLPnJ5DFr5xMWj8mP25gDmKO4bFJSczLLUov07RK4Mh4s8iroc6zYcGYWYwPj EvsuRk4OCQETiUvfGxi7GLk4hATWMUos/zCJCSQhJLCYUWLH8aQuRg4ONgELie5/2iBhEYF4 iVl3loCVCAs4Sbx5f5UVIu4sce5GEyOEbSSx/slfVpBWFgFViQ9TuUDCvAK+Ehev3mYBCQsJ BEi0LfQGCXMKBEo0TWlhAbEZBcQkvp9aAzadWUBc4taT+UwQVwpILNlznhnCFpV4+fgfK4St JLHo9meo+nyJE1emsEKsEpQ4OfMJywRG4VlIRs1CUjYLSdksoIuYBTQl1u/ShyhRlJjS/ZAd wtaQaJ0zlx1ZfAEj+ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwEg6uOW31Q7Gg88dDzEK cDAq8fAW7FsaIcSaWFZcmXuIUYKDWUmEN2MtUIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr7 4UIC6YklqdmpqQWpRTBZJg5OqQZGra+3kw6/OvDkl5jBz1OtCrvs3FIrH8ldlzyTOKnXnblL 8MUE51uPfloHx8a3T7p4j/ugKkvNurYfC7N9VP7uaVpf6+R7pyPR/9C+36e06thvrzN9bxb1 SGRC2bf7rzpkzOdHdv5391j7lNdS/JHZ1KoFK33F98v0bcivFQ86Oqu+bS7vWzZuJZbijERD Leai4kQAWa1sx6ACAAA= Archived-At: Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:51:12 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4C004492ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk5vdGUgdGhhdCB0aGUgbWVjaGFuaXNtIGlzIGFsc28gdXNlZCBhdCBsZWFzdCBieSBD TFVFLCB3aGljaCBkb2VzIG5vdCBtYW5kYXRlIElDRSAob3IgSlNFUCkuDQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQoNCkZyb206IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogMTYgRmVicnVhcnkgMjAxNyAxNzo0 NA0KVG86IG1tdXNpYyBXRyA8bW11c2ljQGlldGYub3JnPjsgQmVuIENhbXBiZWxsIDxiZW5Abm9z dHJ1bS5jb20+DQpTdWJqZWN0OiBbTU1VU0lDXSBEbyB3ZSByZWFsbHkgbmVlZCBUQ1AvRFRMUy9T Q1RQIHByb3RvIGZpZWxkPw0KDQpJIHJhaXNlZCB0aGlzIHdpdGggdGhlIGF1dGhvcnMsIGJ1dCBt YXliZSBpdCBpcyB3b3J0aCBhc2tpbmcgdGhlIG1haWxpbmcgbGlzdC4NCg0KSXQgc2VlbXMgbGlr ZSB3ZSBhcmUgdHJlbmRpbmcgdG93YXJkcyBhIHdvcmxkIHdoZXJlIHdlIGp1c3QgaWdub3JlIHRo ZSB0cmFuc3BvcnQNCmNvbXBvbmVudCBvZiB0aGUgcHJvdG8gZmllbGQgYW5kIGxldCBJQ0Ugd29y ayB0aGluZ3Mgb3V0LiBJbiB0aGF0IHZlaW4sIEkgd29uZGVyDQpkbyB3ZSByZWFsbHkgbmVlZCB0 byByZWdpc3Rlci9kZWZpbmUgVENQL0RUTFMvU0NUUC4gSXQncyBvbmx5IHJlYWxseSB1c2VmdWwg aWYNCndlIHRoaW5rIHBlb3BsZSB3aWxsIGRvIFNDVFAgb3ZlciBEVExTIHdpdGggVENQIHdpdGhv dXQgSUNFLiBJcyB0aGF0IGFjdHVhbGx5DQpsaWtlbHkuIEkgbm90ZSB0aGF0IHBlciBwcmV2aW91 cyBkaXNjdXNzaW9ucywgSlNFUCBhbHJlYWR5IHJlcXVpcmVzIHRoYXQgeW91IHVzZQ0KVURQL0RU TFMvU0NUUCBhbGwgdGhlIHRpbWU6IGh0dHA6Ly9ydGN3ZWItd2cuZ2l0aHViLmlvL2pzZXAvI3Jm Yy5zZWN0aW9uLjUuMS4yDQoNCi1Fa3INCg0K --_000_7594FB04B1934943A5C02806D1A2204B4C004492ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk5vdGUgdGhhdCB0aGUgbWVjaGFuaXNtIGlzIGFsc28g dXNlZCBhdCBsZWFzdCBieSBDTFVFLCB3aGljaCBkb2VzIG5vdCBtYW5kYXRlIElDRSAob3IgSlNF UCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6PC9i PiAxNiBGZWJydWFyeSAyMDE3IDE3OjQ0PGJyPg0KPGI+VG86PC9iPiBtbXVzaWMgV0cgJmx0O21t dXNpY0BpZXRmLm9yZyZndDs7IEJlbiBDYW1wYmVsbCAmbHQ7YmVuQG5vc3RydW0uY29tJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBbTU1VU0lDXSBEbyB3ZSByZWFsbHkgbmVlZCBUQ1AvRFRMUy9T Q1RQIHByb3RvIGZpZWxkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg cmFpc2VkIHRoaXMgd2l0aCB0aGUgYXV0aG9ycywgYnV0IG1heWJlIGl0IGlzIHdvcnRoIGFza2lu ZyB0aGUgbWFpbGluZyBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SXQgc2VlbXMgbGlrZSB3ZSBhcmUgdHJlbmRpbmcgdG93YXJkcyBhIHdvcmxkIHdo ZXJlIHdlIGp1c3QgaWdub3JlIHRoZSB0cmFuc3BvcnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNvbXBvbmVudCBvZiB0aGUgcHJvdG8gZmllbGQg YW5kIGxldCBJQ0Ugd29yayB0aGluZ3Mgb3V0LiBJbiB0aGF0IHZlaW4sIEkgd29uZGVyPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kbyB3ZSByZWFs bHkgbmVlZCB0byByZWdpc3Rlci9kZWZpbmUgVENQL0RUTFMvU0NUUC4gSXQncyBvbmx5IHJlYWxs eSB1c2VmdWwgaWY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPndlIHRoaW5rIHBlb3BsZSB3aWxsIGRvIFNDVFAgb3ZlciBEVExTIHdpdGggVENQIHdp dGhvdXQgSUNFLiBJcyB0aGF0IGFjdHVhbGx5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5saWtlbHkuIEkgbm90ZSB0aGF0IHBlciBwcmV2aW91cyBk aXNjdXNzaW9ucywgSlNFUCBhbHJlYWR5IHJlcXVpcmVzIHRoYXQgeW91IHVzZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VURQL0RUTFMvU0NUUCBh bGwgdGhlIHRpbWU6Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3J0Y3dlYi13Zy5naXRodWIuaW8vanNl cC8jcmZjLnNlY3Rpb24uNS4xLjIiPmh0dHA6Ly9ydGN3ZWItd2cuZ2l0aHViLmlvL2pzZXAvI3Jm Yy5zZWN0aW9uLjUuMS4yPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4C004492ESESSMB209erics_-- From nobody Thu Feb 16 07:52:44 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048DF1294C1 for ; Thu, 16 Feb 2017 07:52:39 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 0HSofz0F4Ee0 for ; Thu, 16 Feb 2017 07:52:37 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9562C12963C for ; Thu, 16 Feb 2017 07:52:37 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v1GFqaLR096646 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 16 Feb 2017 09:52:36 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Eric Rescorla" Date: Thu, 16 Feb 2017 09:52:24 -0600 Message-ID: <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_BBC7F893-517C-4F35-87AF-A1DE018C38FD_=" Embedded-HTML: [{"HTML":[641, 836], "plain":[245, 595], "uuid":"ACF5B5F8-C73F-4C71-A598-E639148BBB61"}] X-Mailer: MailMate (1.9.6r5344) Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:52:39 -0000 --=_MailMate_BBC7F893-517C-4F35-87AF-A1DE018C38FD_= Content-Type: text/plain; format=flowed Process background: draft-ietf-mmusic-sctp-sdp was on today's IESG telechat. The draft is approved for publication, but with a point raised to ask the WG resolve Ekr's question. Thanks! Ben. On 16 Feb 2017, at 9:43, Eric Rescorla wrote: > I raised this with the authors, but maybe it is worth asking the > mailing > list. > > It seems like we are trending towards a world where we just ignore the > transport > component of the proto field and let ICE work things out. In that > vein, I > wonder > do we really need to register/define TCP/DTLS/SCTP. It's only really > useful > if > we think people will do SCTP over DTLS with TCP without ICE. Is that > actually > likely. I note that per previous discussions, JSEP already requires > that > you use > UDP/DTLS/SCTP all the time: > http://rtcweb-wg.github.io/jsep/#rfc.section.5.1.2 > > -Ekr --=_MailMate_BBC7F893-517C-4F35-87AF-A1DE018C38FD_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Process background: draft-ietf-mmusic-sctp-sdp was on toda= y's IESG telechat. The draft is approved for publication, but with a poin= t raised to ask the WG resolve Ekr's question.

Thanks!

Ben.

On 16 Feb 2017, at 9:43, Eric Rescorla wrote:

I raised this with the authors, but maybe it is worth aski= ng the mailing list.

It seems like we are trending tow= ards a world where we just ignore the transport
component of th= e proto field and let ICE work things out. In that vein, I wonder
do we really need to register/define TCP/DTLS/SCTP. It's only real= ly useful if
we think people will do SCTP over DTLS with TCP wi= thout ICE. Is that actually
likely. I note that per previous di= scussions, JSEP already requires that you use
UDP/DTLS/SCTP all= the time:=C2=A0http://rtcweb-wg.github.io/jsep/#rfc.section.5.1.2
=
-Ekr

--=_MailMate_BBC7F893-517C-4F35-87AF-A1DE018C38FD_=-- From nobody Thu Feb 16 08:56:01 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472D11295D9 for ; Thu, 16 Feb 2017 08:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 EqxlkWXO2POg for ; Thu, 16 Feb 2017 08:55:58 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CDF1294FF for ; Thu, 16 Feb 2017 08:55:58 -0800 (PST) X-AuditID: c1b4fb25-55bff70000001738-b6-58a5d99a4a47 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 6A.62.05944.A99D5A85; Thu, 16 Feb 2017 17:55:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 17:55:54 +0100 From: Christer Holmberg To: Ben Campbell , Eric Rescorla Thread-Topic: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? Thread-Index: AQHSiGuZ0ghkIgIFz0iRXtxKyN1pOqFrt7kAgAAhoiA= Date: Thu, 16 Feb 2017 16:55:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C004589@ESESSMB209.ericsson.se> References: <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.com> In-Reply-To: <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4C004589ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2J7oO6cm0sjDM6t1raY33ma3WLF63Ps FlOXP2ZxYPZYsuQnk8esnU9YPCY/bmMOYI7isklJzcksSy3St0vgymj9PYO5YFVCxcsbv1gb GG/EdjFyckgImEgc/refpYuRi0NIYB2jxOad51lBEkICixklZs1w7WLk4GATsJDo/qcNEhYR cJCY9P0CWAmzgLzEhSVrmEBsYQEniTfvr7JC1DhLnLvRxAhhW0k0zbrJAmKzCKhKzFj7BSzO K+ArcWfSGSaIVa2MEj1/OEBsTgF7iXsbf7GD2IwCYhLfT0HMZxYQl7j1ZD4TxM0CEkv2nGeG sEUlXj7+xwphK0k0LnkCdVu+xNyzk9kgdglKnJz5hGUCo8gsJKNmISmbhaRsFtDHzAKaEut3 6UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmCcHdzy W3UH4+U3jocYBTgYlXh4C/YtjRBiTSwrrsw9xCjBwawkwrv6KlCINyWxsiq1KD++qDQntfgQ ozQHi5I4r9nK++FCAumJJanZqakFqUUwWSYOTqkGRnGu7UsFb1395f71ls8UHZ16gbf++dWO rM6qc+rcGF/+/HjbRbREe3mL/84v35U66zbMzxfYacIf0+s4neVzYPQX5vcSRwIE9vr/+7Dy 8C3lvUW33Zv2ZV1rT8vfU7Ml4keiy7zT9+/apf2ULsicuVjnom78yr5Yq3jfRXyS4mHnS/jf Ve1vUWIpzkg01GIuKk4EAOzEcU6vAgAA Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:56:00 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4C004589ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk15IHN1Z2dlc3Rpb24gaXMgdG8ga2VlcCB0aGUgVENQL0RUTFMvU0NUUCBkZWZpbml0 aW9uLg0KDQpXZSBlYXJsaWVyIG1hZGUgYSBjaG9pY2UgdG8gcmVzdHJpY3QgdGhlIHNjb3BlIG9m IHRoZSBkb2N1bWVudCAoYnkgcmVtb3ZpbmcgcGxhaW4gU0NUUCBhbmQgRFRMUy1vdmVyLVNDVFAg cHJvdG8gdmFsdWVzKSwgYW5kIEkgdGhpbmsgd2Ugc2hvdWxkIGtlZXAgdGhlIGN1cnJlbnQgc2Nv cGUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTogbW11c2ljIFttYWlsdG86bW11 c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZW4gQ2FtcGJlbGwNClNlbnQ6IDE2 IEZlYnJ1YXJ5IDIwMTcgMTc6NTINClRvOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+DQpD YzogbW11c2ljIFdHIDxtbXVzaWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gRG8g d2UgcmVhbGx5IG5lZWQgVENQL0RUTFMvU0NUUCBwcm90byBmaWVsZD8NCg0KDQpQcm9jZXNzIGJh Y2tncm91bmQ6IGRyYWZ0LWlldGYtbW11c2ljLXNjdHAtc2RwIHdhcyBvbiB0b2RheSdzIElFU0cg dGVsZWNoYXQuIFRoZSBkcmFmdCBpcyBhcHByb3ZlZCBmb3IgcHVibGljYXRpb24sIGJ1dCB3aXRo IGEgcG9pbnQgcmFpc2VkIHRvIGFzayB0aGUgV0cgcmVzb2x2ZSBFa3IncyBxdWVzdGlvbi4NCg0K VGhhbmtzIQ0KDQpCZW4uDQoNCk9uIDE2IEZlYiAyMDE3LCBhdCA5OjQzLCBFcmljIFJlc2Nvcmxh IHdyb3RlOg0KSSByYWlzZWQgdGhpcyB3aXRoIHRoZSBhdXRob3JzLCBidXQgbWF5YmUgaXQgaXMg d29ydGggYXNraW5nIHRoZSBtYWlsaW5nIGxpc3QuDQoNCkl0IHNlZW1zIGxpa2Ugd2UgYXJlIHRy ZW5kaW5nIHRvd2FyZHMgYSB3b3JsZCB3aGVyZSB3ZSBqdXN0IGlnbm9yZSB0aGUgdHJhbnNwb3J0 DQpjb21wb25lbnQgb2YgdGhlIHByb3RvIGZpZWxkIGFuZCBsZXQgSUNFIHdvcmsgdGhpbmdzIG91 dC4gSW4gdGhhdCB2ZWluLCBJIHdvbmRlcg0KZG8gd2UgcmVhbGx5IG5lZWQgdG8gcmVnaXN0ZXIv ZGVmaW5lIFRDUC9EVExTL1NDVFAuIEl0J3Mgb25seSByZWFsbHkgdXNlZnVsIGlmDQp3ZSB0aGlu ayBwZW9wbGUgd2lsbCBkbyBTQ1RQIG92ZXIgRFRMUyB3aXRoIFRDUCB3aXRob3V0IElDRS4gSXMg dGhhdCBhY3R1YWxseQ0KbGlrZWx5LiBJIG5vdGUgdGhhdCBwZXIgcHJldmlvdXMgZGlzY3Vzc2lv bnMsIEpTRVAgYWxyZWFkeSByZXF1aXJlcyB0aGF0IHlvdSB1c2UNClVEUC9EVExTL1NDVFAgYWxs IHRoZSB0aW1lOiBodHRwOi8vcnRjd2ViLXdnLmdpdGh1Yi5pby9qc2VwLyNyZmMuc2VjdGlvbi41 LjEuMg0KDQotRWtyDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B4C004589ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NeSBzdWdn ZXN0aW9uIGlzIHRvIGtlZXAgdGhlIFRDUC9EVExTL1NDVFAgZGVmaW5pdGlvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldlIGVhcmxpZXIgbWFkZSBhIGNob2ljZSB0 byByZXN0cmljdCB0aGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50IChieSByZW1vdmluZyBwbGFpbiBT Q1RQIGFuZCBEVExTLW92ZXItU0NUUCBwcm90byB2YWx1ZXMpLCBhbmQgSSB0aGluaw0KIHdlIHNo b3VsZCBrZWVwIHRoZSBjdXJyZW50IHNjb3BlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5h bWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmVuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+IDE2 IEZlYnJ1YXJ5IDIwMTcgMTc6NTI8YnI+DQo8Yj5Ubzo8L2I+IEVyaWMgUmVzY29ybGEgJmx0O2Vr ckBydGZtLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG1tdXNpYyBXRyAmbHQ7bW11c2ljQGlldGYu b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gRG8gd2UgcmVhbGx5IG5l ZWQgVENQL0RUTFMvU0NUUCBwcm90byBmaWVsZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5Qcm9jZXNzIGJhY2tncm91bmQ6IGRyYWZ0LWlldGYtbW11c2ljLXNjdHAt c2RwIHdhcyBvbiB0b2RheSdzIElFU0cgdGVsZWNoYXQuIFRoZSBkcmFmdCBpcyBhcHByb3ZlZCBm b3IgcHVibGljYXRpb24sIGJ1dCB3aXRoIGEgcG9pbnQgcmFpc2VkIHRvIGFzayB0aGUgV0cgcmVz b2x2ZSBFa3IncyBxdWVzdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzITxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj5CZW4uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5PbiAxNiBG ZWIgMjAxNywgYXQgOTo0MywgRXJpYyBSZXNjb3JsYSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjNzc3Nzc3IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6 MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTozLjc1cHQiPg0KPGRpdiBpZD0iQUNG NUI1RjgtQzczRi00QzcxLUE1OTgtRTYzOTE0OEJCQjYxIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNzc3Nzc3Ij5JIHJhaXNlZCB0aGlzIHdpdGggdGhlIGF1dGhvcnMsIGJ1dCBt YXliZSBpdCBpcyB3b3J0aCBhc2tpbmcgdGhlIG1haWxpbmcgbGlzdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6Izc3Nzc3NyI+SXQgc2VlbXMgbGlrZSB3ZSBhcmUgdHJlbmRpbmcgdG93YXJkcyBhIHdvcmxk IHdoZXJlIHdlIGp1c3QgaWdub3JlIHRoZSB0cmFuc3BvcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5jb21wb25l bnQgb2YgdGhlIHByb3RvIGZpZWxkIGFuZCBsZXQgSUNFIHdvcmsgdGhpbmdzIG91dC4gSW4gdGhh dCB2ZWluLCBJIHdvbmRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPmRvIHdlIHJlYWxseSBuZWVkIHRvIHJlZ2lz dGVyL2RlZmluZSBUQ1AvRFRMUy9TQ1RQLiBJdCdzIG9ubHkgcmVhbGx5IHVzZWZ1bCBpZjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM3Nzc3NzciPndlIHRoaW5rIHBlb3BsZSB3aWxsIGRvIFNDVFAgb3ZlciBEVExTIHdpdGggVENQ IHdpdGhvdXQgSUNFLiBJcyB0aGF0IGFjdHVhbGx5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+bGlrZWx5LiBJIG5v dGUgdGhhdCBwZXIgcHJldmlvdXMgZGlzY3Vzc2lvbnMsIEpTRVAgYWxyZWFkeSByZXF1aXJlcyB0 aGF0IHlvdSB1c2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5VRFAvRFRMUy9TQ1RQIGFsbCB0aGUgdGltZTombmJz cDs8YSBocmVmPSJodHRwOi8vcnRjd2ViLXdnLmdpdGh1Yi5pby9qc2VwLyNyZmMuc2VjdGlvbi41 LjEuMiI+aHR0cDovL3J0Y3dlYi13Zy5naXRodWIuaW8vanNlcC8jcmZjLnNlY3Rpb24uNS4xLjI8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6Izc3Nzc3NyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPi1Fa3I8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj Nzc3Nzc3Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4C004589ESESSMB209erics_-- From nobody Thu Feb 16 09:07:49 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541BB129633 for ; Thu, 16 Feb 2017 09:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5WoZghSP2wMk for ; Thu, 16 Feb 2017 09:07:46 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D044129675 for ; Thu, 16 Feb 2017 09:07:40 -0800 (PST) X-AuditID: c1b4fb2d-18e0e98000005112-3d-58a5dc5a9635 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 38.42.20754.A5CD5A85; Thu, 16 Feb 2017 18:07:39 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 18:07:20 +0100 From: Christer Holmberg To: Eric Rescorla , mmusic WG Thread-Topic: [MMUSIC] Issue #27: Allow RTP attributes in non-media m= sections Thread-Index: AQHSiF+7PjHVV4um5k+nn0lmLGqqn6Fr2vKw Date: Thu, 16 Feb 2017 17:07:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4C0045CBESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbHdUjf6ztIIgyO3WCxWvD7HbjF1+WMW ByaPJUt+MnlMftzGHMAUxWWTkpqTWZZapG+XwJWx72MDe8GDxIo3h66zNjD2xHcxcnJICJhI XD7ymrmLkYtDSGAdo8T0a/sYIZzFjBLXJrUBORwcbAIWEt3/tEEaRARsJXp6j4CFhQUCJG6c loAIB0rcab/JDhIWETCSuP8yASTMIqAqsW7dKWaQMK+Ar8Te22BhIaDGae8egFVzAnU+exQC EmYUEJP4fmoNE4jNLCAucevJfCaIIwUkluw5zwxhi0q8fPyPFcJWkmhc8oQVoj5f4smk8+wg Nq+AoMTJmU9YJjAKz0IyahaSsllIymYBXcEsoCmxfpc+RImixJTuh+wQtoZE65y57MjiCxjZ VzGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIERs3BLb91dzCufu14iFGAg1GJh7dg39IIIdbE suLK3EOMEhzMSiK8q68ChXhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBa BJNl4uCUamBc6RmyQ7Jm0taYNPtbbd8/zTj1vUI7Zplm7vTr6SGp6xS+/fh1I2DnKuk4tYiY Z4bnHXsCj3YKKE5v3Dn5x8k14RWvI1SsDlouFN9m7qtbYW/cs2Wty7xFgsIuet3nDb7d9595 W/OrhE3OzQcv+k/afTIX05nOV7xWxSrv8BaTVRenB7Iy9+crsRRnJBpqMRcVJwIA7VkEHZYC AAA= Archived-At: Subject: Re: [MMUSIC] Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:07:47 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4C0045CBESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5TZWU6DQo+aHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LXNkcC1idW5kbGUv aXNzdWVzLzI3DQo+aHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9qc2VwL2lzc3Vlcy81MjgN Cj4NCj5UaGUgYmFzaWMgaXNzdWUgaXMgdGhhdCBpdCdzIHBvc3NpYmxlIHRvIGhhdmUgYSBzaXR1 YXRpb24gd2hlcmUgeW91IGhhdmUgYm90aA0KPm1lZGlhIGFuZCBkYXRhIG09IHNlY3Rpb25zIGJ1 dCB0aGUgQlVORExFIHRhZyBpcyBhc3NvY2lhdGVkIHdpdGggdGhlIGRhdGENCj5tPSBzZWN0aW9u IGFuZCBub3cgeW91IG5lZWQgdG8gcHV0IHRoZSBUUkFOU1BPUlQgYW5kIElERU5USUNBTA0KPmF0 dHJpYnV0ZXMgc29tZXdoZXJlLiBUaGUgSlNFUCBlZGl0b3JzIGRpc2N1c3NlZCB0aGlzIGFuZCBj YW1lIHRvIHRoZQ0KPmNvbmNsdXNpb24gdGhhdCBpdCBzaG91bGQgZ28gd2l0aCB0aGUgQlVORExF IHRhZyAoaS5lLiwgaW4gdGhlIGRhdGEgbT0gc2VjdGlvbikNCj5hbmQgdGhhdCBCVU5ETEUgc2hv dWxkIGZvcmJpZCB0aGlzLCBidXQgaXQgcmVxdWlyZXMgYSBjaGFuZ2UgdG8gQlVORExFLg0KDQpE aWQgeW91IG1lYW4gdG8gc2F5IHRoYXQgQlVORExFIHNob3VsZCBOT1QgZm9yYmlkIHRoaXM/DQoN CkJhc2VkIG9uIHlvdXIgR2l0SHViIGRpc2N1c3Npb24sIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhh dCB5b3Ugd2FudCB0byBhbGxvdyB0byBpbmNsdWRlIFJUUC1zcGVjaWZpYyBwYXJhbWV0ZXJzICji gJhydGNwLW11eOKAmSwg4oCYcnRjcOKAmSwg4oCYcnRjcC1tdXgtb25seeKAmSBhdHRyaWJ1dGVz IGV0YykgaW4gdGhlIGRhdGEgbT0gc2VjdGlvbi4NCg0KVG8gcmVwZWF0IHdoYXQgSSBzYWlkIG9u IEdpdEh1YjoNCg0KVGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgaW4gdGhlIHBhc3QsIGFuZCB0aGUg b3V0Y29tZSBoYXMgYmVlbiB0byBub3cgYWxsb3cgUlRQLXNwZWNpZmljIHBhcmFtZXRlcnMgaW4g bm9uLVJUUCBtPSBzZWN0aW9ucy4NCg0KQSBzb2x1dGlvbiB3b3VsZCBiZSB0byBzaW1wbHkgY2hh bmdlIHRoZSBidW5kbGUgdGFnIHdoZW4gdGhlIFJUUCBtPSBzZWN0aW9ucyBhcmUgYWRkZWQuDQoN CuKApk9SLCB3ZSBjaGFuZ2UgdGhlIG11eCBjYXRlZ29yeSBmb3IgdGhlIFJUUC1zcGVjaWZpYyBw YXJhbWV0ZXJzLiBCdXQsIHRoYXQgb2YgY291cnNlIG1lYW5zIHRoZXkgaGF2ZSB0byBiZSBhZGRl ZCB0byBldmVyeSBSVFAgbT0gc2VjdGlvbi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== --_000_7594FB04B1934943A5C02806D1A2204B4C0045CBESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY0OTk4 OTk4NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk5 MDE0NTQgMTM0ODA3NTY5IDEzNDgwNzU3NyAxMzQ4MDc1NzkgMTM0ODA3NTY3IDEzNDgwNzU3NyAx MzQ4MDc1NzkgMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1Nzk7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVs Nw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdC IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj5TZWU6PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxhIGhyZWY9Imh0dHBzOi8v Z2l0aHViLmNvbS9jZGg0dS9kcmFmdC1zZHAtYnVuZGxlL2lzc3Vlcy8yNyI+aHR0cHM6Ly9naXRo dWIuY29tL2NkaDR1L2RyYWZ0LXNkcC1idW5kbGUvaXNzdWVzLzI3PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxhIGhyZWY9Imh0dHBz Oi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvanNlcC9pc3N1ZXMvNTI4Ij5odHRwczovL2dpdGh1Yi5j b20vcnRjd2ViLXdnL2pzZXAvaXNzdWVzLzUyODwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtUaGUgYmFzaWMgaXNzdWUgaXMg dGhhdCBpdCdzIHBvc3NpYmxlIHRvIGhhdmUgYSBzaXR1YXRpb24gd2hlcmUgeW91IGhhdmUgYm90 aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 O21lZGlhIGFuZCBkYXRhIG09IHNlY3Rpb25zIGJ1dCB0aGUgQlVORExFIHRhZyBpcyBhc3NvY2lh dGVkIHdpdGggdGhlIGRhdGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZndDttPSBzZWN0aW9uIGFuZCBub3cgeW91IG5lZWQgdG8gcHV0IHRoZSBU UkFOU1BPUlQgYW5kIElERU5USUNBTDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0O2F0dHJpYnV0ZXMgc29tZXdoZXJlLiBUaGUgSlNFUCBlZGl0 b3JzIGRpc2N1c3NlZCB0aGlzIGFuZCBjYW1lIHRvIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O2NvbmNsdXNpb24gdGhhdCBpdCBzaG91 bGQgZ28gd2l0aCB0aGUgQlVORExFIHRhZyAoaS5lLiwgaW4gdGhlIGRhdGEgbT0gc2VjdGlvbik8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDth bmQgdGhhdCBCVU5ETEUgc2hvdWxkIGZvcmJpZCB0aGlzLCBidXQgaXQgcmVxdWlyZXMgYSBjaGFu Z2UgdG8gQlVORExFLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkRpZCB5b3UgbWVhbiB0byBzYXkgdGhhdCBCVU5ETEUgc2hvdWxkIE5PVCBm b3JiaWQgdGhpcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QmFzZWQgb24geW91ciBHaXRIdWIgZGlzY3Vzc2lv biwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHlvdSB3YW50IHRvIGFsbG93IHRvIGluY2x1ZGUg UlRQLXNwZWNpZmljIHBhcmFtZXRlcnMgKOKAmHJ0Y3AtbXV44oCZLCDigJhydGNw4oCZLCDigJhy dGNwLW11eC1vbmx54oCZIGF0dHJpYnV0ZXMgZXRjKSBpbiB0aGUgZGF0YQ0KIG09IHNlY3Rpb24u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlRvIHJlcGVhdCB3aGF0IEkgc2FpZCBvbiBHaXRIdWI6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlRoaXMgaGFzIGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBwYXN0LCBhbmQgdGhlIG91dGNv bWUgaGFzIGJlZW4gdG8gbm93IGFsbG93IFJUUC1zcGVjaWZpYyBwYXJhbWV0ZXJzIGluIG5vbi1S VFAgbT0gc2VjdGlvbnMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QSBzb2x1dGlvbiB3b3VsZCBiZSB0byBz aW1wbHkgY2hhbmdlIHRoZSBidW5kbGUgdGFnIHdoZW4gdGhlIFJUUCBtPSBzZWN0aW9ucyBhcmUg YWRkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKApk9SLCB3ZSBjaGFuZ2UgdGhlIG11eCBjYXRlZ29yeSBm b3IgdGhlIFJUUC1zcGVjaWZpYyBwYXJhbWV0ZXJzLiBCdXQsIHRoYXQgb2YgY291cnNlIG1lYW5z IHRoZXkgaGF2ZSB0byBiZSBhZGRlZCB0byBldmVyeSBSVFAgbT0gc2VjdGlvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4C0045CBESESSMB209erics_-- From nobody Thu Feb 16 09:16:42 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68D4129663 for ; Thu, 16 Feb 2017 09:16:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUzPyOvwjCr3 for ; Thu, 16 Feb 2017 09:16:39 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA971295A6 for ; Thu, 16 Feb 2017 09:16:39 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id 11so21483040qkl.3 for ; Thu, 16 Feb 2017 09:16:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0IWOslrZAfhGcctuqPfesBhD5kWFQjZ/p+X086TcVD0=; b=j/CLV5DRu4Sh9RjLXNhy8m7OYRaFKG2SFV1JWTB3W6533YBTI7C8Rvn+W6/uccj0+3 5/7Zuy7b/BIVBHe1uqIcCHf2ON72JkKYYmg06+irVVt+wMkDhhwQu/IV1LacSpHK6Zis THxduLyYsRZO7vyzi+BBbPzTgs4zuhj0ziTNJzV4yuBntPspY6Y9+tb2VJqCaV/chFJt gCLHk8yd27/DvhLCWwPZBCb+AgvPji8SBk5OS4yhYAz5OywrL/c02xAijAVI3JEa4YhP jLIHl2sx5llUXMa7n9Qy+8vjDDHMDLLuV/LHCZShXnlLtNobprzJShNUxEXCzm/NSNNh Czyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0IWOslrZAfhGcctuqPfesBhD5kWFQjZ/p+X086TcVD0=; b=IBIdM+usXkne9+L7oXldOPJ8weSKNb7HiHnhyN8vgesJr8c/9SJZf8TOT4u9tr9MDv PgAWHZrR7DUXuyyFxCxvUkiEiKM3BnMVm2D5CHoOEY8QUV1K10mbQq7JRXD4LjEJaObQ ei86HhptxpNmKCFn0qwgSTT8SuLxpYYuCHkrJgCUuVhBslhxaoj3i++/02PcSvvL28fP mgqVtOOGmkekBbZt7q1V27M0hxUfv1uYNyIk7C30rAhhVptzejjMmTXH5OicqbQA/EYg scjedTySuAq2gB/jFz0D6o0+tmkRBmO7qgcSk3P2gAPq/W8ecjax1THM/T2tkBGNTNMO V3SQ== X-Gm-Message-State: AMke39m1AptV4/28s2FGlziMb2GjAd7MjnYZV2jkXRqo7aSd1Vp1BZhJtH/n6L/watF/9A== X-Received: by 10.55.215.149 with SMTP id t21mr3398998qkt.196.1487265398530; Thu, 16 Feb 2017 09:16:38 -0800 (PST) Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com. [209.85.220.174]) by smtp.gmail.com with ESMTPSA id y23sm4780186qtc.38.2017.02.16.09.16.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 09:16:38 -0800 (PST) Received: by mail-qk0-f174.google.com with SMTP id p22so21885945qka.0 for ; Thu, 16 Feb 2017 09:16:37 -0800 (PST) X-Received: by 10.55.17.206 with SMTP id 75mr3008955qkr.34.1487265397676; Thu, 16 Feb 2017 09:16:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Thu, 16 Feb 2017 09:16:37 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4C004589@ESESSMB209.ericsson.se> References: <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4C004589@ESESSMB209.ericsson.se> From: Roman Shpount Date: Thu, 16 Feb 2017 12:16:37 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1146c91eb77b060548a8f50f Archived-At: Cc: Ben Campbell , mmusic WG Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:16:41 -0000 --001a1146c91eb77b060548a8f50f Content-Type: text/plain; charset=UTF-8 The way ICE is currently defined, ICE enabled end points are supposed to send a re-INVITE after nomination process is completed with the selected candidate address in the m= line. So, if tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP in the m= line. Also, any offers/answers after the ICE nomination is complete, are supposed to send the currently selected candidate in the m= line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected. Based on all of this, I would strongly suggest to keep TCP/DTLS/SCTP. Regards, _____________ Roman Shpount On Thu, Feb 16, 2017 at 11:55 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > My suggestion is to keep the TCP/DTLS/SCTP definition. > > > > We earlier made a choice to restrict the scope of the document (by > removing plain SCTP and DTLS-over-SCTP proto values), and I think we should > keep the current scope. > > > > Regards, > > > > Christer > > > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Ben > Campbell > *Sent:* 16 February 2017 17:52 > *To:* Eric Rescorla > *Cc:* mmusic WG > *Subject:* Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? > > > > Process background: draft-ietf-mmusic-sctp-sdp was on today's IESG > telechat. The draft is approved for publication, but with a point raised to > ask the WG resolve Ekr's question. > > Thanks! > > Ben. > > On 16 Feb 2017, at 9:43, Eric Rescorla wrote: > > I raised this with the authors, but maybe it is worth asking the mailing > list. > > > > It seems like we are trending towards a world where we just ignore the > transport > > component of the proto field and let ICE work things out. In that vein, I > wonder > > do we really need to register/define TCP/DTLS/SCTP. It's only really > useful if > > we think people will do SCTP over DTLS with TCP without ICE. Is that > actually > > likely. I note that per previous discussions, JSEP already requires that > you use > > UDP/DTLS/SCTP all the time: http://rtcweb-wg.github. > io/jsep/#rfc.section.5.1.2 > > > > -Ekr > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a1146c91eb77b060548a8f50f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The way ICE is currently defined, ICE enabled end points a= re supposed to send a re-INVITE after nomination process is completed with = the selected candidate address in the m=3D line. So, if tcp candidate is se= lected, re-INVITE must be sent with TCP/DTLS/SCTP in the m=3D line. Also, a= ny offers/answers after the ICE nomination is complete, are supposed to sen= d the currently selected candidate in the m=3D line, which will also be TCP= /DTLS/SCTP in case tcp candidate is selected.

Based on a= ll of this, I would strongly suggest to keep TCP/DTLS/SCTP.

<= /div>
Regards,

=
____= _________
Roman Shpount

On Thu, Feb 16, 2017 at 11:55 AM, Christer H= olmberg <christer.holmberg@ericsson.com> wrote:=

Hi,

=C2=A0

My suggestion is to keep the TCP/DTLS= /SCTP definition.

=C2=A0

We earlier made a choice to restrict = the scope of the document (by removing plain SCTP and DTLS-over-SCTP proto = values), and I think we should keep the current scope.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">=C2=A0

From: = mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: 16 February 2017 17:52
To: Eric Rescorla <ekr@rtfm.com>
Cc: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?

=C2=A0

Process backgro= und: draft-ietf-mmusic-sctp-sdp was on today's IESG telechat. The draft= is approved for publication, but with a point raised to ask the WG resolve= Ekr's question.

Thanks!<= u>

Ben. =

On 16 Feb 2017,= at 9:43, Eric Rescorla wrote:

I raised this with the authors, but maybe it is worth as= king the mailing list.

=C2=A0

It seems like we are trending towards a world where we j= ust ignore the transport

component of the proto field and let ICE work things out= . In that vein, I wonder

do we really need to register/define TCP/DTLS/SCTP. It&#= 39;s only really useful if

we think people will do SCTP over DTLS with TCP without = ICE. Is that actually

likely. I note that per previous discussions, JSEP alrea= dy requires that you use

UDP/DTLS/SCTP all the time:=C2=A0http://rtcweb-wg.= github.io/jsep/#rfc.section.5.1.2

=C2=A0

-Ekr

=C2=A0


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

--001a1146c91eb77b060548a8f50f-- From nobody Thu Feb 16 09:38:49 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A46129535 for ; Thu, 16 Feb 2017 09:38:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BHhUiGOqKb1 for ; Thu, 16 Feb 2017 09:38:47 -0800 (PST) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E67EE12946A for ; Thu, 16 Feb 2017 09:38:46 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id j82so6242884ybg.1 for ; Thu, 16 Feb 2017 09:38:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UvtITq0W5R2esHXR8Kz4QiDA46x4qlqmNZxI6nCH8to=; b=EfkzgeETCsxDMIsGVxtmP0LW1BDFVyiJXU9v08YoXfVg9/1H44uHDc4VBRYgqOksjB YpJs3Gm5TkmychDUbOL7f/tp7lTFnah3XaUj7DvK+QTJlQgdMH+CeBR+wH+UHTmVUAow tWd89U8MYIO1fAVSeG0fE2IViXb/pIDgzOn+6DKPEYkmL1LFcLbkEsoCnfX9fhK3k844 NOEajx1xVOpBb892ivA/uRJzMIz3AA5brOUQYaR7me6qeRDKqwAWZ8nyibxuyivk7ZOB duMG6cPQEIh3y6eQzo9HikSLmD/mzwDYtoqVzRR+QQidJEe9a3ybVy93GtXmrxOR7jqu b7bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UvtITq0W5R2esHXR8Kz4QiDA46x4qlqmNZxI6nCH8to=; b=SIHiYBwiUcGi6ZbkMsO60dWhGDBIgkA6Ro18UMHMGadgik6tGfklFQ+cDA4fSIT5Zd Ft02W9PQXF5rSrKRqISZzsjiPNHLDNa64PmR2hPp1kDEBfHJB32Tzr8twf/p+clSlpab pSqxXRm9A/FWAasu0cUNJuX3XWixnhu8v8cLRETLtSiq3RcrjD3Rt8Kg79Q5EVI6bh7W RH1iW1zM6lj72P533/4ToKpRZljkZtuWZgbEQgelOAx2YpgpVKxQ9oeftTHi0QRWgiG/ XPIipPIX7lIPt99e/KuwLHDs94F+ZVcZ6MBy7QiaXY17HDwND0GhZu8qAPFWtQY66X4u oRBg== X-Gm-Message-State: AMke39nluwNQpVTpKbN0N0+jlaHLuPSNVQ4d1IjJA5r4AtzrkA3MPUtIkhsgYKyEFuzhlalqVMp7eQ65hSCKsg== X-Received: by 10.37.78.3 with SMTP id c3mr2415898ybb.180.1487266725996; Thu, 16 Feb 2017 09:38:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Thu, 16 Feb 2017 09:38:05 -0800 (PST) In-Reply-To: References: <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4C004589@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Thu, 16 Feb 2017 09:38:05 -0800 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=001a113e7faee40f920548a944f1 Archived-At: Cc: Ben Campbell , mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:38:48 -0000 --001a113e7faee40f920548a944f1 Content-Type: text/plain; charset=UTF-8 I also think the re-INVITE is unnecessary. -Ekr On Thu, Feb 16, 2017 at 9:16 AM, Roman Shpount wrote: > The way ICE is currently defined, ICE enabled end points are supposed to > send a re-INVITE after nomination process is completed with the selected > candidate address in the m= line. So, if tcp candidate is selected, > re-INVITE must be sent with TCP/DTLS/SCTP in the m= line. Also, any > offers/answers after the ICE nomination is complete, are supposed to send > the currently selected candidate in the m= line, which will also be > TCP/DTLS/SCTP in case tcp candidate is selected. > > Based on all of this, I would strongly suggest to keep TCP/DTLS/SCTP. > > Regards, > > _____________ > Roman Shpount > > On Thu, Feb 16, 2017 at 11:55 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> My suggestion is to keep the TCP/DTLS/SCTP definition. >> >> >> >> We earlier made a choice to restrict the scope of the document (by >> removing plain SCTP and DTLS-over-SCTP proto values), and I think we should >> keep the current scope. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> >> >> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Ben >> Campbell >> *Sent:* 16 February 2017 17:52 >> *To:* Eric Rescorla >> *Cc:* mmusic WG >> *Subject:* Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? >> >> >> >> Process background: draft-ietf-mmusic-sctp-sdp was on today's IESG >> telechat. The draft is approved for publication, but with a point raised to >> ask the WG resolve Ekr's question. >> >> Thanks! >> >> Ben. >> >> On 16 Feb 2017, at 9:43, Eric Rescorla wrote: >> >> I raised this with the authors, but maybe it is worth asking the mailing >> list. >> >> >> >> It seems like we are trending towards a world where we just ignore the >> transport >> >> component of the proto field and let ICE work things out. In that vein, I >> wonder >> >> do we really need to register/define TCP/DTLS/SCTP. It's only really >> useful if >> >> we think people will do SCTP over DTLS with TCP without ICE. Is that >> actually >> >> likely. I note that per previous discussions, JSEP already requires that >> you use >> >> UDP/DTLS/SCTP all the time: http://rtcweb-wg.github. >> io/jsep/#rfc.section.5.1.2 >> >> >> >> -Ekr >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > --001a113e7faee40f920548a944f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I al= so think the re-INVITE is unnecessary.

=
-Ekr

<= /div>
On Thu, Feb 16, 2017 at 9:16 AM, Roman Shpo= unt <roman@telurix.com> wrote:
The way ICE is currently defined, ICE enabled end poi= nts are supposed to send a re-INVITE after nomination process is completed = with the selected candidate address in the m=3D line. So, if tcp candidate = is selected, re-INVITE must be sent with TCP/DTLS/SCTP in the m=3D line. Al= so, any offers/answers after the ICE nomination is complete, are supposed t= o send the currently selected candidate in the m=3D line, which will also b= e TCP/DTLS/SCTP in case tcp candidate is selected.

Based= on all of this, I would strongly suggest to keep TCP/DTLS/SCTP.
=
Regards,

_____________
Roman Shpount

On Thu, Feb 16, 2017 = at 11:55 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
=

Hi,

=C2=A0

My suggestion is to keep the TCP/DTLS= /SCTP definition.

=C2=A0

We earlier made a choice to restrict = the scope of the document (by removing plain SCTP and DTLS-over-SCTP proto = values), and I think we should keep the current scope.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: = mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: 16 February 2017 17:52
To: Eric Rescorla <ekr@rtfm.com>
Cc: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?

=C2=A0

Process backgro= und: draft-ietf-mmusic-sctp-sdp was on today's IESG telechat. The draft= is approved for publication, but with a point raised to ask the WG resolve= Ekr's question.

Thanks!<= u>

Ben. =

On 16 Feb 2017,= at 9:43, Eric Rescorla wrote:

I raised this with the authors, but maybe it is worth as= king the mailing list.

=C2=A0

It seems like we are trending towards a world where we j= ust ignore the transport

component of the proto field and let ICE work things out= . In that vein, I wonder

do we really need to register/define TCP/DTLS/SCTP. It&#= 39;s only really useful if

we think people will do SCTP over DTLS with TCP without = ICE. Is that actually

likely. I note that per previous discussions, JSEP alrea= dy requires that you use

UDP/DTLS/SCTP all the time:=C2=A0http://rtcweb-wg.= github.io/jsep/#rfc.section.5.1.2

=C2=A0

-Ekr

=C2=A0


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


--001a113e7faee40f920548a944f1-- From nobody Thu Feb 16 09:40:58 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C6412946A for ; Thu, 16 Feb 2017 09:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9YvsfNXM00wl for ; Thu, 16 Feb 2017 09:40:55 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF52129406 for ; Thu, 16 Feb 2017 09:40:54 -0800 (PST) X-AuditID: c1b4fb25-93e1698000001738-48-58a5e4248ccf Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 4F.88.05944.424E5A85; Thu, 16 Feb 2017 18:40:52 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 18:40:36 +0100 From: Christer Holmberg To: Eric Rescorla , Roman Shpount Thread-Topic: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? Thread-Index: AQHSiGuZ0ghkIgIFz0iRXtxKyN1pOqFrt7kAgAAhoiD///XmgIAABf+AgAARKfA= Date: Thu, 16 Feb 2017 17:40:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C00464B@ESESSMB209.ericsson.se> References: <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4C004589@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4C00464BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2K7k67Kk6URBiu/mFrM7zzNbrHi9Tl2 i6nLH7NYzLgwldmBxWPJkp9MHrN2PmHxmPy4jdnj1pSCAJYoLpuU1JzMstQifbsEroyeixdY C5btZKxoac5tYNywhbGLkZNDQsBEYuKORjBbSGAdo8TKfo8uRi4gezGjxPXGb6xdjBwcbAIW Et3/tEFqRAScJU60vWADsZkF7CUarjWyg9jCAk4Sb95fZYWpOXejiRGkVUTAT+LLT26QMIuA qsSG5a/BWnkFfCV2L+lig1h1nUli6dptzCAJToFAifVvroEVMQqISXw/tYYJYpe4xK0n85kg bhaQWLLnPDOELSrx8vE/VghbSaJxyRNWiPp8ic0966CWCUqcnPmEZQKjyCwko2YhKZuFpGwW 0NnMApoS63fpQ5QoSkzpfsgOYWtItM6Zy44svoCRfRWjaHFqcVJuupGxXmpRZnJxcX6eXl5q ySZGYOwd3PJbdQfj5TeOhxgFOBiVeHgL9i2NEGJNLCuuzD3EKMHBrCTCu/oqUIg3JbGyKrUo P76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQbG1tvv9JRrd31fufFaUF1E zqnAaQpuBzLKeSbahR5/G+xkyPq8PMz/7qnlXn9CBO7fVprBeG7e180GbsZvJnbl1Fi0HZRp 4Trw74CRILf8LqPss9LM6pcW6JWp/LzwIHPSq/IZH/P+nFq5Lo7Fa5rcHr/lH1b/CFKKXBc2 cSX3/vzHdY45hQ0RSizFGYmGWsxFxYkAQm8tdrkCAAA= Archived-At: Cc: Ben Campbell , mmusic WG Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:40:57 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4C00464BESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkl04oCZcyBub3Qgb25seSB0aGUgcmUtSU5WSVRFLCBpdOKAmXMgQU5ZIHN1YnNlcXVl bnQgb2ZmZXIgc2VudCBkdXJpbmcgdGhlIHNlc3Npb24uDQoNCkhvd2V2ZXIsICBJIHRoaW5rIHdl IGNoYW5nZWQgdGhhdCBwYXJ0LiBUaGUgZHJhZnQgbm93IHNheXMgdGhhdCB3aGVuIHNlbmRpbmcg YW4gb2ZmZXIgb3IgYW5zd2VyLCB0aGUgbS0gbGluZSBwcm90byB2YWx1ZSBtdXN0IHJlZmxlY3Qg dGhlIERFRkFVTFQgY2FuZGlkaWF0ZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTog RXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0NClNlbnQ6IDE2IEZlYnJ1YXJ5IDIw MTcgMTk6MzgNClRvOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT4NCkNjOiBDaHJp c3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgQmVuIENhbXBi ZWxsIDxiZW5Abm9zdHJ1bS5jb20+OyBtbXVzaWMgV0cgPG1tdXNpY0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbTU1VU0lDXSBEbyB3ZSByZWFsbHkgbmVlZCBUQ1AvRFRMUy9TQ1RQIHByb3RvIGZp ZWxkPw0KDQpJIGFsc28gdGhpbmsgdGhlIHJlLUlOVklURSBpcyB1bm5lY2Vzc2FyeS4NCg0KLUVr cg0KDQpPbiBUaHUsIEZlYiAxNiwgMjAxNyBhdCA5OjE2IEFNLCBSb21hbiBTaHBvdW50IDxyb21h bkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90ZToNClRoZSB3YXkg SUNFIGlzIGN1cnJlbnRseSBkZWZpbmVkLCBJQ0UgZW5hYmxlZCBlbmQgcG9pbnRzIGFyZSBzdXBw b3NlZCB0byBzZW5kIGEgcmUtSU5WSVRFIGFmdGVyIG5vbWluYXRpb24gcHJvY2VzcyBpcyBjb21w bGV0ZWQgd2l0aCB0aGUgc2VsZWN0ZWQgY2FuZGlkYXRlIGFkZHJlc3MgaW4gdGhlIG09IGxpbmUu IFNvLCBpZiB0Y3AgY2FuZGlkYXRlIGlzIHNlbGVjdGVkLCByZS1JTlZJVEUgbXVzdCBiZSBzZW50 IHdpdGggVENQL0RUTFMvU0NUUCBpbiB0aGUgbT0gbGluZS4gQWxzbywgYW55IG9mZmVycy9hbnN3 ZXJzIGFmdGVyIHRoZSBJQ0Ugbm9taW5hdGlvbiBpcyBjb21wbGV0ZSwgYXJlIHN1cHBvc2VkIHRv IHNlbmQgdGhlIGN1cnJlbnRseSBzZWxlY3RlZCBjYW5kaWRhdGUgaW4gdGhlIG09IGxpbmUsIHdo aWNoIHdpbGwgYWxzbyBiZSBUQ1AvRFRMUy9TQ1RQIGluIGNhc2UgdGNwIGNhbmRpZGF0ZSBpcyBz ZWxlY3RlZC4NCg0KQmFzZWQgb24gYWxsIG9mIHRoaXMsIEkgd291bGQgc3Ryb25nbHkgc3VnZ2Vz dCB0byBrZWVwIFRDUC9EVExTL1NDVFAuDQoNClJlZ2FyZHMsDQoNCl9fX19fX19fX19fX18NClJv bWFuIFNocG91bnQNCg0KT24gVGh1LCBGZWIgMTYsIDIwMTcgYXQgMTE6NTUgQU0sIENocmlzdGVy IEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNCk15IHN1Z2dlc3Rpb24gaXMg dG8ga2VlcCB0aGUgVENQL0RUTFMvU0NUUCBkZWZpbml0aW9uLg0KDQpXZSBlYXJsaWVyIG1hZGUg YSBjaG9pY2UgdG8gcmVzdHJpY3QgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudCAoYnkgcmVtb3Zp bmcgcGxhaW4gU0NUUCBhbmQgRFRMUy1vdmVyLVNDVFAgcHJvdG8gdmFsdWVzKSwgYW5kIEkgdGhp bmsgd2Ugc2hvdWxkIGtlZXAgdGhlIGN1cnJlbnQgc2NvcGUuDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNCg0KRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEJlbiBDYW1wYmVsbA0K U2VudDogMTYgRmVicnVhcnkgMjAxNyAxNzo1Mg0KVG86IEVyaWMgUmVzY29ybGEgPGVrckBydGZt LmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4NCkNjOiBtbXVzaWMgV0cgPG1tdXNpY0BpZXRmLm9y ZzxtYWlsdG86bW11c2ljQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBEbyB3ZSBy ZWFsbHkgbmVlZCBUQ1AvRFRMUy9TQ1RQIHByb3RvIGZpZWxkPw0KDQoNClByb2Nlc3MgYmFja2dy b3VuZDogZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHAgd2FzIG9uIHRvZGF5J3MgSUVTRyB0ZWxl Y2hhdC4gVGhlIGRyYWZ0IGlzIGFwcHJvdmVkIGZvciBwdWJsaWNhdGlvbiwgYnV0IHdpdGggYSBw b2ludCByYWlzZWQgdG8gYXNrIHRoZSBXRyByZXNvbHZlIEVrcidzIHF1ZXN0aW9uLg0KDQpUaGFu a3MhDQoNCkJlbi4NCg0KT24gMTYgRmViIDIwMTcsIGF0IDk6NDMsIEVyaWMgUmVzY29ybGEgd3Jv dGU6DQpJIHJhaXNlZCB0aGlzIHdpdGggdGhlIGF1dGhvcnMsIGJ1dCBtYXliZSBpdCBpcyB3b3J0 aCBhc2tpbmcgdGhlIG1haWxpbmcgbGlzdC4NCg0KSXQgc2VlbXMgbGlrZSB3ZSBhcmUgdHJlbmRp bmcgdG93YXJkcyBhIHdvcmxkIHdoZXJlIHdlIGp1c3QgaWdub3JlIHRoZSB0cmFuc3BvcnQNCmNv bXBvbmVudCBvZiB0aGUgcHJvdG8gZmllbGQgYW5kIGxldCBJQ0Ugd29yayB0aGluZ3Mgb3V0LiBJ biB0aGF0IHZlaW4sIEkgd29uZGVyDQpkbyB3ZSByZWFsbHkgbmVlZCB0byByZWdpc3Rlci9kZWZp bmUgVENQL0RUTFMvU0NUUC4gSXQncyBvbmx5IHJlYWxseSB1c2VmdWwgaWYNCndlIHRoaW5rIHBl b3BsZSB3aWxsIGRvIFNDVFAgb3ZlciBEVExTIHdpdGggVENQIHdpdGhvdXQgSUNFLiBJcyB0aGF0 IGFjdHVhbGx5DQpsaWtlbHkuIEkgbm90ZSB0aGF0IHBlciBwcmV2aW91cyBkaXNjdXNzaW9ucywg SlNFUCBhbHJlYWR5IHJlcXVpcmVzIHRoYXQgeW91IHVzZQ0KVURQL0RUTFMvU0NUUCBhbGwgdGhl IHRpbWU6IGh0dHA6Ly9ydGN3ZWItd2cuZ2l0aHViLmlvL2pzZXAvI3JmYy5zZWN0aW9uLjUuMS4y DQoNCi1Fa3INCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0K DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B4C00464BESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SXTigJlzIG5vdCBvbmx5IHRo ZSByZS1JTlZJVEUsIGl04oCZcyBBTlkgc3Vic2VxdWVudCBvZmZlciBzZW50IGR1cmluZyB0aGUg c2Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhvd2V2ZXIs Jm5ic3A7IEkgdGhpbmsgd2UgY2hhbmdlZCB0aGF0IHBhcnQuIFRoZSBkcmFmdCBub3cgc2F5cyB0 aGF0IHdoZW4gc2VuZGluZyBhbiBvZmZlciBvciBhbnN3ZXIsIHRoZSBtLSBsaW5lIHByb3RvIHZh bHVlIG11c3QgcmVmbGVjdA0KIHRoZSBERUZBVUxUIGNhbmRpZGlhdGUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IDE2IEZlYnJ1YXJ5IDIwMTcgMTk6Mzg8YnI+DQo8Yj5Ubzo8L2I+IFJvbWFuIFNocG91bnQg Jmx0O3JvbWFuQHRlbHVyaXguY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQ2hyaXN0ZXIgSG9sbWJl cmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs7IEJlbiBDYW1wYmVsbCAm bHQ7YmVuQG5vc3RydW0uY29tJmd0OzsgbW11c2ljIFdHICZsdDttbXVzaWNAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBEbyB3ZSByZWFsbHkgbmVlZCBUQ1Av RFRMUy9TQ1RQIHByb3RvIGZpZWxkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBhbHNvIHRoaW5rIHRoZSByZS1JTlZJVEUgaXMgdW5uZWNlc3Nh cnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gVGh1LCBGZWIgMTYsIDIwMTcgYXQgOToxNiBBTSwgUm9tYW4gU2hwb3VudCAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFuayI+cm9tYW5AdGVs dXJpeC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHdheSBJQ0UgaXMgY3VycmVudGx5IGRlZmluZWQs IElDRSBlbmFibGVkIGVuZCBwb2ludHMgYXJlIHN1cHBvc2VkIHRvIHNlbmQgYSByZS1JTlZJVEUg YWZ0ZXIgbm9taW5hdGlvbiBwcm9jZXNzIGlzIGNvbXBsZXRlZCB3aXRoIHRoZSBzZWxlY3RlZCBj YW5kaWRhdGUgYWRkcmVzcyBpbiB0aGUgbT0gbGluZS4gU28sIGlmIHRjcCBjYW5kaWRhdGUgaXMg c2VsZWN0ZWQsIHJlLUlOVklURSBtdXN0IGJlIHNlbnQNCiB3aXRoIFRDUC9EVExTL1NDVFAgaW4g dGhlIG09IGxpbmUuIEFsc28sIGFueSBvZmZlcnMvYW5zd2VycyBhZnRlciB0aGUgSUNFIG5vbWlu YXRpb24gaXMgY29tcGxldGUsIGFyZSBzdXBwb3NlZCB0byBzZW5kIHRoZSBjdXJyZW50bHkgc2Vs ZWN0ZWQgY2FuZGlkYXRlIGluIHRoZSBtPSBsaW5lLCB3aGljaCB3aWxsIGFsc28gYmUgVENQL0RU TFMvU0NUUCBpbiBjYXNlIHRjcCBjYW5kaWRhdGUgaXMgc2VsZWN0ZWQuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CYXNlZCBvbiBhbGwgb2YgdGhpcywgSSB3 b3VsZCBzdHJvbmdseSBzdWdnZXN0IHRvIGtlZXAgVENQL0RUTFMvU0NUUC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy IGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEZl YiAxNiwgMjAxNyBhdCAxMTo1NSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1h aWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhp LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk15IHN1Z2dl c3Rpb24gaXMgdG8ga2VlcCB0aGUgVENQL0RUTFMvU0NUUCBkZWZpbml0aW9uLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldlIGVhcmxpZXIgbWFkZSBhIGNo b2ljZSB0byByZXN0cmljdCB0aGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50IChieSByZW1vdmluZyBw bGFpbiBTQ1RQIGFuZCBEVExTLW92ZXItU0NUUA0KIHByb3RvIHZhbHVlcyksIGFuZCBJIHRoaW5r IHdlIHNob3VsZCBrZWVwIHRoZSBjdXJyZW50IHNjb3BlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9 Im1fLTU4MjU3MDQyNDc5NTAwMTA4NTdfbV8tNTY1NDE0MjI5Nzg1NjMiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBtbXVzaWMNCiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptbXVzaWMt Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpYy1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmVuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+ IDE2IEZlYnJ1YXJ5IDIwMTcgMTc6NTI8YnI+DQo8Yj5Ubzo8L2I+IEVyaWMgUmVzY29ybGEgJmx0 OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5j b208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gbW11c2ljIFdHICZsdDs8YSBocmVmPSJtYWlsdG86 bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPiZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIERvIHdlIHJlYWxseSBuZWVkIFRDUC9E VExTL1NDVFAgcHJvdG8gZmllbGQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlByb2Nlc3MgYmFja2dyb3VuZDogZHJhZnQtaWV0Zi1tbXVz aWMtc2N0cC1zZHAgd2FzIG9uIHRvZGF5J3MgSUVTRyB0ZWxlY2hhdC4gVGhlIGRyYWZ0IGlzIGFw cHJvdmVkIGZvciBwdWJsaWNhdGlvbiwgYnV0IHdpdGggYSBwb2ludCByYWlzZWQgdG8gYXNrIHRo ZSBXRyByZXNvbHZlIEVrcidzIHF1ZXN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGFu a3MhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkJlbi4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi Pk9uIDE2IEZlYiAyMDE3LCBhdCA5OjQzLCBFcmljIFJlc2NvcmxhIHdyb3RlOjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICM3Nzc3NzcgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdDttYXJn aW4tbGVmdDowY207bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206My43NXB0Ij4NCjxkaXYgaWQ9Im1fLTU4MjU3MDQyNDc5NTAwMTA4NTdtXy01NjU0MTQyMjk3 ODU2MzY1OTk3QUNGNUI1RjgtQzczRi00QzcxLUE1OTgtRTYzOTE0OEJCQjYxIj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPkkgcmFpc2VkIHRoaXMgd2l0aCB0aGUg YXV0aG9ycywgYnV0IG1heWJlIGl0IGlzIHdvcnRoIGFza2luZyB0aGUgbWFpbGluZyBsaXN0Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3 Nzc3NzciPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+SXQgc2VlbXMgbGlrZSB3ZSBhcmUgdHJlbmRp bmcgdG93YXJkcyBhIHdvcmxkIHdoZXJlIHdlIGp1c3QgaWdub3JlIHRoZSB0cmFuc3BvcnQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM3Nzc3NzciPmNvbXBvbmVudCBvZiB0aGUgcHJvdG8gZmllbGQgYW5kIGxldCBJQ0Ugd29y ayB0aGluZ3Mgb3V0LiBJbiB0aGF0IHZlaW4sIEkgd29uZGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5kbyB3 ZSByZWFsbHkgbmVlZCB0byByZWdpc3Rlci9kZWZpbmUgVENQL0RUTFMvU0NUUC4gSXQncyBvbmx5 IHJlYWxseSB1c2VmdWwgaWY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPndlIHRoaW5rIHBlb3BsZSB3aWxsIGRv IFNDVFAgb3ZlciBEVExTIHdpdGggVENQIHdpdGhvdXQgSUNFLiBJcyB0aGF0IGFjdHVhbGx5PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNzc3Nzc3Ij5saWtlbHkuIEkgbm90ZSB0aGF0IHBlciBwcmV2aW91cyBkaXNjdXNzaW9u cywgSlNFUCBhbHJlYWR5IHJlcXVpcmVzIHRoYXQgeW91IHVzZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+VURQ L0RUTFMvU0NUUCBhbGwgdGhlIHRpbWU6Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3J0Y3dlYi13Zy5n aXRodWIuaW8vanNlcC8jcmZjLnNlY3Rpb24uNS4xLjIiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v cnRjd2ViLXdnLmdpdGh1Yi5pby9qc2VwLyNyZmMuc2VjdGlvbi41LjEuMjwvYT48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3 Nzc3NzciPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPi1Fa3I8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3Nzci PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptbXVz aWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4C00464BESESSMB209erics_-- From nobody Thu Feb 16 09:47:24 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E651295BA for ; Thu, 16 Feb 2017 09:47:23 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 QMAZN0MgO0Wo for ; Thu, 16 Feb 2017 09:47:22 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB7F1294F1 for ; Thu, 16 Feb 2017 09:47:22 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v1GHlIY9010932 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 16 Feb 2017 11:47:19 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Christer Holmberg" Date: Thu, 16 Feb 2017 11:47:18 -0600 Message-ID: <7E4962C5-52BB-416C-8C28-879F8F4ACEA4@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4C004492@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4C004492@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5344) Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:47:24 -0000 On 16 Feb 2017, at 9:51, Christer Holmberg wrote: > Hi, > > Note that the mechanism is also used at least by CLUE, which does not > mandate ICE (or JSEP). ISTM that this argument trumps the ongoing ICE usage discussion. Am I missing something? Ben. From nobody Thu Feb 16 09:49:26 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5AB1295A6 for ; Thu, 16 Feb 2017 09:49:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeeNW3SH7N94 for ; Thu, 16 Feb 2017 09:49:23 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51DA1295BA for ; Thu, 16 Feb 2017 09:49:22 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id k15so20800043qtg.3 for ; Thu, 16 Feb 2017 09:49:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4A911m3+HRsHgR6QwlHE7JrFyrv5LgGCmQj1EWe+6oU=; b=n8SnaejRp5sRNR29pXN+gutFebye2yRyUzDL36dKUToXluymDOpjGwalSuBVTd2q23 Mv5gOBcgKfqJcGM86U3V2xwzIqKKtnRrG+qOcQajbvoB9JorT85ezXLIqzRaKHOEOuwG gPFfMOhK3PbMuPD/OQXir8gkz6uWAAeiuDb5QlJpXFC2bFFLCIA8cFPsdDcW3mUPbJ5S R8NPqPWXz2ZY4FxxOAwPXe8jIm6ZGWkaUOAb51WUUl1h4XjOtBOIkaj1ocJjotWcgInj RS9mLIirpZbfYJ1MgTzDDtoTaH9maZlmxurTwax6SRFeGmDkVd5o3ZlZZhtZErgrxIK6 k97Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4A911m3+HRsHgR6QwlHE7JrFyrv5LgGCmQj1EWe+6oU=; b=Lf+pUym+Et9vxqTbAxY6QxhnbCMBfDzZc+bGakzZRNH8z8A0NnTeJP/Oaa5lNoGY7X cIgxzjXdeJi0LqtQCAs4fr8E9S6TT7XRv1P62d0ZBhOEcCwW3AXklr77OF88yZyFBRR/ 8uHx8j59/Y5cdLBExEl97/Lgue3endH7dd9dqzL5X8kAeswMDwtHeDgc9h8P+D/kKSgW ES/usF9IPF2YNBNI+gjg3wzbyItO+vryFdpSZ3W8xF0S1jgbgsqvbyNoSjzdEMlwVT5d NY4JCw3n2rB+asqlHOTdVykelFukThCECgRiLnxHVJ8Aj8JsMlclUJP+gfvKwQIdBVP1 QZhw== X-Gm-Message-State: AMke39lVXiJRQA5v/AsEJbDo8/Xz1cVNTEi8+RGUx0jjOwBUKeSt3n3HRCAr+8f3fLKMLw== X-Received: by 10.237.39.5 with SMTP id n5mr3181410qtd.38.1487267361664; Thu, 16 Feb 2017 09:49:21 -0800 (PST) Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com. [209.85.220.179]) by smtp.gmail.com with ESMTPSA id k19sm4836415qtf.37.2017.02.16.09.49.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 09:49:21 -0800 (PST) Received: by mail-qk0-f179.google.com with SMTP id 11so22372318qkl.3 for ; Thu, 16 Feb 2017 09:49:21 -0800 (PST) X-Received: by 10.55.20.77 with SMTP id e74mr3330761qkh.71.1487267360905; Thu, 16 Feb 2017 09:49:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Thu, 16 Feb 2017 09:49:20 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4C00464B@ESESSMB209.ericsson.se> References: <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4C004589@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C00464B@ESESSMB209.ericsson.se> From: Roman Shpount Date: Thu, 16 Feb 2017 12:49:20 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11400008bbaa510548a96ac4 Archived-At: Cc: Ben Campbell , mmusic WG Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:49:25 -0000 --001a11400008bbaa510548a96ac4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Once nomination process is completed, it should be the selected, not the default candidate. When session is established or during ICE restart, multiple candidates are sent in offer/answer and DEFAULT candidate must be used in the m=3D line. Once nomination process is completed, only the currently selected candidate is sent in offer/answer and this would be the candidate in the m=3D line. Resources associated with other candidates, such as network ports or TURN allocations, are typically released at that point, so there is no point to include them any more. I am all for removing the re-INVITE requirement, but we need to do it cleanly in backwards compatible manner. In any case, this is a separate discussion and current RFC 5245 requires it. Regards, _____________ Roman Shpount On Thu, Feb 16, 2017 at 12:40 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > It=E2=80=99s not only the re-INVITE, it=E2=80=99s ANY subsequent offer se= nt during the > session. > > > > However, I think we changed that part. The draft now says that when > sending an offer or answer, the m- line proto value must reflect the > DEFAULT candidiate. > > > > Regards, > > > > Christer > > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* 16 February 2017 19:38 > *To:* Roman Shpount > *Cc:* Christer Holmberg ; Ben Campbell < > ben@nostrum.com>; mmusic WG > > *Subject:* Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? > > > > I also think the re-INVITE is unnecessary. > > > > -Ekr > > > > On Thu, Feb 16, 2017 at 9:16 AM, Roman Shpount wrote: > > The way ICE is currently defined, ICE enabled end points are supposed to > send a re-INVITE after nomination process is completed with the selected > candidate address in the m=3D line. So, if tcp candidate is selected, > re-INVITE must be sent with TCP/DTLS/SCTP in the m=3D line. Also, any > offers/answers after the ICE nomination is complete, are supposed to send > the currently selected candidate in the m=3D line, which will also be > TCP/DTLS/SCTP in case tcp candidate is selected. > > > > Based on all of this, I would strongly suggest to keep TCP/DTLS/SCTP. > > > > Regards, > > > _____________ > Roman Shpount > > > > On Thu, Feb 16, 2017 at 11:55 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > My suggestion is to keep the TCP/DTLS/SCTP definition. > > > > We earlier made a choice to restrict the scope of the document (by > removing plain SCTP and DTLS-over-SCTP proto values), and I think we shou= ld > keep the current scope. > > > > Regards, > > > > Christer > > > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Ben > Campbell > *Sent:* 16 February 2017 17:52 > *To:* Eric Rescorla > *Cc:* mmusic WG > *Subject:* Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? > > > > Process background: draft-ietf-mmusic-sctp-sdp was on today's IESG > telechat. The draft is approved for publication, but with a point raised = to > ask the WG resolve Ekr's question. > > Thanks! > > Ben. > > On 16 Feb 2017, at 9:43, Eric Rescorla wrote: > > I raised this with the authors, but maybe it is worth asking the mailing > list. > > > > It seems like we are trending towards a world where we just ignore the > transport > > component of the proto field and let ICE work things out. In that vein, I > wonder > > do we really need to register/define TCP/DTLS/SCTP. It's only really > useful if > > we think people will do SCTP over DTLS with TCP without ICE. Is that > actually > > likely. I note that per previous discussions, JSEP already requires that > you use > > UDP/DTLS/SCTP all the time: http://rtcweb-wg.github. > io/jsep/#rfc.section.5.1.2 > > > > -Ekr > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > --001a11400008bbaa510548a96ac4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Once nomination process is completed, it should be the sel= ected, not the default candidate.

When session is establ= ished or during ICE restart, multiple candidates are sent in offer/answer a= nd DEFAULT candidate must be used in the m=3D line.

= Once nomination process is completed, only the currently selected candidate= is sent in offer/answer and this would be the candidate in the m=3D line. = Resources associated with other candidates, such as network ports or TURN a= llocations, are typically released at that point, so there is no point to i= nclude them any more.

I am all for removing = the re-INVITE requirement, but we need to do it cleanly in backwards compat= ible manner. In any case, this is a separate discussion and current RFC 524= 5 requires it.

Regards,

_____________
Roman Shpount

On Thu, Feb 16, 2017 at 12:40 PM, Christer H= olmberg <christer.holmberg@ericsson.com> wrote:=

Hi,

=C2=A0

It=E2=80=99s not only the re-INVITE, = it=E2=80=99s ANY subsequent offer sent during the session.

=C2=A0

However,=C2=A0 I think we changed tha= t part. The draft now says that when sending an offer or answer, the m- lin= e proto value must reflect the DEFAULT candidiate.

=C2=A0

Regards,

=C2=A0

Christer

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">=C2=A0

From: = Eric Rescorla [mailto:ekr= @rtfm.com]
Sent: 16 February 2017 19:38
To: Roman Shpount <roman@telurix.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>; Ben = Campbell <ben@nostr= um.com>; mmusic WG <mmusic@ietf.org>


Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?

=C2=A0

I also think the re-INVITE is unnecessary.=

=C2=A0

-Ekr

=C2=A0

On Thu, Feb 16, 2017 at 9:16 AM, Roman Shpount <<= a href=3D"mailto:roman@telurix.com" target=3D"_blank">roman@telurix.com= > wrote:

The way ICE is currently defined, ICE enabled end po= ints are supposed to send a re-INVITE after nomination process is completed= with the selected candidate address in the m=3D line. So, if tcp candidate= is selected, re-INVITE must be sent with TCP/DTLS/SCTP in the m=3D line. Also, any offers/answers after the IC= E nomination is complete, are supposed to send the currently selected candi= date in the m=3D line, which will also be TCP/DTLS/SCTP in case tcp candida= te is selected.

=C2=A0

Based on all of this, I would strongly suggest to ke= ep TCP/DTLS/SCTP.

=C2=A0

Regards,


_____________
Roman Shpount

=C2=A0

On Thu, Feb 16, 2017 at 11:55 AM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

My suggestion is to keep the TCP/DTLS= /SCTP definition.

=C2=A0

We earlier made a choice to restrict = the scope of the document (by removing plain SCTP and DTLS-over-SCTP proto values), and I think we should keep the current scope.=

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: = mmusic [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: 16 February 2017 17:52
To: Eric Rescorla <ekr@rtfm.com>
Cc: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?

=C2=A0

Process backgro= und: draft-ietf-mmusic-sctp-sdp was on today's IESG telechat. The draft= is approved for publication, but with a point raised to ask the WG resolve= Ekr's question.

Thanks!<= u>

Ben. =

On 16 Feb 2017,= at 9:43, Eric Rescorla wrote:

I raised this with the authors, but maybe it is worth as= king the mailing list.

=C2=A0

It seems like we are trending towards a world where we j= ust ignore the transport

component of the proto field and let ICE work things out= . In that vein, I wonder

do we really need to register/define TCP/DTLS/SCTP. It&#= 39;s only really useful if

we think people will do SCTP over DTLS with TCP without = ICE. Is that actually

likely. I note that per previous discussions, JSEP alrea= dy requires that you use

UDP/DTLS/SCTP all the time:=C2=A0http://rtcweb-wg.= github.io/jsep/#rfc.section.5.1.2

=C2=A0

-Ekr

=C2=A0

=C2=A0

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

=C2=A0

=C2=A0


--001a11400008bbaa510548a96ac4-- From nobody Thu Feb 16 09:55:03 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F401D129483 for ; Thu, 16 Feb 2017 09:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6-YyCbr3YywD for ; Thu, 16 Feb 2017 09:54:59 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EFA129406 for ; Thu, 16 Feb 2017 09:54:59 -0800 (PST) X-AuditID: c1b4fb30-2868b98000002c77-89-58a5e771f456 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by (Symantec Mail Security) with SMTP id 02.8B.11383.177E5A85; Thu, 16 Feb 2017 18:54:57 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 18:54:04 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? Thread-Index: AQHSiGuZ0ghkIgIFz0iRXtxKyN1pOqFrt7kAgAAhoiD///XmgIAABf+AgAARKfD///H8AIAAEY/Q Date: Thu, 16 Feb 2017 17:54:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C0046CD@ESESSMB209.ericsson.se> References: <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4C004589@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C00464B@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4C0046CDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM+JvjW7h86URBu0TdCzmd55mt1jx+hy7 xdTlj1ksZlyYyuzA4rFkyU8mj1k7n7B4TH7cxuxxa0pBAEsUl01Kak5mWWqRvl0CV8aVK+fZ Cr79ZqzYtXQHUwPjiq+MXYycHBICJhJvzj1l72Lk4hASWM8o8WnWchaQhJDAYkaJk9/Suxg5 ONgELCS6/2mDhEUEVCX+fp/MBGIzC8RLXJl2hQ3EFhZwknjz/iorRI2zxLkbTYwgrSICURKT +qxAwixArTO+HAGbzivgK/Fm5WJGiE2PmCX+v00HsTkFAiVO3v8LNp5RQEzi+6k1UKvEJW49 mc8EcbKAxJI955khbFGJl4//sULYShKNS56wQtTnS9yesYQNYpegxMmZT1gmMIrMQjJqFpKy WUjKZgFdzSygKbF+lz5EiaLElO6H7BC2hkTrnLnsyOILGNlXMYoWpxYn5aYbGemlFmUmFxfn 5+nlpZZsYgTG3sEtvw12ML587niIUYCDUYmHt2Df0ggh1sSy4srcQ4wSHMxKIryrrwKFeFMS K6tSi/Lji0pzUosPMUpzsCiJ85qtvB8uJJCeWJKanZpakFoEk2Xi4JRqYFRlmv7q+cuHhx/f 6XdsTXtwcVlrs9ndYu1u1VDLvpvcLOan9hSc3f400j/owbk37FGtdrObMlcsYV024+H9Q1fb Ba3Zu2/vX3dGm/fqwh2PZt7ikH9+/LqM57fKW1umzpsttP31pK1hCYW/RQ4Z/zSev9nodvGM oooyrfIiqcNXHjat/O5591+nEktxRqKhFnNRcSIAw4Brg7kCAAA= Archived-At: Cc: Ben Campbell , mmusic WG Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:55:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4C0046CDESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5PbmNlIG5vbWluYXRpb24gcHJvY2VzcyBpcyBjb21wbGV0ZWQsIGl0IHNob3VsZCBi ZSB0aGUgc2VsZWN0ZWQsIG5vdCB0aGUgZGVmYXVsdCA+Y2FuZGlkYXRlLg0KPg0KPldoZW4gc2Vz c2lvbiBpcyBlc3RhYmxpc2hlZCBvciBkdXJpbmcgSUNFIHJlc3RhcnQsIG11bHRpcGxlIGNhbmRp ZGF0ZXMgYXJlIHNlbnQgPmluIG9mZmVyL2Fuc3dlciBhbmQgREVGQVVMVCBjYW5kaWRhdGUgbXVz dCBiZSB1c2VkIGluIHRoZSBtPSBsaW5lLg0KPg0KPk9uY2Ugbm9taW5hdGlvbiBwcm9jZXNzIGlz IGNvbXBsZXRlZCwgb25seSB0aGUgY3VycmVudGx5IHNlbGVjdGVkIGNhbmRpZGF0ZSBpcyA+c2Vu dCBpbiBvZmZlci9hbnN3ZXIgYW5kIHRoaXMgd291bGQgYmUgdGhlIGNhbmRpZGF0ZSBpbiB0aGUg bT0gbGluZS4gUmVzb3VyY2VzID5hc3NvY2lhdGVkIHdpdGggb3RoZXIgY2FuZGlkYXRlcywgc3Vj aCBhcyBuZXR3b3JrIHBvcnRzIG9yIFRVUk4gYWxsb2NhdGlvbnMsID5hcmUgdHlwaWNhbGx5IHJl bGVhc2VkIGF0IHRoYXQgcG9pbnQsIHNvIHRoZXJlIGlzIG5vIHBvaW50IHRvIGluY2x1ZGUgdGhl bSBhbnkgPm1vcmUuDQoNCldlbGwsIHRoZW4gd2UgbmVlZCB0byBjbGFyaWZ5IHRoZSB0ZXh0IChv ciByZW1vdmUgdGhlIHRleHQgY29tcGxldGVseSwgYW5kIHNpbXBseSByZWZlciB0byB0aGUgSUNF IHNwZWMpLCBiZWNhdXNlIHRoZSBJQ0UgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0YWxrcyBhYm91 dCBvZmZlcnMgYW5kIGFuc3dlcnMgaW4gZ2VuZXJhbC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0KDQoNCk9uIFRodSwgRmViIDE2LCAyMDE3IGF0IDEyOjQwIFBNLCBDaHJpc3RlciBIb2xtYmVy ZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQpJdOKAmXMgbm90IG9ubHkgdGhlIHJlLUlO VklURSwgaXTigJlzIEFOWSBzdWJzZXF1ZW50IG9mZmVyIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9u Lg0KDQpIb3dldmVyLCAgSSB0aGluayB3ZSBjaGFuZ2VkIHRoYXQgcGFydC4gVGhlIGRyYWZ0IG5v dyBzYXlzIHRoYXQgd2hlbiBzZW5kaW5nIGFuIG9mZmVyIG9yIGFuc3dlciwgdGhlIG0tIGxpbmUg cHJvdG8gdmFsdWUgbXVzdCByZWZsZWN0IHRoZSBERUZBVUxUIGNhbmRpZGlhdGUuDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5j b208bWFpbHRvOmVrckBydGZtLmNvbT5dDQpTZW50OiAxNiBGZWJydWFyeSAyMDE3IDE5OjM4DQpU bzogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXgu Y29tPj4NCkNjOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PjsgQmVuIENhbXBiZWxs IDxiZW5Abm9zdHJ1bS5jb208bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4+OyBtbXVzaWMgV0cgPG1t dXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPj4NCg0KU3ViamVjdDogUmU6IFtN TVVTSUNdIERvIHdlIHJlYWxseSBuZWVkIFRDUC9EVExTL1NDVFAgcHJvdG8gZmllbGQ/DQoNCkkg YWxzbyB0aGluayB0aGUgcmUtSU5WSVRFIGlzIHVubmVjZXNzYXJ5Lg0KDQotRWtyDQoNCk9uIFRo dSwgRmViIDE2LCAyMDE3IGF0IDk6MTYgQU0sIFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXgu Y29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdyb3RlOg0KVGhlIHdheSBJQ0UgaXMgY3Vy cmVudGx5IGRlZmluZWQsIElDRSBlbmFibGVkIGVuZCBwb2ludHMgYXJlIHN1cHBvc2VkIHRvIHNl bmQgYSByZS1JTlZJVEUgYWZ0ZXIgbm9taW5hdGlvbiBwcm9jZXNzIGlzIGNvbXBsZXRlZCB3aXRo IHRoZSBzZWxlY3RlZCBjYW5kaWRhdGUgYWRkcmVzcyBpbiB0aGUgbT0gbGluZS4gU28sIGlmIHRj cCBjYW5kaWRhdGUgaXMgc2VsZWN0ZWQsIHJlLUlOVklURSBtdXN0IGJlIHNlbnQgd2l0aCBUQ1Av RFRMUy9TQ1RQIGluIHRoZSBtPSBsaW5lLiBBbHNvLCBhbnkgb2ZmZXJzL2Fuc3dlcnMgYWZ0ZXIg dGhlIElDRSBub21pbmF0aW9uIGlzIGNvbXBsZXRlLCBhcmUgc3VwcG9zZWQgdG8gc2VuZCB0aGUg Y3VycmVudGx5IHNlbGVjdGVkIGNhbmRpZGF0ZSBpbiB0aGUgbT0gbGluZSwgd2hpY2ggd2lsbCBh bHNvIGJlIFRDUC9EVExTL1NDVFAgaW4gY2FzZSB0Y3AgY2FuZGlkYXRlIGlzIHNlbGVjdGVkLg0K DQpCYXNlZCBvbiBhbGwgb2YgdGhpcywgSSB3b3VsZCBzdHJvbmdseSBzdWdnZXN0IHRvIGtlZXAg VENQL0RUTFMvU0NUUC4NCg0KUmVnYXJkcywNCg0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3Vu dA0KDQpPbiBUaHUsIEZlYiAxNiwgMjAxNyBhdCAxMTo1NSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcg PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KTXkgc3VnZ2VzdGlvbiBpcyB0byBrZWVwIHRo ZSBUQ1AvRFRMUy9TQ1RQIGRlZmluaXRpb24uDQoNCldlIGVhcmxpZXIgbWFkZSBhIGNob2ljZSB0 byByZXN0cmljdCB0aGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50IChieSByZW1vdmluZyBwbGFpbiBT Q1RQIGFuZCBEVExTLW92ZXItU0NUUCBwcm90byB2YWx1ZXMpLCBhbmQgSSB0aGluayB3ZSBzaG91 bGQga2VlcCB0aGUgY3VycmVudCBzY29wZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpG cm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bW11c2lj LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQmVuIENhbXBiZWxsDQpTZW50OiAxNiBG ZWJydWFyeSAyMDE3IDE3OjUyDQpUbzogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0 bzpla3JAcnRmbS5jb20+Pg0KQ2M6IG1tdXNpYyBXRyA8bW11c2ljQGlldGYub3JnPG1haWx0bzpt bXVzaWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIERvIHdlIHJlYWxseSBuZWVk IFRDUC9EVExTL1NDVFAgcHJvdG8gZmllbGQ/DQoNCg0KUHJvY2VzcyBiYWNrZ3JvdW5kOiBkcmFm dC1pZXRmLW1tdXNpYy1zY3RwLXNkcCB3YXMgb24gdG9kYXkncyBJRVNHIHRlbGVjaGF0LiBUaGUg ZHJhZnQgaXMgYXBwcm92ZWQgZm9yIHB1YmxpY2F0aW9uLCBidXQgd2l0aCBhIHBvaW50IHJhaXNl ZCB0byBhc2sgdGhlIFdHIHJlc29sdmUgRWtyJ3MgcXVlc3Rpb24uDQoNClRoYW5rcyENCg0KQmVu Lg0KDQpPbiAxNiBGZWIgMjAxNywgYXQgOTo0MywgRXJpYyBSZXNjb3JsYSB3cm90ZToNCkkgcmFp c2VkIHRoaXMgd2l0aCB0aGUgYXV0aG9ycywgYnV0IG1heWJlIGl0IGlzIHdvcnRoIGFza2luZyB0 aGUgbWFpbGluZyBsaXN0Lg0KDQpJdCBzZWVtcyBsaWtlIHdlIGFyZSB0cmVuZGluZyB0b3dhcmRz IGEgd29ybGQgd2hlcmUgd2UganVzdCBpZ25vcmUgdGhlIHRyYW5zcG9ydA0KY29tcG9uZW50IG9m IHRoZSBwcm90byBmaWVsZCBhbmQgbGV0IElDRSB3b3JrIHRoaW5ncyBvdXQuIEluIHRoYXQgdmVp biwgSSB3b25kZXINCmRvIHdlIHJlYWxseSBuZWVkIHRvIHJlZ2lzdGVyL2RlZmluZSBUQ1AvRFRM Uy9TQ1RQLiBJdCdzIG9ubHkgcmVhbGx5IHVzZWZ1bCBpZg0Kd2UgdGhpbmsgcGVvcGxlIHdpbGwg ZG8gU0NUUCBvdmVyIERUTFMgd2l0aCBUQ1Agd2l0aG91dCBJQ0UuIElzIHRoYXQgYWN0dWFsbHkN Cmxpa2VseS4gSSBub3RlIHRoYXQgcGVyIHByZXZpb3VzIGRpc2N1c3Npb25zLCBKU0VQIGFscmVh ZHkgcmVxdWlyZXMgdGhhdCB5b3UgdXNlDQpVRFAvRFRMUy9TQ1RQIGFsbCB0aGUgdGltZTogaHR0 cDovL3J0Y3dlYi13Zy5naXRodWIuaW8vanNlcC8jcmZjLnNlY3Rpb24uNS4xLjINCg0KLUVrcg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptbXVz aWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B4C0046CDESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mZ3Q7PC9zcGFuPk9uY2Ugbm9taW5hdGlvbiBwcm9jZXNzIGlzIGNvbXBsZXRlZCwg aXQgc2hvdWxkIGJlIHRoZSBzZWxlY3RlZCwgbm90IHRoZSBkZWZhdWx0DQo8c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5jYW5kaWRhdGUuPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8 L3NwYW4+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5XaGVuIHNlc3Np b24gaXMgZXN0YWJsaXNoZWQgb3IgZHVyaW5nIElDRSByZXN0YXJ0LCBtdWx0aXBsZSBjYW5kaWRh dGVzIGFyZSBzZW50DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5pbiBv ZmZlci9hbnN3ZXIgYW5kIERFRkFVTFQgY2FuZGlkYXRlIG11c3QgYmUgdXNlZCBpbiB0aGUgbT0g bGluZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mZ3Q7PC9zcGFuPk9uY2Ugbm9taW5hdGlvbiBwcm9jZXNzIGlzIGNvbXBsZXRlZCwgb25s eSB0aGUgY3VycmVudGx5IHNlbGVjdGVkIGNhbmRpZGF0ZSBpcw0KPHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZndDs8L3NwYW4+c2VudCBpbiBvZmZlci9hbnN3ZXIgYW5kIHRoaXMgd291bGQg YmUgdGhlIGNhbmRpZGF0ZSBpbiB0aGUgbT0gbGluZS4gUmVzb3VyY2VzDQo8c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5hc3NvY2lhdGVkIHdpdGggb3RoZXIgY2FuZGlkYXRl cywgc3VjaCBhcyBuZXR3b3JrIHBvcnRzIG9yIFRVUk4gYWxsb2NhdGlvbnMsDQo8c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5hcmUgdHlwaWNhbGx5IHJlbGVhc2VkIGF0IHRo YXQgcG9pbnQsIHNvIHRoZXJlIGlzIG5vIHBvaW50IHRvIGluY2x1ZGUgdGhlbSBhbnkNCjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPm1vcmUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2VsbCwgdGhlbiB3ZSBuZWVk IHRvIGNsYXJpZnkgdGhlIHRleHQgKG9yIHJlbW92ZSB0aGUgdGV4dCBjb21wbGV0ZWx5LCBhbmQg c2ltcGx5IHJlZmVyIHRvIHRoZSBJQ0Ugc3BlYyksIGJlY2F1c2UgdGhlIElDRSBjb25zaWRlcmF0 aW9ucyBzZWN0aW9uIHRhbGtzIGFib3V0IG9mZmVycw0KIGFuZCBhbnN3ZXJzIGluIGdlbmVyYWwu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEZlYiAxNiwgMjAxNyBhdCAxMjo0MCBQTSwgQ2hy aXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhp LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkl04oCZcyBu b3Qgb25seSB0aGUgcmUtSU5WSVRFLCBpdOKAmXMgQU5ZIHN1YnNlcXVlbnQgb2ZmZXIgc2VudCBk dXJpbmcgdGhlIHNlc3Npb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SG93ZXZlciwmbmJzcDsgSSB0aGluayB3ZSBjaGFuZ2VkIHRoYXQgcGFydC4gVGhl IGRyYWZ0IG5vdyBzYXlzIHRoYXQgd2hlbiBzZW5kaW5nIGFuIG9mZmVyIG9yIGFuc3dlciwgdGhl DQogbS0gbGluZSBwcm90byB2YWx1ZSBtdXN0IHJlZmxlY3QgdGhlIERFRkFVTFQgY2FuZGlkaWF0 ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRz LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVy PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSJt Xy02ODg0NDI4OTI4NTQ5MTQzODk2X19NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gRXJpYw0KIFJlc2NvcmxhIFttYWls dG86PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZt LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTYgRmVicnVhcnkgMjAxNyAxOTozODxicj4N CjxiPlRvOjwvYj4gUm9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVy aXguY29tIiB0YXJnZXQ9Il9ibGFuayI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0Ozxicj4NCjxi PkNjOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb208L2E+Jmd0OzsgQmVuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmVu QG5vc3RydW0uY29tIiB0YXJnZXQ9Il9ibGFuayI+YmVuQG5vc3RydW0uY29tPC9hPiZndDs7IG1t dXNpYyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm1tdXNpY0BpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtN TVVTSUNdIERvIHdlIHJlYWxseSBuZWVkIFRDUC9EVExTL1NDVFAgcHJvdG8gZmllbGQ/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5JIGFsc28gdGhpbmsgdGhlIHJlLUlOVklURSBpcyB1bm5lY2Vzc2Fy eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk9uIFRodSwgRmViIDE2LCAyMDE3IGF0IDk6MTYgQU0sIFJvbWFuIFNocG91bnQg Jmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJv bWFuQHRlbHVyaXguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRoZSB3YXkgSUNFIGlzIGN1cnJlbnRseSBkZWZpbmVkLCBJQ0UgZW5hYmxl ZCBlbmQgcG9pbnRzIGFyZSBzdXBwb3NlZCB0byBzZW5kIGEgcmUtSU5WSVRFIGFmdGVyIG5vbWlu YXRpb24gcHJvY2VzcyBpcyBjb21wbGV0ZWQgd2l0aCB0aGUgc2VsZWN0ZWQgY2FuZGlkYXRlIGFk ZHJlc3MgaW4gdGhlIG09IGxpbmUuDQogU28sIGlmIHRjcCBjYW5kaWRhdGUgaXMgc2VsZWN0ZWQs IHJlLUlOVklURSBtdXN0IGJlIHNlbnQgd2l0aCBUQ1AvRFRMUy9TQ1RQIGluIHRoZSBtPSBsaW5l LiBBbHNvLCBhbnkgb2ZmZXJzL2Fuc3dlcnMgYWZ0ZXIgdGhlIElDRSBub21pbmF0aW9uIGlzIGNv bXBsZXRlLCBhcmUgc3VwcG9zZWQgdG8gc2VuZCB0aGUgY3VycmVudGx5IHNlbGVjdGVkIGNhbmRp ZGF0ZSBpbiB0aGUgbT0gbGluZSwgd2hpY2ggd2lsbCBhbHNvIGJlIFRDUC9EVExTL1NDVFANCiBp biBjYXNlIHRjcCBjYW5kaWRhdGUgaXMgc2VsZWN0ZWQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmFzZWQgb24gYWxsIG9mIHRoaXMsIEkgd291bGQg c3Ryb25nbHkgc3VnZ2VzdCB0byBrZWVwIFRDUC9EVExTL1NDVFAuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi ciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g VGh1LCBGZWIgMTYsIDIwMTcgYXQgMTE6NTUgQU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBo cmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFu ayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGksPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TXkgc3VnZ2VzdGlvbiBpcyB0byBr ZWVwIHRoZSBUQ1AvRFRMUy9TQ1RQIGRlZmluaXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2UgZWFybGllciBtYWRlIGEgY2hvaWNlIHRvIHJlc3Ry aWN0IHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQgKGJ5IHJlbW92aW5nIHBsYWluIFNDVFAgYW5k IERUTFMtb3Zlci1TQ1RQDQogcHJvdG8gdmFsdWVzKSwgYW5kIEkgdGhpbmsgd2Ugc2hvdWxkIGtl ZXAgdGhlIGN1cnJlbnQgc2NvcGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ibV8tNjg4NDQyODky ODU0OTE0Mzg5Nl9tXy01ODI1NzA0MjQ3OTUwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+IG1tdXNpYw0KIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5CZW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50OjwvYj4gMTYgRmVicnVhcnkg MjAxNyAxNzo1Mjxicj4NCjxiPlRvOjwvYj4gRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBtbXVzaWMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW01NVVNJQ10gRG8gd2UgcmVhbGx5IG5lZWQgVENQL0RUTFMvU0NUUCBwcm90 byBmaWVsZD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+UHJvY2VzcyBiYWNrZ3JvdW5kOiBkcmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNkcCB3 YXMgb24gdG9kYXkncyBJRVNHIHRlbGVjaGF0LiBUaGUgZHJhZnQgaXMgYXBwcm92ZWQgZm9yIHB1 YmxpY2F0aW9uLCBidXQgd2l0aCBhIHBvaW50IHJhaXNlZCB0byBhc2sgdGhlIFdHIHJlc29sdmUg RWtyJ3MgcXVlc3Rpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyE8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+QmVuLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+T24gMTYgRmViIDIw MTcsIGF0IDk6NDMsIEVyaWMgUmVzY29ybGEgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Izc3Nzc3NyAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21hcmdpbi1sZWZ0OjBjbTtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTozLjc1cHQiPg0K PGRpdiBpZD0ibV8tNjg4NDQyODkyODU0OTE0Mzg5Nm1fLTU4MjU3MDQyNDc5NTAwMTA4NTdtXy01 NjU0MTQyMjk3ODU2MzY1OTk3QUNGNUI1RjgtQzczRi00QzcxLUE1OTgtRTYzOTE0OEJCQjYxIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPkkgcmFpc2VkIHRoaXMg d2l0aCB0aGUgYXV0aG9ycywgYnV0IG1heWJlIGl0IGlzIHdvcnRoIGFza2luZyB0aGUgbWFpbGlu ZyBsaXN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM3Nzc3NzciPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+SXQgc2VlbXMgbGlrZSB3ZSBh cmUgdHJlbmRpbmcgdG93YXJkcyBhIHdvcmxkIHdoZXJlIHdlIGp1c3QgaWdub3JlIHRoZSB0cmFu c3BvcnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM3Nzc3NzciPmNvbXBvbmVudCBvZiB0aGUgcHJvdG8gZmllbGQgYW5kIGxl dCBJQ0Ugd29yayB0aGluZ3Mgb3V0LiBJbiB0aGF0IHZlaW4sIEkgd29uZGVyPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3 Nzc3Ij5kbyB3ZSByZWFsbHkgbmVlZCB0byByZWdpc3Rlci9kZWZpbmUgVENQL0RUTFMvU0NUUC4g SXQncyBvbmx5IHJlYWxseSB1c2VmdWwgaWY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPndlIHRoaW5rIHBlb3Bs ZSB3aWxsIGRvIFNDVFAgb3ZlciBEVExTIHdpdGggVENQIHdpdGhvdXQgSUNFLiBJcyB0aGF0IGFj dHVhbGx5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5saWtlbHkuIEkgbm90ZSB0aGF0IHBlciBwcmV2aW91cyBk aXNjdXNzaW9ucywgSlNFUCBhbHJlYWR5IHJlcXVpcmVzIHRoYXQgeW91IHVzZTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3 Nzc3NyI+VURQL0RUTFMvU0NUUCBhbGwgdGhlIHRpbWU6Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3J0 Y3dlYi13Zy5naXRodWIuaW8vanNlcC8jcmZjLnNlY3Rpb24uNS4xLjIiIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vcnRjd2ViLXdnLmdpdGh1Yi5pby9qc2VwLyNyZmMuc2VjdGlvbi41LjEuMjwvYT48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM3Nzc3NzciPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPi1Fa3I8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM3Nzc3NzciPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4C0046CDESESSMB209erics_-- From nobody Thu Feb 16 09:59:38 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAEA129663 for ; Thu, 16 Feb 2017 09:59:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: 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_V34R7nSiJs for ; Thu, 16 Feb 2017 09:59:34 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25B60129535 for ; Thu, 16 Feb 2017 09:59:34 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id w75so12018115ywg.1 for ; Thu, 16 Feb 2017 09:59:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ESL83bPoD437tuexKlypRV1+74BV978X2+q9ZMZP7Sw=; b=kYQpoRbTDsxLLzBIldlmJiEOLXDA2T/CbSLDnlBtr6f6b9Yn4HX/IXNgoaYKqi7kjJ 3/Prj5X6u3CN+nEyA7fkMV6kHgopqHvcfbol4lhO0ghC/+vl5Snvu9/hXNSoWMW8axmm /rUUR9RJa7NWsNt32QIQJ8gdoWUuZ5m3wmHZZj2E/I/SKOBjA7SoYvkeU9uQioyhUXMH vgoefIscyT3jKusI89hMA7mihPDobr9Vr9bSYAJwjpgjmvr8eBlNf48VQNjlre2jKsT4 N7oodzqh9Lon921JQwLpNPliCFpQ7CXvCwGWee/B53dWin6FZsLPxBVBOqIgFpXlGBHF AxcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ESL83bPoD437tuexKlypRV1+74BV978X2+q9ZMZP7Sw=; b=fq4vZupuQqm1jhxYQ+WTXejwaDNGIwog7rqNaEJRLmxD3wFG92OSCUe5tR1gl9C0Rl NRh4Sf+eHCIA+3TDnImpi4JRO7vfjsEQ+DHuio2W5WFMTky+21bu9P7pErWohZ2WugNj FiCVDqZiznbBZt+xh9i8Rsoc/zAQcElJJwO/6SSJqGe9TKXNjG2GVd8GYf98Nit+Jygd ctwM/JRkAfbYGBvGRijrsYfgRn1UimHypJGp0oB73spXTvZUSB4SjGgk79Q8qEkpx8vY 9aOgIAGY49rGg1iS9gsyNaSTRVlmdPpZf5SwC50IZ0tVPzy0zrkIckD8MJk5S5DKGpei VFmw== X-Gm-Message-State: AMke39k91CuyFkWrrdsbDrpStVhZ6x8H7PbmtK6bKt8qYcCooZl8H599vEy5Tiyqd0JSp4Gr9MZpGdeDUhyxXQ== X-Received: by 10.129.132.77 with SMTP id u74mr2487156ywf.125.1487267973385; Thu, 16 Feb 2017 09:59:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Thu, 16 Feb 2017 09:58:53 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Thu, 16 Feb 2017 09:58:53 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114f09963dd9d80548a98f7f Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:59:36 -0000 --001a114f09963dd9d80548a98f7f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2017 at 9:07 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > *>*See: > > >https://github.com/cdh4u/draft-sdp-bundle/issues/27 > > >https://github.com/rtcweb-wg/jsep/issues/528 > > > > > >The basic issue is that it's possible to have a situation where you have > both > > >media and data m=3D sections but the BUNDLE tag is associated with the d= ata > > >m=3D section and now you need to put the TRANSPORT and IDENTICAL > > >attributes somewhere. The JSEP editors discussed this and came to the > > >conclusion that it should go with the BUNDLE tag (i.e., in the data m=3D > section) > > >and that BUNDLE should forbid this, but it requires a change to BUNDLE. > > > > Did you mean to say that BUNDLE should NOT forbid this? > > > > Based on your GitHub discussion, my understanding is that you want to > allow to include RTP-specific parameters (=E2=80=98rtcp-mux=E2=80=99, =E2= =80=98rtcp=E2=80=99, > =E2=80=98rtcp-mux-only=E2=80=99 attributes etc) in the data m=3D section. > Yes/ > > > To repeat what I said on GitHub: > > > > This has been discussed in the past, and the outcome has been to now allo= w > RTP-specific parameters in non-RTP m=3D sections. > Do you mean "not" rather than now? -Ekr > > > A solution would be to simply change the bundle tag when the RTP m=3D > sections are added. > > > > =E2=80=A6OR, we change the mux category for the RTP-specific parameters. = But, that > of course means they have to be added to every RTP m=3D section. > > > > Regards, > > > > Christer > --001a114f09963dd9d80548a98f7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 16, 2017 at 9:07 AM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

>See:=

>=C2=A0

>The basic issue is that it's possible to hav= e a situation where you have both

>media and data m=3D sections but the BUNDLE tag = is associated with the data

>m=3D section and now you need to put the TRANSPO= RT and IDENTICAL

>attributes somewhere. The JSEP editors discussed= this and came to the

>conclusion that it should go with the BUNDLE tag= (i.e., in the data m=3D section)

>and that BUNDLE should forbid this, but it requi= res a change to BUNDLE.

=C2=A0

Did you mean to say that BUNDLE should NOT forbid t= his?

=C2=A0

Based on your GitHub discussion, my understanding i= s that you want to allow to include RTP-specific parameters (=E2=80=98rtcp-= mux=E2=80=99, =E2=80=98rtcp=E2=80=99, =E2=80=98rtcp-mux-only=E2=80=99 attri= butes etc) in the data m=3D section.


Yes/
=C2=A0

=C2=A0

To repeat what I said on GitHub:

=C2=A0

This has been discussed in the past, and the outcom= e has been to now allow RTP-specific parameters in non-RTP m=3D sections.


Do you me= an "not" rather than now?

-Ekr
=C2=A0
<= div>

=C2=A0

A solution would be to simply change the bundle tag= when the RTP m=3D sections are added.

=C2=A0

=E2=80=A6OR, we change the mux category for the RTP= -specific parameters. But, that of course means they have to be added to ev= ery RTP m=3D section.

=C2=A0

Regards,

=C2=A0

Christer


--001a114f09963dd9d80548a98f7f-- From nobody Thu Feb 16 10:07:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282E1129624 for ; Thu, 16 Feb 2017 10:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Za8A14dhiV2A for ; Thu, 16 Feb 2017 10:07:52 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719AA1294F1 for ; Thu, 16 Feb 2017 10:07:52 -0800 (PST) X-AuditID: c1b4fb3a-f72d4980000021e0-f2-58a5ea763023 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id D7.49.08672.67AE5A85; Thu, 16 Feb 2017 19:07:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 19:07:41 +0100 From: Christer Holmberg To: Eric Rescorla Thread-Topic: [MMUSIC] Issue #27: Allow RTP attributes in non-media m= sections Thread-Index: AQHSiF+7PjHVV4um5k+nn0lmLGqqn6Fr2vKwgAAANoCAABM4/w== Date: Thu, 16 Feb 2017 18:07:40 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A1249D1AA5724958B2480F26A599DFE0ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbHdW7fs1dIIg//HVS1WvD7HbjF1+WMW ByaPJUt+MnlMftzGHMAUxWWTkpqTWZZapG+XwJXRsr2ZvWC7c8WprmtMDYwXrLsYOTkkBEwk ulafZe1i5OIQEljHKLGk6QMThLOYUeL4p0Ygh4ODTcBCovufNkiDiICCxK8/J1hAbGYBeYkL S9YwgdjCAgES25ZtZ4WoCZS4036THcJ2kri18CkziM0ioCrR2n+DEcTmFbCXuLD3OpgtJHCT UWL3owQQmxOot/fUCrA5jAJiEt9PQcxnFhCXuPVkPhPE0QISS/acZ4awRSVePv7HClGTLHHk 7R9WiPmCEidnPmGZwCg8C0n7LCRls5CUQcQNJN6fm88MYWtLLFv4GsrWl9j45SwjsvgCRvZV jKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIHxc3DLb6sdjAefOx5iFOBgVOLhLdi3NEKINbGs uDL3EKMEB7OSCO/qq0Ah3pTEyqrUovz4otKc1OJDjNIcLErivGYr74cLCaQnlqRmp6YWpBbB ZJk4OKUaGHlFJRMYZrB+2/Do7cnQDg1Ln4OPtBhu7jYTd3786WX97keFt39zJK1V/dl0ya4s zeyp9gnL2Qu0P78Q0M04Hc92rv3PlQeXlu63eelw5OvDU3HT971Z3fnssPId8Y++12/fNTq1 xP0x09kn3S0qgvo7U5Yz1gda5CjPmVIc+ybxHF9sWnR031olluKMREMt5qLiRACtD4KrmwIA AA== Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:07:54 -0000 --_000_A1249D1AA5724958B2480F26A599DFE0ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes, I meant "not" :) Sent from my iPhone On 16 Feb 2017, at 18.59, Eric Rescorla >= wrote: On Thu, Feb 16, 2017 at 9:07 AM, Christer Holmberg > wrote: Hi, >See: >https://github.com/cdh4u/draft-sdp-bundle/issues/27 >https://github.com/rtcweb-wg/jsep/issues/528 > >The basic issue is that it's possible to have a situation where you have b= oth >media and data m=3D sections but the BUNDLE tag is associated with the dat= a >m=3D section and now you need to put the TRANSPORT and IDENTICAL >attributes somewhere. The JSEP editors discussed this and came to the >conclusion that it should go with the BUNDLE tag (i.e., in the data m=3D s= ection) >and that BUNDLE should forbid this, but it requires a change to BUNDLE. Did you mean to say that BUNDLE should NOT forbid this? Based on your GitHub discussion, my understanding is that you want to allow= to include RTP-specific parameters (=91rtcp-mux=92, =91rtcp=92, =91rtcp-mu= x-only=92 attributes etc) in the data m=3D section. Yes/ To repeat what I said on GitHub: This has been discussed in the past, and the outcome has been to now allow = RTP-specific parameters in non-RTP m=3D sections. Do you mean "not" rather than now? -Ekr A solution would be to simply change the bundle tag when the RTP m=3D secti= ons are added. =85OR, we change the mux category for the RTP-specific parameters. But, tha= t of course means they have to be added to every RTP m=3D section. Regards, Christer --_000_A1249D1AA5724958B2480F26A599DFE0ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Yes, I meant "not" :)

Sent from my iPhone

On 16 Feb 2017, at 18.59, Eric Rescorla <ekr@rtfm.com> wrote:



On Thu, Feb 16, 2017 at 9:07 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

 

>See:=

> 

>The basic issue is that it's possible to have a = situation where you have both

>media and data m=3D sections but the BUNDLE tag = is associated with the data

>m=3D section and now you need to put the TRANSPO= RT and IDENTICAL

>attributes somewhere. The JSEP editors discussed= this and came to the

>conclusion that it should go with the BUNDLE tag= (i.e., in the data m=3D section)

>and that BUNDLE should forbid this, but it requi= res a change to BUNDLE.

 

Did you mean to say that BUNDLE should NOT forbid t= his?

 

Based on your GitHub discussion, my understanding i= s that you want to allow to include RTP-specific parameters (=91rtcp-mux=92= , =91rtcp=92, =91rtcp-mux-only=92 attributes etc) in the data m=3D section.


Yes/
 

 

To repeat what I said on GitHub:

 

This has been discussed in the past, and the outcom= e has been to now allow RTP-specific parameters in non-RTP m=3D sections.


Do you mean "not" rather than now?

-Ekr
 

 

A solution would be to simply change the bundle tag= when the RTP m=3D sections are added.

 

=85OR, we change the mux category for the RTP-speci= fic parameters. But, that of course means they have to be added to every RT= P m=3D section.

 

Regards,

 

Christer


--_000_A1249D1AA5724958B2480F26A599DFE0ericssoncom_-- From nobody Thu Feb 16 11:11:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73348129663 for ; Thu, 16 Feb 2017 11:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po4qN7Kq0jjh for ; Thu, 16 Feb 2017 11:11:42 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9FB12955E for ; Thu, 16 Feb 2017 11:11:42 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id 11so24585999qkl.3 for ; Thu, 16 Feb 2017 11:11:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nRHBuWAXw86xGFXZxGxtWRSmy8+lZXhOWGYw1yBM9iU=; b=lDNtNfiIgVNIciW8N8Z5BjsZLXHq6ez5kCf+XLnWsW4IXCe4xgJ4rSkwaNTtC9YCWL NOKzzKjyt/I/Ev0Yyk31MnGbnHnomlUJ73vuXXbSh69GEfy6D3bLHM0BbMr58r+JzouX HF9NeIDgGUq1xz3GYlXs1nR48WHubo286rhNB+e1qTDpkvAuqHDj2a9htGB99KO3XGyS wTEeWqlKeo6JlIYDDNVEMySZnCAoTWooTpFt4g5DqKUUR96/nmT21KqYxGswk/dM8tCk QCBg4eubtny8Cm3oP/XxdKJLiCrBILTDOZ0L0Yz2vKIaxCGQi6y+MvlWmYdoEvv2dXss Obtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nRHBuWAXw86xGFXZxGxtWRSmy8+lZXhOWGYw1yBM9iU=; b=Fyc217OxGSjscIYo6QhM271P40id5WPZNAGYeMW1qWVNcF3T2x2Ksf/oR1Dveh0hSq fL8R512T5AvDrZlHam51lrOkXAwmll9aahfaQ03TOdmB83VDAs/qELlrd4sS/vxAen/y 3lcezvT5lSqaCqRVIvJPLs0F1cZnsevZLOcFFLVGcEnCPMPJYHJk5jLVQViFxKplCOlq UtWi6/75J1zMz5Tza85uMgWMsydV3/ygSTisBLSpOFzK8tuOiusPJOWtgpzWDX+VNVUi zyyckpxw5qxy+xvssZcK2qa65I5B6cTpXzBWwfeuJKJG3b0sTipTnce0JYVvinA3go3R ySnw== X-Gm-Message-State: AMke39lyn3qLNg3Q6iZKfeOfrQ2pEqLnPQjIOtdWlzxRWv78m2qMmo4bqMuQUWMmfAAQayRq2q+mH6+I54Jmhhcr X-Received: by 10.55.129.71 with SMTP id c68mr3606502qkd.113.1487272301017; Thu, 16 Feb 2017 11:11:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.38.188 with HTTP; Thu, 16 Feb 2017 11:11:40 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> From: Taylor Brandstetter Date: Thu, 16 Feb 2017 11:11:40 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c06266a306d2e0548aa9164 Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:11:44 -0000 --94eb2c06266a306d2e0548aa9164 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Yes, I meant "not" :) I can't find this restriction in the current draft of BUNDLE. Also, this restriction would make BUNDLE even more complex and non-future-proof (suppose some future protocol that can be bundled with RTP also has its own TRANSPORT attributes). What are the reasons for this restriction? Shouldn't endpoints ignore attributes they don't expect? "If an attribute is received that is not understood, it MUST be ignored by the receiver." > OR, we change the mux category for the RTP-specific parameters. But, that > of course means they have to be added to every RTP m=3D section. > That wouldn't make sense in my opinion. If rtcp-rsize wasn't a transport-level attribute, then multiple bundled m=3D sections would be allowed to use different values for it. It's fundamentally a transport-level attribute. On Thu, Feb 16, 2017 at 10:07 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Yes, I meant "not" :) > > Sent from my iPhone > > On 16 Feb 2017, at 18.59, Eric Rescorla wrote: > > > > On Thu, Feb 16, 2017 at 9:07 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> *>*See: >> >> >https://github.com/cdh4u/draft-sdp-bundle/issues/27 >> >> >https://github.com/rtcweb-wg/jsep/issues/528 >> >> > >> >> >The basic issue is that it's possible to have a situation where you hav= e >> both >> >> >media and data m=3D sections but the BUNDLE tag is associated with the = data >> >> >m=3D section and now you need to put the TRANSPORT and IDENTICAL >> >> >attributes somewhere. The JSEP editors discussed this and came to the >> >> >conclusion that it should go with the BUNDLE tag (i.e., in the data m= =3D >> section) >> >> >and that BUNDLE should forbid this, but it requires a change to BUNDLE. >> >> >> >> Did you mean to say that BUNDLE should NOT forbid this? >> >> >> >> Based on your GitHub discussion, my understanding is that you want to >> allow to include RTP-specific parameters (=E2=80=98rtcp-mux=E2=80=99, = =E2=80=98rtcp=E2=80=99, >> =E2=80=98rtcp-mux-only=E2=80=99 attributes etc) in the data m=3D section= . >> > > Yes/ > > >> >> >> To repeat what I said on GitHub: >> >> >> >> This has been discussed in the past, and the outcome has been to now >> allow RTP-specific parameters in non-RTP m=3D sections. >> > > Do you mean "not" rather than now? > > -Ekr > > >> >> >> A solution would be to simply change the bundle tag when the RTP m=3D >> sections are added. >> >> >> >> =E2=80=A6OR, we change the mux category for the RTP-specific parameters.= But, >> that of course means they have to be added to every RTP m=3D section. >> >> >> >> Regards, >> >> >> >> Christer >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --94eb2c06266a306d2e0548aa9164 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I meant "not" :)
=C2=A0
I can't find this restriction in the current dra= ft of BUNDLE. Also, this restriction would make BUNDLE even more complex an= d non-future-proof (suppose some future protocol that can be bundled with R= TP also has its own TRANSPORT attributes). What are the reasons for this re= striction? Shouldn't endpoints ignore attributes they don't expect?= "If an attribute is received that is not understood, it MUST be ignor= ed by the receiver."
=C2=A0

OR, we change t= he mux category for the RTP-specific parameters. But, that of course means = they have to be added to every RTP m=3D section.


That wouldn't make sense in my opinion. If rtcp-rsize = wasn't a transport-level attribute, then multiple bundled m=3D sections= would be allowed to use different values for it. It's fundamentally a = transport-level attribute.


On Thu, Feb 16, 2017 at 10:07 AM, Christer Holmber= g <christer.holmberg@ericsson.com> wrote:
Yes, I meant "not" :)

Sent from my iPhone

On 16 Feb 2017, at 18.59, Eric Rescorla <ekr@rtfm.com> wrote:



On Thu, Feb 16, 2017 at 9:07 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

>See:=

>=C2=A0

>The basic issue is that it's possible to hav= e a situation where you have both

>media and data m=3D sections but the BUNDLE tag = is associated with the data

>m=3D section and now you need to put the TRANSPO= RT and IDENTICAL

>attributes somewhere. The JSEP editors discussed= this and came to the

>conclusion that it should go with the BUNDLE tag= (i.e., in the data m=3D section)

>and that BUNDLE should forbid this, but it requi= res a change to BUNDLE.

=C2=A0

Did you mean to say that BUNDLE should NOT forbid t= his?

=C2=A0

Based on your GitHub discussion, my understanding i= s that you want to allow to include RTP-specific parameters (=E2=80=98rtcp-= mux=E2=80=99, =E2=80=98rtcp=E2=80=99, =E2=80=98rtcp-mux-only=E2=80=99 attri= butes etc) in the data m=3D section.


Yes/
=C2=A0

=C2=A0

To repeat what I said on GitHub:

=C2=A0

This has been discussed in the past, and the outcom= e has been to now allow RTP-specific parameters in non-RTP m=3D sections.


Do you mean "not" rather than now?

-Ekr
=C2=A0

=C2=A0

A solution would be to simply change the bundle tag= when the RTP m=3D sections are added.

=C2=A0

=E2=80=A6OR, we change the mux category for the RTP= -specific parameters. But, that of course means they have to be added to ev= ery RTP m=3D section.

=C2=A0

Regards,

=C2=A0

Christer



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

--94eb2c06266a306d2e0548aa9164-- From nobody Thu Feb 16 11:49:43 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3916212949F for ; Thu, 16 Feb 2017 11:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RgRM6rfD78W9 for ; Thu, 16 Feb 2017 11:49:40 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44686128E18 for ; Thu, 16 Feb 2017 11:49:40 -0800 (PST) X-AuditID: c1b4fb25-55bff70000001738-ce-58a60251ec5e Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 5A.85.05944.15206A85; Thu, 16 Feb 2017 20:49:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 20:49:37 +0100 From: Christer Holmberg To: Taylor Brandstetter Thread-Topic: [MMUSIC] Issue #27: Allow RTP attributes in non-media m= sections Thread-Index: AQHSiF+7PjHVV4um5k+nn0lmLGqqn6Fr2vKwgAAANoCAABM4/4AAAR4AgAAZrTA= Date: Thu, 16 Feb 2017 19:49:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C004A22@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbE9UDeIaVmEwdFpEhaXVzxktVjx+hy7 xdTlj1kcmD0WbCr1WLLkJ5PH5MdtzAHMUVw2Kak5mWWpRfp2CVwZf35UFLxQqLg05yRTA+Mf +S5GTg4JAROJO0v2MXcxcnEICaxjlLgz+xAThLOYUeLg7N3sXYwcHGwCFhLd/7RBGkQEdCVu fl3IBmIzC9hKzDx1kRGkRFggQOLGaQmIkkCJO+032SFsP4k/57oZQWwWAVWJrvaZYOW8Ar4S ffczIDbdYJI41neHCaSGE6j3xJX5rCA2o4CYxPdTa5ggVolL3HoynwniZgGJJXvOM0PYohIv H/9jhbCVJBbd/swEMp9ZQFNi/S59iFZFiSndD8HO4RUQlDg58wnLBEbRWUimzkLomIWkYxaS jgWMLKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAiPm4JbfqjsYL79xPMQowMGoxMNbsG9p hBBrYllxZe4hRgkOZiUR3rC/QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8ZivvhwsJpCeWpGan phakFsFkmTg4pRoYBaV/Ms1L6Ur8V3h13tJDRhzW8T8Vi2/4NNUvOFawUGDTm3eCc2o5/4Za Ptqcw+1y8sOUW/F6mz/ws/xdqMr1VdTJvlNdp+7fw/jge/ci/ga2JAsozp/EM7fG8EiFRvLp 01eX689ftOXidcd6iazi9dbtr+Y1Vv8NflRSJFr0LY/fJvnRtEIrJZbijERDLeai4kQAKlp8 h5QCAAA= Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:49:42 -0000 SGksDQoNCg0KPj4gWWVzLCBJIG1lYW50ICJub3QiIDopDQo+DQo+IEkgY2FuJ3QgZmluZCB0aGlz IHJlc3RyaWN0aW9uIGluIHRoZSBjdXJyZW50IGRyYWZ0IG9mIEJVTkRMRS4gQWxzbywgdGhpcyBy ZXN0cmljdGlvbiB3b3VsZCBtYWtlIEJVTkRMRSBldmVuIG1vcmUgY29tcGxleCBhbmQgDQo+IG5v bi1mdXR1cmUtcHJvb2YgKHN1cHBvc2Ugc29tZSBmdXR1cmUgcHJvdG9jb2wgdGhhdCBjYW4gYmUg YnVuZGxlZCB3aXRoIFJUUCBhbHNvIGhhcyBpdHMgb3duIFRSQU5TUE9SVCBhdHRyaWJ1dGVzKS4g V2hhdCANCj4gYXJlIHRoZSByZWFzb25zIGZvciB0aGlzIHJlc3RyaWN0aW9uPyBTaG91bGRuJ3Qg ZW5kcG9pbnRzIGlnbm9yZSBhdHRyaWJ1dGVzIHRoZXkgZG9uJ3QgZXhwZWN0PyAiSWYgYW4gYXR0 cmlidXRlIGlzIHJlY2VpdmVkIHRoYXQgaXMgDQo+IG5vdCB1bmRlcnN0b29kLCBpdCBNVVNUIGJl IGlnbm9yZWQgYnkgdGhlIHJlY2VpdmVyLiINCsKgDQpJdCdzIG5vdCBhIEJVTkRMRSByZXN0cmlj dGlvbi4gVGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgaXQncyBhIHJlc3RyaWN0aW9uIGluIHRoZSBz cGVjcyBkZWZpbmluZyB0aGUgcGFyYW1ldGVycy4NCg0KSWYgdGhlcmUgaXMgbm8gcmVzdHJpY3Rp b24sIHRoZW4gdGhlcmUgc2hvdWxkIGJlIG5vIGlzc3VlIHRvIGJlZ2luIHdpdGguIA0KDQpJZiB0 aGVyZSBpcyBhIHJlc3RyaWN0aW9uLCB0aGVuIHRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHdlIHdv dWxkIG5lZWQgdG8gdXBkYXRlIHRoZSBzcGVjcyBkZWZpbmluZyB0aGUgcGFyYW1ldGVycy4NCg0K Pj4gT1IsIHdlIGNoYW5nZSB0aGUgbXV4IGNhdGVnb3J5IGZvciB0aGUgUlRQLXNwZWNpZmljIHBh cmFtZXRlcnMuIEJ1dCwgdGhhdCBvZiBjb3Vyc2UgbWVhbnMgdGhleSBoYXZlIHRvIGJlIGFkZGVk IHRvIGV2ZXJ5IFJUUCBtPSBzZWN0aW9uLg0KPg0KPiBUaGF0IHdvdWxkbid0IG1ha2Ugc2Vuc2Ug aW4gbXkgb3Bpbmlvbi4gSWYgcnRjcC1yc2l6ZSB3YXNuJ3QgYSB0cmFuc3BvcnQtbGV2ZWwgYXR0 cmlidXRlLCB0aGVuIG11bHRpcGxlIGJ1bmRsZWQgbT0gc2VjdGlvbnMgd291bGQgDQo+IGJlIGFs bG93ZWQgdG8gdXNlIGRpZmZlcmVudCB2YWx1ZXMgZm9yIGl0LiBJdCdzIGZ1bmRhbWVudGFsbHkg YSB0cmFuc3BvcnQtbGV2ZWwgYXR0cmlidXRlLg0KDQpJIGFncmVlLiBUaGUgcXVlc3Rpb24gaXMg d2hldGhlciBpdCdzIGFsbG93ZWQgdG8gcGxhY2UgdGhlIGF0dHJpYnV0ZSBpbiBhIG5vbi1SVFAg bT0gc2VjdGlvbi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KT24gVGh1LCBGZWIg MTYsIDIwMTcgYXQgMTA6MDcgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KWWVzLCBJIG1lYW50ICJub3QiIDopDQoNClNlbnQgZnJv bSBteSBpUGhvbmUNCg0KT24gMTYgRmViIDIwMTcsIGF0IDE4LjU5LCBFcmljIFJlc2NvcmxhIDxl a3JAcnRmbS5jb20+IHdyb3RlOg0KDQoNCk9uIFRodSwgRmViIDE2LCAyMDE3IGF0IDk6MDcgQU0s IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3Rl Og0KSGksDQrCoA0KPlNlZToNCj5odHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtc2RwLWJ1 bmRsZS9pc3N1ZXMvMjcNCj5odHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvaXNzdWVz LzUyOA0KPsKgDQo+VGhlIGJhc2ljIGlzc3VlIGlzIHRoYXQgaXQncyBwb3NzaWJsZSB0byBoYXZl IGEgc2l0dWF0aW9uIHdoZXJlIHlvdSBoYXZlIGJvdGgNCj5tZWRpYSBhbmQgZGF0YSBtPSBzZWN0 aW9ucyBidXQgdGhlIEJVTkRMRSB0YWcgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBkYXRhDQo+bT0g c2VjdGlvbiBhbmQgbm93IHlvdSBuZWVkIHRvIHB1dCB0aGUgVFJBTlNQT1JUIGFuZCBJREVOVElD QUwNCj5hdHRyaWJ1dGVzIHNvbWV3aGVyZS4gVGhlIEpTRVAgZWRpdG9ycyBkaXNjdXNzZWQgdGhp cyBhbmQgY2FtZSB0byB0aGUNCj5jb25jbHVzaW9uIHRoYXQgaXQgc2hvdWxkIGdvIHdpdGggdGhl IEJVTkRMRSB0YWcgKGkuZS4sIGluIHRoZSBkYXRhIG09IHNlY3Rpb24pDQo+YW5kIHRoYXQgQlVO RExFIHNob3VsZCBmb3JiaWQgdGhpcywgYnV0IGl0IHJlcXVpcmVzIGEgY2hhbmdlIHRvIEJVTkRM RS4NCsKgDQpEaWQgeW91IG1lYW4gdG8gc2F5IHRoYXQgQlVORExFIHNob3VsZCBOT1QgZm9yYmlk IHRoaXM/DQrCoA0KQmFzZWQgb24geW91ciBHaXRIdWIgZGlzY3Vzc2lvbiwgbXkgdW5kZXJzdGFu ZGluZyBpcyB0aGF0IHlvdSB3YW50IHRvIGFsbG93IHRvIGluY2x1ZGUgUlRQLXNwZWNpZmljIHBh cmFtZXRlcnMgKOKAmHJ0Y3AtbXV44oCZLCDigJhydGNw4oCZLCDigJhydGNwLW11eC1vbmx54oCZ IGF0dHJpYnV0ZXMgZXRjKSBpbiB0aGUgZGF0YSBtPSBzZWN0aW9uLg0KDQpZZXMvDQrCoA0KwqAN ClRvIHJlcGVhdCB3aGF0IEkgc2FpZCBvbiBHaXRIdWI6DQrCoA0KVGhpcyBoYXMgYmVlbiBkaXNj dXNzZWQgaW4gdGhlIHBhc3QsIGFuZCB0aGUgb3V0Y29tZSBoYXMgYmVlbiB0byBub3cgYWxsb3cg UlRQLXNwZWNpZmljIHBhcmFtZXRlcnMgaW4gbm9uLVJUUCBtPSBzZWN0aW9ucy4NCg0KRG8geW91 IG1lYW4gIm5vdCIgcmF0aGVyIHRoYW4gbm93Pw0KDQotRWtyDQrCoA0KwqANCkEgc29sdXRpb24g d291bGQgYmUgdG8gc2ltcGx5IGNoYW5nZSB0aGUgYnVuZGxlIHRhZyB3aGVuIHRoZSBSVFAgbT0g c2VjdGlvbnMgYXJlIGFkZGVkLg0KwqANCuKApk9SLCB3ZSBjaGFuZ2UgdGhlIG11eCBjYXRlZ29y eSBmb3IgdGhlIFJUUC1zcGVjaWZpYyBwYXJhbWV0ZXJzLiBCdXQsIHRoYXQgb2YgY291cnNlIG1l YW5zIHRoZXkgaGF2ZSB0byBiZSBhZGRlZCB0byBldmVyeSBSVFAgbT0gc2VjdGlvbi4NCsKgDQpS ZWdhcmRzLA0KwqANCkNocmlzdGVyDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0K From rshpount@turbobridge.com Thu Feb 16 09:39:54 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192FE126CD8 for ; Thu, 16 Feb 2017 09:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=turbobridge.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIgNvawb8tS9 for ; Thu, 16 Feb 2017 09:39:51 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ABCD12964F for ; Thu, 16 Feb 2017 09:39:45 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id u25so22309879qki.2 for ; Thu, 16 Feb 2017 09:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=turbobridge.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=novmeJZEqdT7T4qGb6hn5XvP6B9/EUgaDi3POVqubGQ=; b=uT4laqr46FNzEZHF1D0euHnynp1hx1nRJTGHq9OHjwSj/AdLxuHp6P4ujPjPxnbgvb zWFCJepGJcKRWEWT+3wzzo7CYRQV9GXKPWdv81eEPsvao6lxFf0aOLATJYEe4yJ31q8N C07k1KKwvFNypJ1pVVDKhakmRHBy1PJYWCk60= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=novmeJZEqdT7T4qGb6hn5XvP6B9/EUgaDi3POVqubGQ=; b=KqaBvXX+BFKVIVfCEI035c6jQ1k9pxIWbZWyMGpDA1aLeHS71Ev1KNn14U1hBN5XO9 AQyY7HEkmYeEjX6SzfYgbn9pMs1MLyX993vK0+L374hhZVDWW+lDD1fANW7+ENuytNjE KsGKU9PoLSyD3BIkCGv039C9ZjdUwaYZwVlJpaCG+rn/MvsY57efLjYXB0ud7RMZT0YB aTH7DkERkAEoYhmEFGCHVpftClIsOn0CK4OznH56Cmsfq2+KVxHEI8S32IFtKta92GWc 7VH2796tqRRfSZI3GKeV0G4W0mcOd+IYGanSfdLe6R7bfaT5GXvwpUfpBafMt+g+xK2C ZDbQ== X-Gm-Message-State: AMke39lipkOdotQ9QsTmzdlD5fd74+FpZQozK3H9lPiI9VwAiiob/WZi2FvCJ9bdrm2OLQ== X-Received: by 10.55.122.130 with SMTP id v124mr3001389qkc.19.1487266784264; Thu, 16 Feb 2017 09:39:44 -0800 (PST) Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com. [209.85.220.173]) by smtp.gmail.com with ESMTPSA id o16sm3825294qkl.67.2017.02.16.09.39.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 09:39:43 -0800 (PST) Received: by mail-qk0-f173.google.com with SMTP id p22so22530189qka.0; Thu, 16 Feb 2017 09:39:43 -0800 (PST) X-Received: by 10.55.17.206 with SMTP id 75mr3122678qkr.34.1487266783165; Thu, 16 Feb 2017 09:39:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Thu, 16 Feb 2017 09:39:42 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> From: Roman Shpount Date: Thu, 16 Feb 2017 12:39:42 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: multipart/alternative; boundary=001a1146c91e4c04fd0548a94835 Archived-At: X-Mailman-Approved-At: Thu, 16 Feb 2017 13:55:57 -0800 Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , The IESG , Christer Holmberg , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:53:24 -0000 --001a1146c91e4c04fd0548a94835 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, I think a little bit of background will help here. UDP/DTLS/SCTP and TCP/DTLS/SCTP are designed to work with ICE (RFC 5245). In ICE environments, during the nomination process, end points go through multiple candidate pairs, until the most preferred pair is found. During this selection process, data can be sent as soon as the first working pair is found, but the process still continues and candidate pairs can change while data is sent. Furthermore, if end points roam, for instance when mobile end point switches from mobile internet to wifi, end points will initiate an ICE restart, which will trigger a new nomination process between the new set of candidates and likely result in new nominated candidiate pair. When these candidates change, the same DTLS association continues to run, regardless whether it is running over udp or tcp candidate pair. Because of this, ICE tcp requires using RFC 4571 framing when sending data (https://tools.ietf.org/html/rfc6544#section-10.1). Otherwise, if TLS were used, a new TLS or DTLS session would be required every time candidate pair switches between tcp and udp candidates. In order to simplify transition between different underlying transports, DTLS is used for both udp and tcp candidates and TCP/DTLS/SCTP transport tag is defined to differentiate it from other protocols. As far as TCP/DTLS/SCTP transport tag is concerned, please note that ICE end points are supposed to send a re-INVITE after nomination process is completed with the selected candidate address in the m=3D line. So, if tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP transport tag in the m=3D line. Also, any offers/answers after the ICE nomination is complete, are supposed to send the currently selected candidate in the m=3D line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected. I hope this addresses your concern and explains why TCP/DTLS/SCTP is defined instead of TLS/SCTP. Regards, _____________ Roman Shpount On Thu, Feb 16, 2017 at 10:24 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > =E2=80=A6 > > > > >The only question is what should appear in the m=3D proto line. > > > > Even if nobody puts it in the m=3D line, I think it=E2=80=99s useful to k= eep it in > the document, as it gives an overview how it=E2=80=99s realized etc. > > > > It doesn=E2=80=99t cause any harm to keep it, and it=E2=80=99s =E2=80=9Cf= uture proof=E2=80=9D IF someone > wants to use it without ICE at some point. > > > > Regards, > > > > Christer > > > > > > Am 16.02.2017 um 16:02 schrieb Eric Rescorla : > > > > As Christer says. This design is optimized for making the media stack > simpler, which > > using TLS here would not do. > > > > -Ekr > > > > > > > > > > On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > >>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP? > > >>> > > >> Because the way it is realized is by transporting SCTP on top of DTL= S > (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and > > >> transporting DTLS on top of TCP (defined in RFC 4571). > > > > > > I got this but DTLS is a mapping to use TLS with UDP because UDP is a= n > unreliable datagram transport. If you use TCP, you > > > should use TLS. And rfc4571 is not a mapping of DTLS to TCP. > > > > The framing mechanism of RFC 4571 is used, with DTLS packets sent > instead of RTP packets. > > > > Regards, > > > > Christer > > > > > > > --001a1146c91e4c04fd0548a94835 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I think a littl= e bit of background will help here.
=
UDP/DT= LS/SCTP and=C2=A0TCP/DTLS/SCTP are designed to work with ICE (RFC 5245).=

In ICE environments, during= the nomination process, end points go through multiple candidate pairs, un= til the most preferred=C2=A0pair is found. During this selection process, d= ata can be sent as soon as the first working pair is found, but the process= still continues and candidate pairs can change while data is sent. Further= more, if end points roam, for instance when mobile end point switches from = mobile internet to wifi, end points will initiate an ICE restart, which wil= l trigger a new nomination process between the new set of candidates and li= kely result in new nominated candidiate pair. When these candidates change,= the same DTLS association continues to run, regardless whether it is runni= ng over udp or tcp candidate pair. Because of this, ICE tcp requires using = RFC 4571 framing when sending data (https://tools.ietf.org/html/rf= c6544#section-10.1). Otherwise, if TLS were used, a new TLS or DTLS ses= sion would be required every time candidate pair switches between tcp and u= dp candidates. In order to simplify transition between different underlying= transports, DTLS is used for both udp and tcp candidates and=C2=A0<= /font>TCP/DTLS/SCT= P=C2=A0tran= sport tag is defined to differentiate it from other protocols.
=

As far as=C2=A0TCP/DTLS/SCTP transport tag is concerned, please note tha= t=C2=A0ICE end poi= nts are supposed to send a re-INVITE after nomination process is completed = with the selected candidate address in the m=3D line. So, if tcp candidate = is selected, re-INVITE must be sent with TCP/DTLS/SCTP transport tag in the= m=3D line. Also, any offers/answers after the ICE nomination is complete, = are supposed to send the currently selected candidate in the m=3D line, whi= ch will also be TCP/DTLS/SCTP in case tcp candidate is selected.

I hope this addresses your concern and explains why= =C2=A0TCP/DTLS/SCT= P is defined instead of TLS/SCTP.

Regards,=
_____________
Roman Shpount

On Thu, Feb 16, 2017 at 10:24 AM, Christer H= olmberg <christer.holmberg@ericsson.com> w= rote:

Hi,

=C2=A0

=E2=80=A6

=C2=A0

>The only question is what should appear in the m= =3D proto line.

=C2=A0

Even if nobody puts it in the m=3D line, I think it=E2=80= =99s useful to keep it in the document, as it gives an overview how it=E2= =80=99s realized etc.

=C2=A0

It doesn=E2=80=99t cause any harm to keep it, and it=E2=80=99s = =E2=80=9Cfuture proof=E2=80=9D IF someone wants to use it without ICE at so= me point.

=C2=A0

Regards,<= font color=3D"#888888">

=C2=A0

Christer

=C2=A0


> Am 16.02.2017 um 16:02 schrieb Eric Rescorla <ekr@rtfm.com>:
>
> As Christer says. This design is optimized for making the media stack = simpler, which
> using TLS here would not do.
>
> -Ekr
>
>
>
>
> On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg <christer.holmberg@eric= sson.com> wrote:
> Hi,
>
> ------------------------------------------------------------= ----------
> DISCUSS:
> ------------------------------------------------------------= ----------
>
> >>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP?<= br> > >>>
> >> Because the way it is realized is by transporting SCTP on top= of DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and
> >> transporting DTLS on top of TCP (defined in RFC 4571).
> >
> > I got this but DTLS is a mapping to use TLS with UDP because UDP = is an unreliable datagram transport. If you use TCP, you
> > should use TLS. And rfc4571 is not a mapping of DTLS to TCP.
>
> The framing mechanism of RFC 4571 is used, with DTLS packets sent inst= ead of RTP packets.
>
> Regards,
>
> Christer
>
>

=C2=A0


--001a1146c91e4c04fd0548a94835-- From nobody Thu Feb 16 15:19:29 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923B2129526 for ; Thu, 16 Feb 2017 15:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVYVczya0kNP for ; Thu, 16 Feb 2017 15:19:26 -0800 (PST) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F9E1293EE for ; Thu, 16 Feb 2017 15:19:26 -0800 (PST) Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-10v.sys.comcast.net with SMTP id eVHbcZG63OhhfeVKfc0q2Y; Thu, 16 Feb 2017 23:19:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1487287165; bh=FrX4Jh6Ys3VmK8wLZcof9gqSXs4BFpZo+P8hl58NUn0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=UqOQ5cRfQD8ZHgGxTbEEtR8HzrpGUARVio43vJ+6SHFGbIFVifZPuxzaGxFSW+dVB RCAmiEAMOSgpMxhVsuwuxNtvWCEfAV3pyogzI4534EUDZc+AmI/XofzmmG3Y9KvrQo OifPvsozVOFmaHi/szuLm3yYIH6jAR/Q+K7Bi4Tyxd0lhsngew3EaLvyF+pEZ7SbCt Bgkith0HeOODu0NhoTb7/EMYXAczFTQ/q/yT/Pv+2SKI4C0rOLeW9qs5/NQ3TRyqpd d+KfbB6IzS2Q26sSHP6BeqakkFHxPjWZuUi8P7O/YnL36xyz04VyMTjc6MqUogutPn qcnzUqGpw//YA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-17v.sys.comcast.net with SMTP id eVKecT4Nve3QFeVKecrP6m; Thu, 16 Feb 2017 23:19:25 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4C004492@ESESSMB209.ericsson.se> <7E4962C5-52BB-416C-8C28-879F8F4ACEA4@nostrum.com> From: Paul Kyzivat Message-ID: <227192a1-f63d-f2d1-3eb3-53a31d5bc32e@comcast.net> Date: Thu, 16 Feb 2017 18:19:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <7E4962C5-52BB-416C-8C28-879F8F4ACEA4@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfDqNPgNy9zNvZ5QMKxtJD98Xk0pEkE2VBT/sErien1oFTNebubDQcT7Is9WeekzOfLkNdVAPQZVyDxu9Nu5Z2uuTbDsRLAM5GYOQJ3l9wvzvsHk2oY1i hfbU+rUavx9tXyh1oX9UOZ8hiV4tDOrIMbvi1EmA0J6+CkBNpwtrggsE6P7/cSiA+i5Dx4EoIbRhcw== Archived-At: Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 23:19:27 -0000 On 2/16/17 12:47 PM, Ben Campbell wrote: > On 16 Feb 2017, at 9:51, Christer Holmberg wrote: > >> Hi, >> >> Note that the mechanism is also used at least by CLUE, which does not >> mandate ICE (or JSEP). > > ISTM that this argument trumps the ongoing ICE usage discussion. Am I > missing something? First, lets note that TCP/DTLS/SCTP is never a desirable thing. It is simply a fallback for when for some reason UDP/DTLS/SCTP is impossible. So something attempting */DTLS/SCTP without ICE would need to have some other knowledge that UDP was impossible. This is of course *possible*. I don't know how probable a use case it is for something new now that ICE exists. IMO this is really another piece of evidence that we ought to have ICE as a transport: ICE/DTLS/SCTP. Thanks, Paul From nobody Thu Feb 16 15:50:58 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D09612947C for ; Thu, 16 Feb 2017 15:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 jFBZ55wuC8xx for ; Thu, 16 Feb 2017 15:50:56 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B8F21293DA for ; Thu, 16 Feb 2017 15:50:56 -0800 (PST) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-04v.sys.comcast.net with SMTP id eVoWcb0uSxUJaeVp8cybaU; Thu, 16 Feb 2017 23:50:54 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-12v.sys.comcast.net with SMTP id eVp7cNPhsL4A9eVp8c2Yjv; Thu, 16 Feb 2017 23:50:54 +0000 To: Christer Holmberg , IETF MMUSIC WG References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Thu, 16 Feb 2017 18:50:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfCC1tGJg5GdWDvPHjbpaJszXLST2VE4xioJxWH8kJGs6QBY4kWvi4JChj5xFkUtTIN5CofGjdayOG6fdN1Z/VAmq7stDOICwgqwicytuCKzOR+13l2vW ADNgQlA6GFxu1q7Hcu64U4U2fqrfNA6mIMMfdjHEDqxOmN3QwG/k/mOcILTH3oqqhadhBU5rTsYId6SRBMOpIeexSbTgwl/j5U5NRxeABSNf/TpgMV17rxqS Archived-At: Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 23:50:57 -0000 On 2/16/17 12:10 PM, Christer Holmberg wrote: > Hi Paul, > > I assume you have an opinion on this :) > > The suggestion is to allow RTP-specific parameters (SDP rtcp-mux > attributes etc) in non-RTP m= lines (e.g., data channel). This is a nasty issue. The problem with allowing this is: what do these parameters *mean* when so attached? And where do I look to find out? I'm not certain if they are currently permitted or not. AFAIK there is no *general* mechanism for specifying with which proto values a particular attribute may be used. I haven't studied the definitions of the "RTP-related" attributes to see if they make a specific statement about this. My guess is that they don't, but that they only define the meaning in the context of an RTP session. If that is so, perhaps the rule that unknown attributes are to be ignored should apply to those attributes when used with a non-RTP media section. But if that rule were to apply, then we would expect that with O/A the rules for how these attributes in an offer affect what goes in the answer would not apply. I guess that won't be sufficient here. So, to make this work I think it will be necessary to ammend the definitions of the particular attributes to specify this usage. And then future new attributes that pertain to RTP would also need to address this. IMO this is a can of worms. So my opinion is that these should *not* be used with non-RTP m-lines, with or without bundle. Note that data channel is a special case. While we have agreed not to consider it for now, it is possible, in principle, to run RTP over a data channel. If that were defined then these attributes would also be needed. But then they would not be used as media-level attributes. Instead, they would be dcsa attributes. Thanks, Paul > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 16 February 2017 19:07 > *To:* Eric Rescorla ; mmusic WG > *Subject:* Re: [MMUSIC] Issue #27: Allow RTP attributes in non-media m= > sections > > > > Hi, > > * * > > *>*See: > >>https://github.com/cdh4u/draft-sdp-bundle/issues/27 > >>https://github.com/rtcweb-wg/jsep/issues/528 > >> > >>The basic issue is that it's possible to have a situation where you > have both > >>media and data m= sections but the BUNDLE tag is associated with the data > >>m= section and now you need to put the TRANSPORT and IDENTICAL > >>attributes somewhere. The JSEP editors discussed this and came to the > >>conclusion that it should go with the BUNDLE tag (i.e., in the data m= > section) > >>and that BUNDLE should forbid this, but it requires a change to BUNDLE. > > > > Did you mean to say that BUNDLE should NOT forbid this? > > > > Based on your GitHub discussion, my understanding is that you want to > allow to include RTP-specific parameters (‘rtcp-mux’, ‘rtcp’, > ‘rtcp-mux-only’ attributes etc) in the data m= section. > > > > To repeat what I said on GitHub: > > > > This has been discussed in the past, and the outcome has been to now > allow RTP-specific parameters in non-RTP m= sections. > > > > A solution would be to simply change the bundle tag when the RTP m= > sections are added. > > > > …OR, we change the mux category for the RTP-specific parameters. But, > that of course means they have to be added to every RTP m= section. > > > > Regards, > > > > Christer > From nobody Thu Feb 16 18:28:01 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0B2129400 for ; Thu, 16 Feb 2017 18:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Kt6oohZxHhd for ; Thu, 16 Feb 2017 18:27:57 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F8D129463 for ; Thu, 16 Feb 2017 18:27:57 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id u25so33337130qki.2 for ; Thu, 16 Feb 2017 18:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KDQ+hcTA2rGMYRTzCOoj9mSlOEW8j7fjnR2xoFiAGq8=; b=MQzwLVC1r3gggH/7wEi9Xb514uAcxLEtFPOrZI0+CR3JcWWp8sZHyb473MMaL1GPoe FfElLeZjYzTrFcS1IgemBUpRdItrAxdPTNgRfYtTr1EHnmtVSLc2Mrzci6FL5/U68aL4 GD9yl3YJjsoxLr1OTPqFj8P4MDttaFRRNu26jpZOPAAXilcP3cVD5SPVbtFuMQKOqrOo 6T4R352wVfNGylk5sj0ppWG1+W+5fumWnBPWvgD9fG16bB837sSfg5WrrrJtP+ToPA3y TFK7fPMuiQ7LZLyD//HHkrVnB3vLHIqIh+SITEGkknApBW7+ksm5XEeJfyUVI4u9NZ5c ctwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KDQ+hcTA2rGMYRTzCOoj9mSlOEW8j7fjnR2xoFiAGq8=; b=EtgFuG9bAWLae2Qnvk/ZeV065n51yVHMCKdZprFeJ4ioDxj4vINfhLCOuhffY8ln2o QoeUtUZ7J1x7vN1QENlkyeUFE8bqy0Xc8qDLEmAiRkQw2wFC1nG7zsYuQHZ9MsE9oe8y 2D/TOi1peDDHFC4ouJpKebK7RhnIr96UzP6U8mHacxJFHDUdYq0q/sUovNAw219ZRJC7 MPOoPtOHLYx+Yk8SMQpDzIR7Co0TQidf47WZ+LUOby6P5eLRqKGt0CGuMP45KBIbknYX 3y9379dRrlk7TNdKLOKuB456P7ecm47GTCL52BpdOHkkvcjgS4zg1G6MxVKcZCPl9D4M US+A== X-Gm-Message-State: AMke39nhC1bRrU83pA0ZvFP8iWF55xpkr6jdgVQP9WFH+f/41VVt6XIdREQOOruwdvnO0I+F42rr8tQ/bJWDh4E7 X-Received: by 10.55.112.7 with SMTP id l7mr5125993qkc.252.1487298476449; Thu, 16 Feb 2017 18:27:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.38.188 with HTTP; Thu, 16 Feb 2017 18:27:56 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> From: Taylor Brandstetter Date: Thu, 16 Feb 2017 18:27:56 -0800 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a114fe9885d76900548b0a9f7 Archived-At: Cc: IETF MMUSIC WG , Christer Holmberg Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 02:27:59 -0000 --001a114fe9885d76900548b0a9f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > So, to make this work I think it will be necessary to ammend the > definitions of the particular attributes to specify this usage. And then > future new attributes that pertain to RTP would also need to address this= . sdp-mux-attributes already amends the definitions of these attributes, such that a TRANSPORT attribute in m=3D section "A" can be used for media described by m=3D section "B". So, I don't see why it couldn't go a step further, and explicitly allow TRANSPORT and IDENTICAL category attributes to appear in m=3D sections with proto values not normally used with those attributes. On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat wrote= : > On 2/16/17 12:10 PM, Christer Holmberg wrote: > >> Hi Paul, >> >> I assume you have an opinion on this :) >> >> The suggestion is to allow RTP-specific parameters (SDP rtcp-mux >> attributes etc) in non-RTP m=3D lines (e.g., data channel). >> > > This is a nasty issue. > > The problem with allowing this is: what do these parameters *mean* when s= o > attached? And where do I look to find out? > > I'm not certain if they are currently permitted or not. AFAIK there is no > *general* mechanism for specifying with which proto values a particular > attribute may be used. I haven't studied the definitions of the > "RTP-related" attributes to see if they make a specific statement about > this. My guess is that they don't, but that they only define the meaning = in > the context of an RTP session. > > If that is so, perhaps the rule that unknown attributes are to be ignored > should apply to those attributes when used with a non-RTP media section. > But if that rule were to apply, then we would expect that with O/A the > rules for how these attributes in an offer affect what goes in the answer > would not apply. I guess that won't be sufficient here. > > So, to make this work I think it will be necessary to ammend the > definitions of the particular attributes to specify this usage. And then > future new attributes that pertain to RTP would also need to address this= . > > IMO this is a can of worms. So my opinion is that these should *not* be > used with non-RTP m-lines, with or without bundle. > > Note that data channel is a special case. While we have agreed not to > consider it for now, it is possible, in principle, to run RTP over a data > channel. If that were defined then these attributes would also be needed. > But then they would not be used as media-level attributes. Instead, they > would be dcsa attributes. > > Thanks, > Paul > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer >> Holmberg >> *Sent:* 16 February 2017 19:07 >> *To:* Eric Rescorla ; mmusic WG >> *Subject:* Re: [MMUSIC] Issue #27: Allow RTP attributes in non-media m= =3D >> sections >> >> >> >> Hi, >> >> * * >> >> *>*See: >> >> https://github.com/cdh4u/draft-sdp-bundle/issues/27 >>> >> >> https://github.com/rtcweb-wg/jsep/issues/528 >>> >> >> >>> >> The basic issue is that it's possible to have a situation where you >>> >> have both >> >> media and data m=3D sections but the BUNDLE tag is associated with the d= ata >>> >> >> m=3D section and now you need to put the TRANSPORT and IDENTICAL >>> >> >> attributes somewhere. The JSEP editors discussed this and came to the >>> >> >> conclusion that it should go with the BUNDLE tag (i.e., in the data m=3D >>> >> section) >> >> and that BUNDLE should forbid this, but it requires a change to BUNDLE. >>> >> >> >> >> Did you mean to say that BUNDLE should NOT forbid this? >> >> >> >> Based on your GitHub discussion, my understanding is that you want to >> allow to include RTP-specific parameters (=E2=80=98rtcp-mux=E2=80=99, = =E2=80=98rtcp=E2=80=99, >> =E2=80=98rtcp-mux-only=E2=80=99 attributes etc) in the data m=3D section= . >> >> >> >> To repeat what I said on GitHub: >> >> >> >> This has been discussed in the past, and the outcome has been to now >> allow RTP-specific parameters in non-RTP m=3D sections. >> >> >> >> A solution would be to simply change the bundle tag when the RTP m=3D >> sections are added. >> >> >> >> =E2=80=A6OR, we change the mux category for the RTP-specific parameters.= But, >> that of course means they have to be added to every RTP m=3D section. >> >> >> >> Regards, >> >> >> >> Christer >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a114fe9885d76900548b0a9f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, to make this work I think it will be necessary= to ammend the definitions of the particular attributes to specify this usa= ge. And then future new attributes that pertain to RTP would also need to a= ddress this.

sdp-mux-attributes alre= ady amends the definitions of these attributes, such that a TRANSPORT attri= bute in m=3D section "A" can be used for media described by m=3D = section "B". So, I don't see why it couldn't go a step fu= rther, and explicitly allow TRANSPORT and IDENTICAL category attributes to = appear in m=3D sections with proto values not normally used with those attr= ibutes.

On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat <pkyzivat@alum.mit.edu= > wrote:
On 2/16/17 12:10 P= M, Christer Holmberg wrote:
Hi Paul,

I assume you have an opinion on this :)

The suggestion is to allow RTP-specific parameters (SDP rtcp-mux
attributes etc) in non-RTP m=3D lines (e.g., data channel).

This is a nasty issue.

The problem with allowing this is: what do these parameters *mean* when so = attached? And where do I look to find out?

I'm not certain if they are currently permitted or not. AFAIK there is = no *general* mechanism for specifying with which proto values a particular = attribute may be used. I haven't studied the definitions of the "R= TP-related" attributes to see if they make a specific statement about = this. My guess is that they don't, but that they only define the meanin= g in the context of an RTP session.

If that is so, perhaps the rule that unknown attributes are to be ignored s= hould apply to those attributes when used with a non-RTP media section. But= if that rule were to apply, then we would expect that with O/A the rules f= or how these attributes in an offer affect what goes in the answer would no= t apply. I guess that won't be sufficient here.

So, to make this work I think it will be necessary to ammend the definition= s of the particular attributes to specify this usage. And then future new a= ttributes that pertain to RTP would also need to address this.

IMO this is a can of worms. So my opinion is that these should *not* be use= d with non-RTP m-lines, with or without bundle.

Note that data channel is a special case. While we have agreed not to consi= der it for now, it is possible, in principle, to run RTP over a data channe= l. If that were defined then these attributes would also be needed. But the= n they would not be used as media-level attributes. Instead, they would be = dcsa attributes.

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

*From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer
Holmberg
*Sent:* 16 February 2017 19:07
*To:* Eric Rescorla <e= kr@rtfm.com>; mmusic WG <mmusic@ietf.org>
*Subject:* Re: [MMUSIC] Issue #27: Allow RTP attributes in non-media m=3D sections



Hi,

* *

*>*See:

https://github.com/cdh4u/draft-sdp-bundle/is= sues/27

https://github.com/rtcweb-wg/jsep/issues/528



The basic issue is that it's possible to have a situation where you
have both

media and data m=3D sections but the BUNDLE tag is associated with the data=

m=3D section and now you need to put the TRANSPORT and IDENTICAL

attributes somewhere. The JSEP editors discussed this and came to the

conclusion that it should go with the BUNDLE tag (i.e., in the data m=3D
section)

and that BUNDLE should forbid this, but it requires a change to BUNDLE.



Did you mean to say that BUNDLE should NOT forbid this?



Based on your GitHub discussion, my understanding is that you want to
allow to include RTP-specific parameters (=E2=80=98rtcp-mux=E2=80=99, =E2= =80=98rtcp=E2=80=99,
=E2=80=98rtcp-mux-only=E2=80=99 attributes etc) in the data m=3D section.


To repeat what I said on GitHub:



This has been discussed in the past, and the outcome has been to now
allow RTP-specific parameters in non-RTP m=3D sections.



A solution would be to simply change the bundle tag when the RTP m=3D
sections are added.



=E2=80=A6OR, we change the mux category for the RTP-specific parameters. Bu= t,
that of course means they have to be added to every RTP m=3D section.



Regards,



Christer


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

--001a114fe9885d76900548b0a9f7-- From nobody Fri Feb 17 00:27:50 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58A4129528 for ; Fri, 17 Feb 2017 00:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 hj0UDe1L3GTe for ; Fri, 17 Feb 2017 00:27:47 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B621F128B37 for ; Fri, 17 Feb 2017 00:27:46 -0800 (PST) X-AuditID: c1b4fb30-2868b98000002c77-f6-58a6b400190a Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id C0.3F.11383.004B6A85; Fri, 17 Feb 2017 09:27:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0319.002; Fri, 17 Feb 2017 09:27:43 +0100 From: Christer Holmberg To: Taylor Brandstetter , Paul Kyzivat Thread-Topic: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections Thread-Index: AQHSiMV0wsnKqkRmGEuVhuugjvh/xaFs3Maw Date: Fri, 17 Feb 2017 08:27:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C0051A7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbHdRpdxy7IIg993OCwur3jIajF1+WMW ixUbDrA6MHv8ff+ByWPBplKPJUt+MgUwR3HZpKTmZJalFunbJXBl3Pyzia3gnF7F3AUfmRoY t+h2MXJySAiYSGz495sdxBYSWMcosf2HURcjF5C9mFGi9eIixi5GDg42AQuJ7n/aIDUiAqES K2+3MYHYzAIqEq9OX2YFsYUFQiT6J8wFKwep2XKkEqLcSKLt6X5GEJtFQFVidudhsFZeAV+J 2fd3skCsusok8blrHwtIL6dAoMTr/ekgNYwCYhLfT62BWiUucevJfCaIkwUkluw5zwxhi0q8 fPyPFcJWklh0+zMTyBhmAU2J9bv0IVoVJaZ0P2SHWCsocXLmE5YJjKKzkEydhdAxC0nHLCQd CxhZVjGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIERszBLb8NdjC+fO54iFGAg1GJh7dg39II IdbEsuLK3EOMEhzMSiK8whuXRQjxpiRWVqUW5ccXleakFh9ilOZgURLnNVt5P1xIID2xJDU7 NbUgtQgmy8TBKdXA2GneXmBiPnvVnKlvZQ3+/w46mS8jIXOF+Wf0j4XL/l19Hmu1c8kPg1mf +v6+E5HrfRi1YHvF+fV//rz37xGY9bIktVn2VPzcTQ/+TV6qYDVDZNOqCz23dGKKvqYJ9F8y u6q0Qi43+lhEd3P64iq/O6vkxTnPXp3CwC/46dW34EP3d01bpmOyzU6JpTgj0VCLuag4EQDu gK+qlAIAAA== Archived-At: Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 08:27:49 -0000 SGksDQoNCj4+IFNvLCB0byBtYWtlIHRoaXMgd29yayBJIHRoaW5rIGl0IHdpbGwgYmUgbmVjZXNz YXJ5IHRvIGFtbWVuZCB0aGUgZGVmaW5pdGlvbnMgb2YgdGhlIHBhcnRpY3VsYXIgYXR0cmlidXRl cyB0byANCj4+IHNwZWNpZnkgdGhpcyB1c2FnZS4gQW5kIHRoZW4gZnV0dXJlIG5ldyBhdHRyaWJ1 dGVzIHRoYXQgcGVydGFpbiB0byBSVFAgd291bGQgYWxzbyBuZWVkIHRvIGFkZHJlc3MgdGhpcy4N Cj4NCj4gc2RwLW11eC1hdHRyaWJ1dGVzIGFscmVhZHkgYW1lbmRzIHRoZSBkZWZpbml0aW9ucyBv ZiB0aGVzZSBhdHRyaWJ1dGVzLCBzdWNoIHRoYXQgYSBUUkFOU1BPUlQgYXR0cmlidXRlIA0KPiBp biBtPSBzZWN0aW9uICJBIiBjYW4gYmUgdXNlZCBmb3IgbWVkaWEgZGVzY3JpYmVkIGJ5IG09IHNl Y3Rpb24gIkIiLiBTbywgSSBkb24ndCBzZWUgd2h5IGl0IGNvdWxkbid0IGdvIGEgDQo+IHN0ZXAg ZnVydGhlciwgYW5kIGV4cGxpY2l0bHkgYWxsb3cgVFJBTlNQT1JUIGFuZCBJREVOVElDQUwgY2F0 ZWdvcnkgYXR0cmlidXRlcyB0byBhcHBlYXIgaW4gbT0gc2VjdGlvbnMgDQo+IHdpdGggcHJvdG8g dmFsdWVzIG5vdCBub3JtYWxseSB1c2VkIHdpdGggdGhvc2UgYXR0cmlidXRlcy4NCg0KSSBhbSBz dXJlIGl0IGNvdWxkIGJlIGRvbmUuIFRoZSBxdWVzdGlvbiBpcyB3aGF0IChpZiBhbnkpIHNwZWNp ZmljYXRpb25zIHRoYXQgd291bGQgaGF2ZSB0byBiZSB1cGRhdGVkLg0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQoNCk9uIFRodSwgRmViIDE2LCAyMDE3IGF0IDM6NTAgUE0sIFBhdWwgS3l6aXZh dCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PiB3cm90ZToNCk9uIDIvMTYvMTcgMTI6MTAgUE0sIENo cmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KSGkgUGF1bCwNCg0KSSBhc3N1bWUgeW91IGhhdmUgYW4g b3BpbmlvbiBvbiB0aGlzIDopDQoNClRoZSBzdWdnZXN0aW9uIGlzIHRvIGFsbG93IFJUUC1zcGVj aWZpYyBwYXJhbWV0ZXJzIChTRFAgcnRjcC1tdXgNCmF0dHJpYnV0ZXMgZXRjKSBpbiBub24tUlRQ IG09IGxpbmVzIChlLmcuLCBkYXRhIGNoYW5uZWwpLg0KDQpUaGlzIGlzIGEgbmFzdHkgaXNzdWUu DQoNClRoZSBwcm9ibGVtIHdpdGggYWxsb3dpbmcgdGhpcyBpczogd2hhdCBkbyB0aGVzZSBwYXJh bWV0ZXJzICptZWFuKiB3aGVuIHNvIGF0dGFjaGVkPyBBbmQgd2hlcmUgZG8gSSBsb29rIHRvIGZp bmQgb3V0Pw0KDQpJJ20gbm90IGNlcnRhaW4gaWYgdGhleSBhcmUgY3VycmVudGx5IHBlcm1pdHRl ZCBvciBub3QuIEFGQUlLIHRoZXJlIGlzIG5vICpnZW5lcmFsKiBtZWNoYW5pc20gZm9yIHNwZWNp Znlpbmcgd2l0aCB3aGljaCBwcm90byB2YWx1ZXMgYSBwYXJ0aWN1bGFyIGF0dHJpYnV0ZSBtYXkg YmUgdXNlZC4gSSBoYXZlbid0IHN0dWRpZWQgdGhlIGRlZmluaXRpb25zIG9mIHRoZSAiUlRQLXJl bGF0ZWQiIGF0dHJpYnV0ZXMgdG8gc2VlIGlmIHRoZXkgbWFrZSBhIHNwZWNpZmljIHN0YXRlbWVu dCBhYm91dCB0aGlzLiBNeSBndWVzcyBpcyB0aGF0IHRoZXkgZG9uJ3QsIGJ1dCB0aGF0IHRoZXkg b25seSBkZWZpbmUgdGhlIG1lYW5pbmcgaW4gdGhlIGNvbnRleHQgb2YgYW4gUlRQIHNlc3Npb24u DQoNCklmIHRoYXQgaXMgc28sIHBlcmhhcHMgdGhlIHJ1bGUgdGhhdCB1bmtub3duIGF0dHJpYnV0 ZXMgYXJlIHRvIGJlIGlnbm9yZWQgc2hvdWxkIGFwcGx5IHRvIHRob3NlIGF0dHJpYnV0ZXMgd2hl biB1c2VkIHdpdGggYSBub24tUlRQIG1lZGlhIHNlY3Rpb24uIEJ1dCBpZiB0aGF0IHJ1bGUgd2Vy ZSB0byBhcHBseSwgdGhlbiB3ZSB3b3VsZCBleHBlY3QgdGhhdCB3aXRoIE8vQSB0aGUgcnVsZXMg Zm9yIGhvdyB0aGVzZSBhdHRyaWJ1dGVzIGluIGFuIG9mZmVyIGFmZmVjdCB3aGF0IGdvZXMgaW4g dGhlIGFuc3dlciB3b3VsZCBub3QgYXBwbHkuIEkgZ3Vlc3MgdGhhdCB3b24ndCBiZSBzdWZmaWNp ZW50IGhlcmUuDQoNClNvLCB0byBtYWtlIHRoaXMgd29yayBJIHRoaW5rIGl0IHdpbGwgYmUgbmVj ZXNzYXJ5IHRvIGFtbWVuZCB0aGUgZGVmaW5pdGlvbnMgb2YgdGhlIHBhcnRpY3VsYXIgYXR0cmli dXRlcyB0byBzcGVjaWZ5IHRoaXMgdXNhZ2UuIEFuZCB0aGVuIGZ1dHVyZSBuZXcgYXR0cmlidXRl cyB0aGF0IHBlcnRhaW4gdG8gUlRQIHdvdWxkIGFsc28gbmVlZCB0byBhZGRyZXNzIHRoaXMuDQoN CklNTyB0aGlzIGlzIGEgY2FuIG9mIHdvcm1zLiBTbyBteSBvcGluaW9uIGlzIHRoYXQgdGhlc2Ug c2hvdWxkICpub3QqIGJlIHVzZWQgd2l0aCBub24tUlRQIG0tbGluZXMsIHdpdGggb3Igd2l0aG91 dCBidW5kbGUuDQoNCk5vdGUgdGhhdCBkYXRhIGNoYW5uZWwgaXMgYSBzcGVjaWFsIGNhc2UuIFdo aWxlIHdlIGhhdmUgYWdyZWVkIG5vdCB0byBjb25zaWRlciBpdCBmb3Igbm93LCBpdCBpcyBwb3Nz aWJsZSwgaW4gcHJpbmNpcGxlLCB0byBydW4gUlRQIG92ZXIgYSBkYXRhIGNoYW5uZWwuIElmIHRo YXQgd2VyZSBkZWZpbmVkIHRoZW4gdGhlc2UgYXR0cmlidXRlcyB3b3VsZCBhbHNvIGJlIG5lZWRl ZC4gQnV0IHRoZW4gdGhleSB3b3VsZCBub3QgYmUgdXNlZCBhcyBtZWRpYS1sZXZlbCBhdHRyaWJ1 dGVzLiBJbnN0ZWFkLCB0aGV5IHdvdWxkIGJlIGRjc2EgYXR0cmlidXRlcy4NCg0KwqAgwqAgwqAg wqAgVGhhbmtzLA0KwqAgwqAgwqAgwqAgUGF1bA0KKkZyb206Km1tdXNpYyBbbWFpbHRvOm1tdXNp Yy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpDaHJpc3Rlcg0KSG9sbWJlcmcNCipT ZW50OiogMTYgRmVicnVhcnkgMjAxNyAxOTowNw0KKlRvOiogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0 Zm0uY29tPjsgbW11c2ljIFdHIDxtbXVzaWNAaWV0Zi5vcmc+DQoqU3ViamVjdDoqIFJlOiBbTU1V U0lDXSBJc3N1ZSAjMjc6IEFsbG93IFJUUCBhdHRyaWJ1dGVzIGluIG5vbi1tZWRpYSBtPQ0Kc2Vj dGlvbnMNCg0KDQoNCkhpLA0KDQoqICoNCg0KKj4qU2VlOg0KaHR0cHM6Ly9naXRodWIuY29tL2Nk aDR1L2RyYWZ0LXNkcC1idW5kbGUvaXNzdWVzLzI3DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3 ZWItd2cvanNlcC9pc3N1ZXMvNTI4DQoNCg0KDQpUaGUgYmFzaWMgaXNzdWUgaXMgdGhhdCBpdCdz IHBvc3NpYmxlIHRvIGhhdmUgYSBzaXR1YXRpb24gd2hlcmUgeW91DQpoYXZlIGJvdGgNCm1lZGlh IGFuZCBkYXRhIG09IHNlY3Rpb25zIGJ1dCB0aGUgQlVORExFIHRhZyBpcyBhc3NvY2lhdGVkIHdp dGggdGhlIGRhdGENCg0KbT0gc2VjdGlvbiBhbmQgbm93IHlvdSBuZWVkIHRvIHB1dCB0aGUgVFJB TlNQT1JUIGFuZCBJREVOVElDQUwNCg0KYXR0cmlidXRlcyBzb21ld2hlcmUuIFRoZSBKU0VQIGVk aXRvcnMgZGlzY3Vzc2VkIHRoaXMgYW5kIGNhbWUgdG8gdGhlDQoNCmNvbmNsdXNpb24gdGhhdCBp dCBzaG91bGQgZ28gd2l0aCB0aGUgQlVORExFIHRhZyAoaS5lLiwgaW4gdGhlIGRhdGEgbT0NCnNl Y3Rpb24pDQphbmQgdGhhdCBCVU5ETEUgc2hvdWxkIGZvcmJpZCB0aGlzLCBidXQgaXQgcmVxdWly ZXMgYSBjaGFuZ2UgdG8gQlVORExFLg0KDQoNCg0KRGlkIHlvdSBtZWFuIHRvIHNheSB0aGF0IEJV TkRMRSBzaG91bGQgTk9UIGZvcmJpZCB0aGlzPw0KDQoNCg0KQmFzZWQgb24geW91ciBHaXRIdWIg ZGlzY3Vzc2lvbiwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHlvdSB3YW50IHRvDQphbGxvdyB0 byBpbmNsdWRlIFJUUC1zcGVjaWZpYyBwYXJhbWV0ZXJzICjigJhydGNwLW11eOKAmSwg4oCYcnRj cOKAmSwNCuKAmHJ0Y3AtbXV4LW9ubHnigJkgYXR0cmlidXRlcyBldGMpIGluIHRoZSBkYXRhIG09 IHNlY3Rpb24uDQoNCg0KDQpUbyByZXBlYXQgd2hhdCBJIHNhaWQgb24gR2l0SHViOg0KDQoNCg0K VGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgaW4gdGhlIHBhc3QsIGFuZCB0aGUgb3V0Y29tZSBoYXMg YmVlbiB0byBub3cNCmFsbG93IFJUUC1zcGVjaWZpYyBwYXJhbWV0ZXJzIGluIG5vbi1SVFAgbT0g c2VjdGlvbnMuDQoNCg0KDQpBIHNvbHV0aW9uIHdvdWxkIGJlIHRvIHNpbXBseSBjaGFuZ2UgdGhl IGJ1bmRsZSB0YWcgd2hlbiB0aGUgUlRQIG09DQpzZWN0aW9ucyBhcmUgYWRkZWQuDQoNCg0KDQri gKZPUiwgd2UgY2hhbmdlIHRoZSBtdXggY2F0ZWdvcnkgZm9yIHRoZSBSVFAtc3BlY2lmaWMgcGFy YW1ldGVycy4gQnV0LA0KdGhhdCBvZiBjb3Vyc2UgbWVhbnMgdGhleSBoYXZlIHRvIGJlIGFkZGVk IHRvIGV2ZXJ5IFJUUCBtPSBzZWN0aW9uLg0KDQoNCg0KUmVnYXJkcywNCg0KDQoNCkNocmlzdGVy DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptbXVz aWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg== From nobody Fri Feb 17 00:44:14 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 676011295AC; Fri, 17 Feb 2017 00:44:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148732104941.19992.4685982525339354035.idtracker@ietfa.amsl.com> Date: Fri, 17 Feb 2017 00:44:09 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 08:44:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Author : Christer Holmberg Filename : draft-ietf-mmusic-mux-exclusive-11.txt Pages : 12 Date : 2017-02-17 Abstract: This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-mux-exclusive-11 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 17 00:47:34 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007671295BC for ; Fri, 17 Feb 2017 00:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 BLEPEU2D8tZS for ; Fri, 17 Feb 2017 00:47:32 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61AE01293E4 for ; Fri, 17 Feb 2017 00:47:32 -0800 (PST) X-AuditID: c1b4fb2d-da3ff70000005112-66-58a6b8a0cebd Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 10.61.20754.0A8B6A85; Fri, 17 Feb 2017 09:47:30 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0319.002; Fri, 17 Feb 2017 09:46:24 +0100 From: Christer Holmberg To: IETF MMUSIC WG Thread-Topic: Draft new version: draft-ietf-mmusic-mux-exclusive-11 Thread-Index: AdKI+iY0OvIJUG5TTf2For0WbJau/Q== Date: Fri, 17 Feb 2017 08:46:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C005232@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyM2K7me6iHcsiDP6sFLeYuvwxiwOjx5Il P5kCGKO4bFJSczLLUov07RK4MnZf3s9ScIq/4uOS66wNjMd4uhg5OSQETCTmbjzC3sXIxSEk sI5RYtX3fcwQzmJGicYNbxi7GDk42AQsJLr/aYM0iAioSPx794ANxBYWsJPYMuUcC0TcWWL9 9smMELaeRPOpFawgNouAqsSaB+/YQWxeAV+Jz/8OgcUZBcQkvp9awwRiMwuIS9x6Mp8J4iAB iSV7zjND2KISLx//Y4WwlSQW3f4MVa8jsWD3JzYIW1ti2cLXzBDzBSVOznzCMoFRaBaSsbOQ tMxC0jILScsCRpZVjKLFqcXFuelGxnqpRZnJxcX5eXp5qSWbGIGhfHDLb90djKtfOx5iFOBg VOLhLdi3NEKINbGsuDL3EKMEB7OSCO//rcsihHhTEiurUovy44tKc1KLDzFKc7AoifOarbwf LiSQnliSmp2aWpBaBJNl4uCUamCsChbcx7VJjsepO8rujeKrL0JfYz2qLaOOS576dC1vofi1 nhr/m/uuWFp8kBDO1Zp9wpmR6fsrvs/dcTe8d/A4FzT4Kz5vcNffvGWzu+DnPwfTfcxmpvRN i3npEHZB8ZaP5AOJ+kztDsWXbQtXiblyGXovUc+7u8lxFU/NJhaG9J9z5A9ZPFViKc5INNRi LipOBAA2J7BcYQIAAA== Archived-At: Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 08:47:34 -0000 Hi, Based on the comments from Ekr, I've submitted a new version of draft-mux-e= xclusive. The SDP 'rtcp-mux-only' attribute is now only allowed in SDP offers. Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: 17 February 2017 10:44 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-11.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control of t= he IETF. Title : Indicating Exclusive Support of RTP/RTCP Multiple= xing using SDP Author : Christer Holmberg Filename : draft-ietf-mmusic-mux-exclusive-11.txt Pages : 12 Date : 2017-02-17 Abstract: This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-mux-exclusive-11 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/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Feb 17 05:25:58 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC1C129566 for ; Fri, 17 Feb 2017 05:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 zPAdcLayQb60 for ; Fri, 17 Feb 2017 05:25:54 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3258A129546 for ; Fri, 17 Feb 2017 05:25:54 -0800 (PST) Received: (qmail 25971 invoked from network); 17 Feb 2017 14:19:10 +0100 Received: from pd9e1133e.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.19.62) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Feb 2017 14:19:10 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Fri, 17 Feb 2017 14:19:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <55E6C40E-DF5E-4A61-8F02-D5B6E75A8D4C@kuehlewind.net> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> To: Roman Shpount X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , The IESG , Christer Holmberg , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 13:25:57 -0000 Hi Roman, thanks a lot for the explanation. I talked to ekr yesterday during the = telechat and already cleared my discuss. However, I think some more = explanation about this =E2=80=9Aproblem=E2=80=98 explained below in the = draft would be good as well. I understood that TCP is rather the backup than a preferred solution but = it wasn=E2=80=99t clear to me at the beginning how dynamically the = situation can realistically change. I think it would be still good to = note more explicitly in the draft that UDP should be the prefer = transport (especially if e.g. ICE is not used) and that both approaches = are not equally good. Also if you use SCTP over TCP you have two = congestion control loops. While the transmission over TCP will appear = loss-free for the SCTP stack, due to TCP retransmissions SCTP will see = higher delay variations that also influence the transmission behavior = and may slow down SCTP unnecessarily. I think that might be also wot = noticing. Regarding the m=3D line (and I=E2=80=99m by far not expert here, so = excuse me if that doesn't make sense), I guess for the ICE case you = could also just use DTLS/SCTP, no? Wouldn't that resolve the oddity that = you announce one thing and use another? And then you can maybe have an = additional tag for the transport used for the non-ICE cases=E2=80=A6? = Mainly wondering if there is maybe a clearer solution here? Mirja > Am 16.02.2017 um 18:39 schrieb Roman Shpount = : >=20 > Hi All, >=20 > I think a little bit of background will help here. >=20 > UDP/DTLS/SCTP and TCP/DTLS/SCTP are designed to work with ICE (RFC = 5245). >=20 > In ICE environments, during the nomination process, end points go = through multiple candidate pairs, until the most preferred pair is = found. During this selection process, data can be sent as soon as the = first working pair is found, but the process still continues and = candidate pairs can change while data is sent. Furthermore, if end = points roam, for instance when mobile end point switches from mobile = internet to wifi, end points will initiate an ICE restart, which will = trigger a new nomination process between the new set of candidates and = likely result in new nominated candidiate pair. When these candidates = change, the same DTLS association continues to run, regardless whether = it is running over udp or tcp candidate pair. Because of this, ICE tcp = requires using RFC 4571 framing when sending data = (https://tools.ietf.org/html/rfc6544#section-10.1). Otherwise, if TLS = were used, a new TLS or DTLS session would be required every time = candidate pair switches between tcp and udp candidates. In order to = simplify transition between different underlying transports, DTLS is = used for both udp and tcp candidates and TCP/DTLS/SCTP transport tag is = defined to differentiate it from other protocols. >=20 > As far as TCP/DTLS/SCTP transport tag is concerned, please note that = ICE end points are supposed to send a re-INVITE after nomination process = is completed with the selected candidate address in the m=3D line. So, = if tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP = transport tag in the m=3D line. Also, any offers/answers after the ICE = nomination is complete, are supposed to send the currently selected = candidate in the m=3D line, which will also be TCP/DTLS/SCTP in case tcp = candidate is selected. >=20 > I hope this addresses your concern and explains why TCP/DTLS/SCTP is = defined instead of TLS/SCTP. >=20 > Regards, > _____________ > Roman Shpount >=20 > On Thu, Feb 16, 2017 at 10:24 AM, Christer Holmberg = wrote: > Hi, >=20 > =20 >=20 > =E2=80=A6 >=20 > =20 >=20 > >The only question is what should appear in the m=3D proto line. >=20 > =20 >=20 > Even if nobody puts it in the m=3D line, I think it=E2=80=99s useful = to keep it in the document, as it gives an overview how it=E2=80=99s = realized etc. >=20 > =20 >=20 > It doesn=E2=80=99t cause any harm to keep it, and it=E2=80=99s = =E2=80=9Cfuture proof=E2=80=9D IF someone wants to use it without ICE at = some point. >=20 > =20 >=20 > Regards, >=20 > =20 >=20 > Christer >=20 > =20 >=20 >=20 > > Am 16.02.2017 um 16:02 schrieb Eric Rescorla : > > > > As Christer says. This design is optimized for making the media = stack simpler, which > > using TLS here would not do. > > > > -Ekr > > > > > > > > > > On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg = wrote: > > Hi, > > > > = ---------------------------------------------------------------------- > > DISCUSS: > > = ---------------------------------------------------------------------- > > > > >>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP? > > >>> > > >> Because the way it is realized is by transporting SCTP on top of = DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and > > >> transporting DTLS on top of TCP (defined in RFC 4571). > > > > > > I got this but DTLS is a mapping to use TLS with UDP because UDP = is an unreliable datagram transport. If you use TCP, you > > > should use TLS. And rfc4571 is not a mapping of DTLS to TCP. > > > > The framing mechanism of RFC 4571 is used, with DTLS packets sent = instead of RTP packets. > > > > Regards, > > > > Christer > > > > >=20 > =20 >=20 >=20 From nobody Fri Feb 17 05:46:28 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA391299F5; Fri, 17 Feb 2017 05:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 KBTTd8dj37ap; Fri, 17 Feb 2017 05:46:20 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F909129477; Fri, 17 Feb 2017 05:46:19 -0800 (PST) X-AuditID: c1b4fb3a-f72d4980000021e0-bc-58a6fea9a035 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 64.B0.08672.9AEF6A85; Fri, 17 Feb 2017 14:46:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0319.002; Fri, 17 Feb 2017 14:46:15 +0100 From: Christer Holmberg To: "Mirja Kuehlewind (IETF)" , Roman Shpount Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1tbXVz?= =?utf-8?Q?ic-sctp-sdp-23:_(with_DISCUSS)?= Thread-Index: AQHSiEaxS+qNKsn/A0y+WNY+OfKww6Frs1fQ///1IwCAABFeUP//8EEAgAAA4YCAAAH3gIAAE4kggAAVhACAAUmXgIAAF8fg Date: Fri, 17 Feb 2017 13:46:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C0069E5@ESESSMB209.ericsson.se> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> <55E6C40E-DF5E-4A61-8F02-D5B6E75A8D4C@kuehlewind.net> In-Reply-To: <55E6C40E-DF5E-4A61-8F02-D5B6E75A8D4C@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7iu7Kf8siDK790bd4tW4+s8WK1+fY Ld5f0LWY8Wcis8WL6x+ZLc7vXM9kMXX5YxaL6093sThweEz5vZHVY8mSn0weLR8XsnpMftzG 7LH171+2ANYoLpuU1JzMstQifbsErowFR66zF2wwqHj4sqCBcYJ+FyMHh4SAiUTr8twuRi4O IYF1jBLbZ3axdzFyAjmLGSX6ZqqA1LAJWEh0/9MGCYsIxEv82dPMDGIzC0xgkjj4LxykV1ig iVFi3eIWVhBHRKCZUeL0hgcsIM0iAnkS5w/qgDSwCKhKHH2xgA3E5hXwlVgycSbUrmmsElP6 K0BsTgEniS+tv1hBbEYBMYnvp9YwQSwTl7j1ZD6YLSEgILFkz3lmCFtU4uXjf6wQtpLEotuf mUDWMgtoSqzfpQ/RqigxpfshO8RaQYmTM5+wTGAUnYVk6iyEjllIOmYh6VjAyLKKUbQ4tbg4 N93ISC+1KDO5uDg/Ty8vtWQTIzDuDm75bbWD8eBzx0OMAhyMSjy8BfuWRgixJpYVV+YeYpTg YFYS4TV4uyxCiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/ZyvvhQgLpiSWp2ampBalFMFkmDk6p Bsa1nTtZI+b57o/vZ1SXCfs5+fviSx5tkVGXnJkVFj6vUd1yzSNqquYcJ3HnyQpyfHf2sYc6 O0w3skn0WqgVy6Hf5ff/yqNXn8ybln1dlb7z94vI3c6SZxvZFcOszFWj1Lbyis7o+fqzykYx KDfNSo/rUOKOxrMNOUHSHZtnzFl25FDlEwUTTSWW4oxEQy3mouJEAPUautq3AgAA Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , The IESG , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 13:46:22 -0000 SGksDQoNCj5SZWdhcmRpbmcgdGhlIG09IGxpbmUgKGFuZCBJ4oCZbSBieSBmYXIgbm90IGV4cGVy dCBoZXJlLCBzbyBleGN1c2UgbWUgaWYgdGhhdCBkb2Vzbid0IG1ha2Ugc2Vuc2UpLCBJIGd1ZXNz IGZvciB0aGUgSUNFIGNhc2UgeW91DQo+Y291bGQgYWxzbyBqdXN0IHVzZSBEVExTL1NDVFAsIG5v PyBXb3VsZG4ndCB0aGF0IHJlc29sdmUgdGhlIG9kZGl0eSB0aGF0IHlvdSBhbm5vdW5jZSBvbmUg dGhpbmcgYW5kIHVzZSBhbm90aGVyPyBBbmQgdGhlbiANCj55b3UgY2FuIG1heWJlIGhhdmUgYW4g YWRkaXRpb25hbCB0YWcgZm9yIHRoZSB0cmFuc3BvcnQgdXNlZCBmb3IgdGhlIG5vbi1JQ0UgY2Fz ZXPigKY/IE1haW5seSB3b25kZXJpbmcgaWYgdGhlcmUgaXMgbWF5YmUgYSBjbGVhcmVyIHNvbHV0 aW9uIGhlcmU/DQoNClRoYXQgaGFzIGJlZW4gZGlzY3Vzc2VkLCBidXQgdGhlIGRlY2lzaW9uIHdh cyB0byBub3QgZG8gaXQgd2l0aGluIHRoaXMgZHJhZnQuDQoNClRoZXJlIGhhdmUgYmVlbiBnZW5l cmljIGRpc2N1c3Npb25zIGFib3V0IGRlZmluaW5nICJJQ0UgdGFncyIuIEJ1dCwgdGhhdCB3b3Vs ZCBiZSBkb25lIGFzIGEgc2VwYXJhdGUgdGFzaywgYW5kIHdvdWxkIGNvdmVyIG90aGVyIHRyYW5z cG9ydHMgdGhhbiB0aGlzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KPiBBbSAxNi4w Mi4yMDE3IHVtIDE4OjM5IHNjaHJpZWIgUm9tYW4gU2hwb3VudCA8cnNocG91bnRAdHVyYm9icmlk Z2UuY29tPjoNCj4gDQo+IEhpIEFsbCwNCj4gDQo+IEkgdGhpbmsgYSBsaXR0bGUgYml0IG9mIGJh Y2tncm91bmQgd2lsbCBoZWxwIGhlcmUuDQo+IA0KPiBVRFAvRFRMUy9TQ1RQIGFuZCBUQ1AvRFRM Uy9TQ1RQIGFyZSBkZXNpZ25lZCB0byB3b3JrIHdpdGggSUNFIChSRkMgNTI0NSkuDQo+IA0KPiBJ biBJQ0UgZW52aXJvbm1lbnRzLCBkdXJpbmcgdGhlIG5vbWluYXRpb24gcHJvY2VzcywgZW5kIHBv aW50cyBnbyB0aHJvdWdoIG11bHRpcGxlIGNhbmRpZGF0ZSBwYWlycywgdW50aWwgdGhlIG1vc3Qg cHJlZmVycmVkIHBhaXIgaXMgZm91bmQuIER1cmluZyB0aGlzIHNlbGVjdGlvbiBwcm9jZXNzLCBk YXRhIGNhbiBiZSBzZW50IGFzIHNvb24gYXMgdGhlIGZpcnN0IHdvcmtpbmcgcGFpciBpcyBmb3Vu ZCwgYnV0IHRoZSBwcm9jZXNzIHN0aWxsIGNvbnRpbnVlcyBhbmQgY2FuZGlkYXRlIHBhaXJzIGNh biBjaGFuZ2Ugd2hpbGUgZGF0YSBpcyBzZW50LiBGdXJ0aGVybW9yZSwgaWYgZW5kIHBvaW50cyBy b2FtLCBmb3IgaW5zdGFuY2Ugd2hlbiBtb2JpbGUgZW5kIHBvaW50IHN3aXRjaGVzIGZyb20gbW9i aWxlIGludGVybmV0IHRvIHdpZmksIGVuZCBwb2ludHMgd2lsbCBpbml0aWF0ZSBhbiBJQ0UgcmVz dGFydCwgd2hpY2ggd2lsbCB0cmlnZ2VyIGEgbmV3IG5vbWluYXRpb24gcHJvY2VzcyBiZXR3ZWVu IHRoZSBuZXcgc2V0IG9mIGNhbmRpZGF0ZXMgYW5kIGxpa2VseSByZXN1bHQgaW4gbmV3IG5vbWlu YXRlZCBjYW5kaWRpYXRlIHBhaXIuIFdoZW4gdGhlc2UgY2FuZGlkYXRlcyBjaGFuZ2UsIHRoZSBz YW1lIERUTFMgYXNzb2NpYXRpb24gY29udGludWVzIHRvIHJ1biwgcmVnYXJkbGVzcyB3aGV0aGVy IGl0IGlzIHJ1bm5pbmcgb3ZlciB1ZHAgb3IgdGNwIGNhbmRpZGF0ZSBwYWlyLiBCZWNhdXNlIG9m IHRoaXMsIElDRSB0Y3AgcmVxdWlyZXMgdXNpbmcgUkZDIDQ1NzEgZnJhbWluZyB3aGVuIHNlbmRp bmcgZGF0YSAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY1NDQjc2VjdGlvbi0xMC4x KS4gT3RoZXJ3aXNlLCBpZiBUTFMgd2VyZSB1c2VkLCBhIG5ldyBUTFMgb3IgRFRMUyBzZXNzaW9u IHdvdWxkIGJlIHJlcXVpcmVkIGV2ZXJ5IHRpbWUgY2FuZGlkYXRlIHBhaXIgc3dpdGNoZXMgYmV0 d2VlbiB0Y3AgYW5kIHVkcCBjYW5kaWRhdGVzLiBJbiBvcmRlciB0byBzaW1wbGlmeSB0cmFuc2l0 aW9uIGJldHdlZW4gZGlmZmVyZW50IHVuZGVybHlpbmcgdHJhbnNwb3J0cywgRFRMUyBpcyB1c2Vk IGZvciBib3RoIHVkcCBhbmQgdGNwIGNhbmRpZGF0ZXMgYW5kIFRDUC9EVExTL1NDVFAgdHJhbnNw b3J0IHRhZyBpcyBkZWZpbmVkIHRvIGRpZmZlcmVudGlhdGUgaXQgZnJvbSBvdGhlciBwcm90b2Nv bHMuDQo+IA0KPiBBcyBmYXIgYXMgVENQL0RUTFMvU0NUUCB0cmFuc3BvcnQgdGFnIGlzIGNvbmNl cm5lZCwgcGxlYXNlIG5vdGUgdGhhdCBJQ0UgZW5kIHBvaW50cyBhcmUgc3VwcG9zZWQgdG8gc2Vu ZCBhIHJlLUlOVklURSBhZnRlciBub21pbmF0aW9uIHByb2Nlc3MgaXMgY29tcGxldGVkIHdpdGgg dGhlIHNlbGVjdGVkIGNhbmRpZGF0ZSBhZGRyZXNzIGluIHRoZSBtPSBsaW5lLiBTbywgaWYgdGNw IGNhbmRpZGF0ZSBpcyBzZWxlY3RlZCwgcmUtSU5WSVRFIG11c3QgYmUgc2VudCB3aXRoIFRDUC9E VExTL1NDVFAgdHJhbnNwb3J0IHRhZyBpbiB0aGUgbT0gbGluZS4gQWxzbywgYW55IG9mZmVycy9h bnN3ZXJzIGFmdGVyIHRoZSBJQ0Ugbm9taW5hdGlvbiBpcyBjb21wbGV0ZSwgYXJlIHN1cHBvc2Vk IHRvIHNlbmQgdGhlIGN1cnJlbnRseSBzZWxlY3RlZCBjYW5kaWRhdGUgaW4gdGhlIG09IGxpbmUs IHdoaWNoIHdpbGwgYWxzbyBiZSBUQ1AvRFRMUy9TQ1RQIGluIGNhc2UgdGNwIGNhbmRpZGF0ZSBp cyBzZWxlY3RlZC4NCj4gDQo+IEkgaG9wZSB0aGlzIGFkZHJlc3NlcyB5b3VyIGNvbmNlcm4gYW5k IGV4cGxhaW5zIHdoeSBUQ1AvRFRMUy9TQ1RQIGlzIGRlZmluZWQgaW5zdGVhZCBvZiBUTFMvU0NU UC4NCj4gDQo+IFJlZ2FyZHMsDQo+IF9fX19fX19fX19fX18NCj4gUm9tYW4gU2hwb3VudA0KPiAN Cj4gT24gVGh1LCBGZWIgMTYsIDIwMTcgYXQgMTA6MjQgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPiBIaSwNCj4gDQo+ICANCj4g DQo+IOKApg0KPiANCj4gIA0KPiANCj4gPlRoZSBvbmx5IHF1ZXN0aW9uIGlzIHdoYXQgc2hvdWxk IGFwcGVhciBpbiB0aGUgbT0gcHJvdG8gbGluZS4NCj4gDQo+ICANCj4gDQo+IEV2ZW4gaWYgbm9i b2R5IHB1dHMgaXQgaW4gdGhlIG09IGxpbmUsIEkgdGhpbmsgaXTigJlzIHVzZWZ1bCB0byBrZWVw IGl0IGluIHRoZSBkb2N1bWVudCwgYXMgaXQgZ2l2ZXMgYW4gb3ZlcnZpZXcgaG93IGl04oCZcyBy ZWFsaXplZCBldGMuDQo+IA0KPiAgDQo+IA0KPiBJdCBkb2VzbuKAmXQgY2F1c2UgYW55IGhhcm0g dG8ga2VlcCBpdCwgYW5kIGl04oCZcyDigJxmdXR1cmUgcHJvb2bigJ0gSUYgc29tZW9uZSB3YW50 cyB0byB1c2UgaXQgd2l0aG91dCBJQ0UgYXQgc29tZSBwb2ludC4NCj4gDQo+ICANCj4gDQo+IFJl Z2FyZHMsDQo+IA0KPiAgDQo+IA0KPiBDaHJpc3Rlcg0KPiANCj4gIA0KPiANCj4gDQo+ID4gQW0g MTYuMDIuMjAxNyB1bSAxNjowMiBzY2hyaWViIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT46 DQo+ID4NCj4gPiBBcyBDaHJpc3RlciBzYXlzLiBUaGlzIGRlc2lnbiBpcyBvcHRpbWl6ZWQgZm9y IG1ha2luZyB0aGUgbWVkaWEgDQo+ID4gc3RhY2sgc2ltcGxlciwgd2hpY2ggdXNpbmcgVExTIGhl cmUgd291bGQgbm90IGRvLg0KPiA+DQo+ID4gLUVrcg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4g T24gVGh1LCBGZWIgMTYsIDIwMTcgYXQgNzowMCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+ID4gSGksDQo+ID4NCj4gPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+IC0tDQo+ID4gRElTQ1VTUzoNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IC0tDQo+ ID4NCj4gPiA+Pj4gV2h5IGlzIHRoaXMgdXNpbmcgVENQL0RUTFMvU0NUUCBpbnN0ZWFkIG9mIFRD UC9UTFMvU0NUUD8NCj4gPiA+Pj4NCj4gPiA+PiBCZWNhdXNlIHRoZSB3YXkgaXQgaXMgcmVhbGl6 ZWQgaXMgYnkgdHJhbnNwb3J0aW5nIFNDVFAgb24gdG9wIG9mIA0KPiA+ID4+IERUTFMgKGFzIGRl ZmluZWQgaW4gZHJhZnQtaWV0Zi10c3Z3Zy1zY3RwLWR0bHMtZW5jYXBzKSBhbmQgdHJhbnNwb3J0 aW5nIERUTFMgb24gdG9wIG9mIFRDUCAoZGVmaW5lZCBpbiBSRkMgNDU3MSkuDQo+ID4gPg0KPiA+ ID4gSSBnb3QgdGhpcyBidXQgRFRMUyBpcyBhIG1hcHBpbmcgdG8gdXNlIFRMUyB3aXRoIFVEUCBi ZWNhdXNlIFVEUCANCj4gPiA+IGlzIGFuIHVucmVsaWFibGUgZGF0YWdyYW0gdHJhbnNwb3J0LiBJ ZiB5b3UgdXNlIFRDUCwgeW91IHNob3VsZCB1c2UgVExTLiBBbmQgcmZjNDU3MSBpcyBub3QgYSBt YXBwaW5nIG9mIERUTFMgdG8gVENQLg0KPiA+DQo+ID4gVGhlIGZyYW1pbmcgbWVjaGFuaXNtIG9m IFJGQyA0NTcxIGlzIHVzZWQsIHdpdGggRFRMUyBwYWNrZXRzIHNlbnQgaW5zdGVhZCBvZiBSVFAg cGFja2V0cy4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4NCj4gPiBDaHJpc3Rlcg0KPiA+DQo+ID4N Cj4gDQo+ICANCj4gDQo+IA0KDQo= From nobody Fri Feb 17 08:51:29 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAB91294CA for ; Fri, 17 Feb 2017 08:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 p38VuMqC2lWE for ; Fri, 17 Feb 2017 08:51:27 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBFA1289C4 for ; Fri, 17 Feb 2017 08:51:27 -0800 (PST) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-07v.sys.comcast.net with SMTP id elkWcIUoTO8EmelkkcHExk; Fri, 17 Feb 2017 16:51:26 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-09v.sys.comcast.net with SMTP id elkjc6uJRL4O1elkjcHLxn; Fri, 17 Feb 2017 16:51:26 +0000 To: Taylor Brandstetter References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Fri, 17 Feb 2017 11:51:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfJZsHlinoc+CQyTGycwR7YS8xrTUjpzR6l6x9lJnHK+VjfY+AEa3O0/1rbQLq4FQVW1Tkrv+9bpKhUsGuycYziEw3viuGFOg4hS2DO1+MJeGQDFh33Ed l9FZSTe8G7a/l4vaTsS3tcvxNrfPb9GoQzspH05KJhtlelrjV4dw6cepVwDBO+85ODN+S6c3LJtKGoHlqCPMBsKB2ZLJYHQZTeBS6lr8ZTZFkib3L2KijHxn h55PtobhnM/z5XRTXpXMVA== Archived-At: Cc: IETF MMUSIC WG , Christer Holmberg Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 16:51:28 -0000 On 2/16/17 9:27 PM, Taylor Brandstetter wrote: > So, to make this work I think it will be necessary to ammend the > definitions of the particular attributes to specify this usage. And > then future new attributes that pertain to RTP would also need to > address this. > > > sdp-mux-attributes already amends the definitions of these attributes, > such that a TRANSPORT attribute in m= section "A" can be used for media > described by m= section "B". So, I don't see why it couldn't go a step > further, and explicitly allow TRANSPORT and IDENTICAL category > attributes to appear in m= sections with proto values not normally used > with those attributes. I will reserve judgement until I see specific text. Thanks, Paul > On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat > wrote: > > On 2/16/17 12:10 PM, Christer Holmberg wrote: > > Hi Paul, > > I assume you have an opinion on this :) > > The suggestion is to allow RTP-specific parameters (SDP rtcp-mux > attributes etc) in non-RTP m= lines (e.g., data channel). > > > This is a nasty issue. > > The problem with allowing this is: what do these parameters *mean* > when so attached? And where do I look to find out? > > I'm not certain if they are currently permitted or not. AFAIK there > is no *general* mechanism for specifying with which proto values a > particular attribute may be used. I haven't studied the definitions > of the "RTP-related" attributes to see if they make a specific > statement about this. My guess is that they don't, but that they > only define the meaning in the context of an RTP session. > > If that is so, perhaps the rule that unknown attributes are to be > ignored should apply to those attributes when used with a non-RTP > media section. But if that rule were to apply, then we would expect > that with O/A the rules for how these attributes in an offer affect > what goes in the answer would not apply. I guess that won't be > sufficient here. > > So, to make this work I think it will be necessary to ammend the > definitions of the particular attributes to specify this usage. And > then future new attributes that pertain to RTP would also need to > address this. > > IMO this is a can of worms. So my opinion is that these should *not* > be used with non-RTP m-lines, with or without bundle. > > Note that data channel is a special case. While we have agreed not > to consider it for now, it is possible, in principle, to run RTP > over a data channel. If that were defined then these attributes > would also be needed. But then they would not be used as media-level > attributes. Instead, they would be dcsa attributes. > > Thanks, > Paul > > *From:*mmusic [mailto:mmusic-bounces@ietf.org > ] *On Behalf Of *Christer > Holmberg > *Sent:* 16 February 2017 19:07 > *To:* Eric Rescorla >; mmusic > WG > > *Subject:* Re: [MMUSIC] Issue #27: Allow RTP attributes in > non-media m= > sections > > > > Hi, > > * * > > *>*See: > > https://github.com/cdh4u/draft-sdp-bundle/issues/27 > > > > https://github.com/rtcweb-wg/jsep/issues/528 > > > > > > The basic issue is that it's possible to have a situation > where you > > have both > > media and data m= sections but the BUNDLE tag is associated > with the data > > > m= section and now you need to put the TRANSPORT and IDENTICAL > > > attributes somewhere. The JSEP editors discussed this and > came to the > > > conclusion that it should go with the BUNDLE tag (i.e., in > the data m= > > section) > > and that BUNDLE should forbid this, but it requires a change > to BUNDLE. > > > > > Did you mean to say that BUNDLE should NOT forbid this? > > > > Based on your GitHub discussion, my understanding is that you > want to > allow to include RTP-specific parameters (‘rtcp-mux’, ‘rtcp’, > ‘rtcp-mux-only’ attributes etc) in the data m= section. > > > > To repeat what I said on GitHub: > > > > This has been discussed in the past, and the outcome has been to now > allow RTP-specific parameters in non-RTP m= sections. > > > > A solution would be to simply change the bundle tag when the RTP m= > sections are added. > > > > …OR, we change the mux category for the RTP-specific parameters. > But, > that of course means they have to be added to every RTP m= section. > > > > Regards, > > > > Christer > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > From nobody Fri Feb 17 09:04:55 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3351294C1 for ; Fri, 17 Feb 2017 09:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3gT7TTOC5Ad for ; Fri, 17 Feb 2017 09:04:51 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B008B127601 for ; Fri, 17 Feb 2017 09:04:51 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-05v.sys.comcast.net with SMTP id elxCcUtwUy20uelxjcAfPj; Fri, 17 Feb 2017 17:04:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1487351091; bh=cBSmud9hA+wpTRGrnBbFHvr4vlvAfCi8nfghuDk+p8o=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=kgMY14Ams9Nbouzq9wfJhJEOZZK1tFtD0dHnp8TwY//lD3+VnkONaEKynab16Hlt+ 8CzHV0TzQB3jy5oznceNI7cjSdnIdvGL2oZdh8Nt7E+l4tcj6OALuDt1cnbYbwrR1n d2oWM/1uQ/T8RUL1lSfqtShJ8WMlBAII4OTciXp2H75JxXXvFAyTgIcjEnS4RAD960 1E6d6k4G1NM8eZ+NqZr4VYKYAdt7K8Z/COkVw3eMW0FfByU1W8xgGgOOJAUciNSOAy rFJ9Tr24t3BHBXi2vOSJG6akwfRil0aG8Z+8dclZzNuBGOiM6m/9owI6Lr10aBm1tx n7lvauDHPRYXg== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-14v.sys.comcast.net with SMTP id elxicaBwxqUWeelxic7KEP; Fri, 17 Feb 2017 17:04:51 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4C005232@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <405b8725-7173-19f2-58a4-ebae6cbd7814@comcast.net> Date: Fri, 17 Feb 2017 12:04:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4C005232@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfIp6tWkLK/CrXCstTIR3DQ0bDct/6rcpd+vpWewz8bWOFfh9UMwJ56WDU6uCJySLF8zDKTlqHOEfALRD8iHPTNw1Xf/JjblUeGAGzUSoia5X8mGqT3ZE V/+fJnJug4Gt1OBlK5Miy2BjLSbMqXUMGnfZ4a+5zm4auYCkLiIdzWagRZPOHdkuFkJt/R95M7L4Hg== Archived-At: Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 17:04:53 -0000 On 2/17/17 3:46 AM, Christer Holmberg wrote: > Hi, > > Based on the comments from Ekr, I've submitted a new version of draft-mux-exclusive. > > The SDP 'rtcp-mux-only' attribute is now only allowed in SDP offers. With the new text the offerer never knows if the answerer supports rtcp-mux-only. He only knows that the answerer supports rtcp-mux. I don't think this matters for that O/A, but it might matter for subsequent O/As. At the least, I think section 4.5 is now confusing. For m-lines previously negotiated with rtcp-mux-only, must the side that is sending a new offer include the attribute again, while the side that is answering must *not* include it? (Note the implications when the new offer is in the opposite direction from the original one.) I think this will be somewhat of a pain - perhaps more pain than simply always including it in all offers and answers. Thanks, Paul > Regards, > > Christer > > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: 17 February 2017 10:44 > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-11.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia Session Control of the IETF. > > Title : Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP > Author : Christer Holmberg > Filename : draft-ietf-mmusic-mux-exclusive-11.txt > Pages : 12 > Date : 2017-02-17 > > Abstract: > This document defines a new SDP media-level attribute, 'rtcp-mux- > only', that can be used by an endpoint to indicate exclusive support > of RTP/RTCP multiplexing. The document also updates RFC 5761, by > clarifying that an offerer can use a mechanism to indicate that it is > not able to send and receive RTCP on separate ports. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-mux-exclusive-11 > > > 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/ > > _______________________________________________ > 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 Fri Feb 17 09:55:28 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D7A129AC5 for ; Fri, 17 Feb 2017 09:55:27 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 YX3cyaoe_grS for ; Fri, 17 Feb 2017 09:55:25 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846A212955C for ; Fri, 17 Feb 2017 09:55:25 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v1HHtJ0n069389 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 17 Feb 2017 11:55:20 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Christer Holmberg" Date: Fri, 17 Feb 2017 11:55:19 -0600 Message-ID: <18C350AD-9C5B-4723-B934-4E27DD86FB6B@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4C0046CD@ESESSMB209.ericsson.se> References: <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4C004589@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C00464B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0046CD@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 17:55:28 -0000 Hi, While it's the chairs' prerogative to judge consensus, it seems to me that the discussion has been somewhere between "we do need TCP/DTLS/SCTP" and "we might need it". Since the draft has already been approved by the IESG, we shouldn't make a material change unless we have a really good reason. I propose leaving it in. One more comment inline: On 16 Feb 2017, at 11:54, Christer Holmberg wrote: > Hi, > >> Once nomination process is completed, it should be the selected, not >> the default >candidate. >> >> When session is established or during ICE restart, multiple >> candidates are sent >in offer/answer and DEFAULT candidate must be >> used in the m= line. >> >> Once nomination process is completed, only the currently selected >> candidate is >sent in offer/answer and this would be the candidate in >> the m= line. Resources >associated with other candidates, such as >> network ports or TURN allocations, >are typically released at that >> point, so there is no point to include them any >more. > > Well, then we need to clarify the text (or remove the text completely, > and simply refer to the ICE spec), because the ICE considerations > section talks about offers and answers in general. To be clear, are you talking about clarifying text in _this_ draft, or elsewhere? Thanks! Ben. > > Regards, > > Christer > > > > On Thu, Feb 16, 2017 at 12:40 PM, Christer Holmberg > > > wrote: > Hi, > > It’s not only the re-INVITE, it’s ANY subsequent offer sent during > the session. > > However, I think we changed that part. The draft now says that when > sending an offer or answer, the m- line proto value must reflect the > DEFAULT candidiate. > > Regards, > > Christer > > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: 16 February 2017 19:38 > To: Roman Shpount > > Cc: Christer Holmberg > >; > Ben Campbell >; mmusic WG > > > > Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? > > I also think the re-INVITE is unnecessary. > > -Ekr > > On Thu, Feb 16, 2017 at 9:16 AM, Roman Shpount > > wrote: > The way ICE is currently defined, ICE enabled end points are supposed > to send a re-INVITE after nomination process is completed with the > selected candidate address in the m= line. So, if tcp candidate is > selected, re-INVITE must be sent with TCP/DTLS/SCTP in the m= line. > Also, any offers/answers after the ICE nomination is complete, are > supposed to send the currently selected candidate in the m= line, > which will also be TCP/DTLS/SCTP in case tcp candidate is selected. > > Based on all of this, I would strongly suggest to keep TCP/DTLS/SCTP. > > Regards, > > _____________ > Roman Shpount > > On Thu, Feb 16, 2017 at 11:55 AM, Christer Holmberg > > > wrote: > Hi, > > My suggestion is to keep the TCP/DTLS/SCTP definition. > > We earlier made a choice to restrict the scope of the document (by > removing plain SCTP and DTLS-over-SCTP proto values), and I think we > should keep the current scope. > > Regards, > > Christer > > > From: mmusic > [mailto:mmusic-bounces@ietf.org] On > Behalf Of Ben Campbell > Sent: 16 February 2017 17:52 > To: Eric Rescorla > > Cc: mmusic WG > > Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? > > > Process background: draft-ietf-mmusic-sctp-sdp was on today's IESG > telechat. The draft is approved for publication, but with a point > raised to ask the WG resolve Ekr's question. > > Thanks! > > Ben. > > On 16 Feb 2017, at 9:43, Eric Rescorla wrote: > I raised this with the authors, but maybe it is worth asking the > mailing list. > > It seems like we are trending towards a world where we just ignore the > transport > component of the proto field and let ICE work things out. In that > vein, I wonder > do we really need to register/define TCP/DTLS/SCTP. It's only really > useful if > we think people will do SCTP over DTLS with TCP without ICE. Is that > actually > likely. I note that per previous discussions, JSEP already requires > that you use > UDP/DTLS/SCTP all the time: > http://rtcweb-wg.github.io/jsep/#rfc.section.5.1.2 > > -Ekr > > > _______________________________________________ > 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 Fri Feb 17 10:10:20 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D431296D7 for ; Fri, 17 Feb 2017 10:10:15 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uM0BqD-Ygol for ; Fri, 17 Feb 2017 10:10:14 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D633812955C for ; Fri, 17 Feb 2017 10:10:13 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id 203so30595066ith.0 for ; Fri, 17 Feb 2017 10:10:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UblC0VOdQ8wqnO2jrzqqSpfumP0KXdPXQw8j2w89In0=; b=peXrC74fu5XqiYFZvP5b7pdYDVUT9TcnmBcuPK1cq0eAeRUNFwx7kWFSxHvbo1U8rR IbBupdNyggB9nUmg/6eTTzD4fImZlujOCj4ucCGJyF4Gj4rS+ocrzlqezWnlN3IYcC4y Uleh39IK+zjcLgBDE2vCMW+iWH0aWculJrx8xP06m7p/FvqVS9t+X9UPUltvV8xV/NEu BQKJphfr6hOzyht3Lu1MNLFm93Qm0/Ro5kwvcLUkv01Fh1iLC1TADHrv+5ZHzMIixxP0 JyoAROFEI6Amib6WRf5yYVwlDJm2qe2qetHufBGJYw7k3RnwMHos4tAXqc1lTvKULEUq +P1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UblC0VOdQ8wqnO2jrzqqSpfumP0KXdPXQw8j2w89In0=; b=srub/l6l0aw4um54BLx+ORLk5cPr/OrHaptHXMc0dm6J4TDakctG2vhpkrnWPnoox1 30BWFXt/SRSv/75BefZVSNGFAE7isTb+B2duvRpxWE+AfouFuaJzXAYFXXKZzN02TNiR wGm7ota3C9IhIHonfADbDUYUuyEiKDDMAOw8qkAvWM3u/vrjkaKdI9EattgSG5e8gUAI QGQal8J+JEsxftANak78kulfBPfDw/DOQDKqOCV/XWkK4FjNK1NM6/CRafpanetqeh69 Qz+qHwnTVJtBsVP9Jum9KUOfNeZvqmr75VLiFGWcuzRGKi2+HYQTReMb0auUYkOJ9hJd SbBg== X-Gm-Message-State: AMke39klNfDW+ZvyYm2lot6iwJy4YxrYgJ7W5D7NgCiw90YqDKZpU8pCEfrcIkuyqVmYNw== X-Received: by 10.107.5.137 with SMTP id 131mr8612632iof.87.1487355013099; Fri, 17 Feb 2017 10:10:13 -0800 (PST) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com. [209.85.214.42]) by smtp.gmail.com with ESMTPSA id m198sm870357itg.1.2017.02.17.10.10.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 10:10:12 -0800 (PST) Received: by mail-it0-f42.google.com with SMTP id g67so23544706itb.1 for ; Fri, 17 Feb 2017 10:10:12 -0800 (PST) X-Received: by 10.36.76.205 with SMTP id a196mr3358894itb.52.1487355012254; Fri, 17 Feb 2017 10:10:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.233.3 with HTTP; Fri, 17 Feb 2017 10:10:11 -0800 (PST) In-Reply-To: <405b8725-7173-19f2-58a4-ebae6cbd7814@comcast.net> References: <7594FB04B1934943A5C02806D1A2204B4C005232@ESESSMB209.ericsson.se> <405b8725-7173-19f2-58a4-ebae6cbd7814@comcast.net> From: Roman Shpount Date: Fri, 17 Feb 2017 13:10:11 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11431eb62918d30548bdd306 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 18:10:15 -0000 --001a11431eb62918d30548bdd306 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 17, 2017 at 12:04 PM, Paul Kyzivat wrote: > On 2/17/17 3:46 AM, Christer Holmberg wrote: > >> Hi, >> >> Based on the comments from Ekr, I've submitted a new version of >> draft-mux-exclusive. >> >> The SDP 'rtcp-mux-only' attribute is now only allowed in SDP offers. >> > > With the new text the offerer never knows if the answerer supports > rtcp-mux-only. He only knows that the answerer supports rtcp-mux. > > I don't think this matters for that O/A, but it might matter for > subsequent O/As. > > At the least, I think section 4.5 is now confusing. For m-lines previously > negotiated with rtcp-mux-only, must the side that is sending a new offer > include the attribute again, while the side that is answering must *not* > include it? (Note the implications when the new offer is in the opposite > direction from the original one.) I think this will be somewhat of a pain - > perhaps more pain than simply always including it in all offers and answers. > Based comments from Ekr, the offerer never cares if the answerer supports rtcp-mux-only. It only cares that answerer supports rtcp-mux. The whole purpose of rtcp-mux-only attribute is to promise to all the parties on the signaling path, such as SBC, that offerer will not accept an answer without rtcp-mux. Based on this promise SBC does not need to allocate an RTCP port for the duration of offer transaction. There is no difference here between the initial offer and offers in session updates -- in either case without rtcp-mux-only attribute SBC would need to allocate an extra port during the session update transaction. So, it does not matter what was negotiated before in the session, every offer in every direction must include rctp-mux-only if offerer is not willing to accept the answer without rtcp-mux, and should not include rtcp-mux-only if offerer allocated the RTCP port and is willing to accept an answer without mux. It makes no sense to include rtcp-mux-only in the answer, since if it includes rtcp-mux attribute, it is enough of the indication that RTP and RTCP are muxed and no extra port is needed. Regards, _____________ Roman Shpount --001a11431eb62918d30548bdd306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 17, 2017 at 12:04 PM, Paul Kyzivat <paul.kyzivat@comcast.ne= t> wrote:
On 2/17/17 3:46 AM, Christer Holmberg wrote:
Hi,

Based on the comments from Ekr, I've submitted a new version of draft-m= ux-exclusive.

The SDP 'rtcp-mux-only' attribute is now only allowed in SDP offers= .

With the new text the offerer never knows if the answerer supports rtcp-mux= -only. He only knows that the answerer supports rtcp-mux.

I don't think this matters for that O/A, but it might matter for subseq= uent O/As.

At the least, I think section 4.5 is now confusing. For m-lines previously = negotiated with rtcp-mux-only, must the side that is sending a new offer in= clude the attribute again, while the side that is answering must *not* incl= ude it? (Note the implications when the new offer is in the opposite direct= ion from the original one.) I think this will be somewhat of a pain - perha= ps more pain than simply always including it in all offers and answers.
=

Based comments from Ekr, the offerer never= cares if the answerer supports rtcp-mux-only. It only cares that answerer = supports rtcp-mux. The whole purpose of rtcp-mux-only attribute is to promi= se to all the parties on the signaling path, such as SBC, that offerer will= not accept an answer without rtcp-mux. Based on this promise SBC does not = need to allocate an RTCP port for the duration of offer transaction. There = is no difference here between the initial offer and offers in session updat= es -- in either case without rtcp-mux-only attribute SBC would need to allo= cate an extra port during the session update transaction. So, it does not m= atter what was negotiated before in the session, every offer in every direc= tion must include rctp-mux-only if offerer is not willing to accept the ans= wer without rtcp-mux, and should not include rtcp-mux-only if offerer alloc= ated the RTCP port and is willing to accept an answer without mux. It makes= no sense to include rtcp-mux-only in the answer, since if it includes rtcp= -mux attribute, it is enough of the indication that RTP and RTCP are muxed = and no extra port is needed.

Regards,
_____________
Roman Shpount
=C2=A0
--001a11431eb62918d30548bdd306-- From nobody Fri Feb 17 10:26:53 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D68129B10 for ; Fri, 17 Feb 2017 10:26:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrIud2NamyIZ for ; Fri, 17 Feb 2017 10:26:50 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5CD4129686 for ; Fri, 17 Feb 2017 10:26:49 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id g67so24020416itb.1 for ; Fri, 17 Feb 2017 10:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lxcT2mCIZOMj5QSi8bw5WtgrcHbasyZGchEZLbOv4j0=; b=MamI6m++tt/VEtNE+lTL+sVCS4RfNFzHcteZsu+Gld4Q4rt4T4YegHizrfQrIYG8uT /8GjIpSC8htb9APaqWnqXLm9wIa9ihyeoGCgUNnJtTGtWBjLEFHUUJrrHMS96Bvlv2B9 b8XehGPFDJaudTvIDu0maofghIz1TlmVKYc39OVlqMFNNvD4NkfcLFB9ruzB0il1K70G eoFqhv5ePUDfzBJ6MYM9KWqhHoFbBY996Zgvo167qWmw4HJJKCkEivgkijQ+IQWXVBDW jGrgCzwQUhXc/XHs8gCzhSHJx/YVgimPPh1UcbVKqiWxx8g81v+DRnt+8PhDuu6Lf2V2 uWcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lxcT2mCIZOMj5QSi8bw5WtgrcHbasyZGchEZLbOv4j0=; b=hSAbgtaaqpLxt7oV0LXh5HrtZLBZ1nnpcQzGbrWtRJQdbyt0RNsw7SgtsLEUbLsDD7 H6Wlotd5QSOxvgZLctteuUzsdr2N3qGXVVntBcMR9vsONhcuBh/nwp357IJFP9sVQ5j1 23VX9vJWQaA8ha2eRKVSX/8IJ78ONw0c0atlgyv65oYjqa6T2TqF3qcmTZ4Oy5+WJeoE FBVFNZQpuNIxt2bJh8XPXyTt2Y08iJVked9BuxoY/tH6zOgk/3VWs2xxJqRV28+WJGq9 0hUD3bntwBBq6XZs90Ldfj/Wi4DsdL64kwG5gk90fHSYpDbAN0YxNKwt6EcK6DzEX4La 8s1A== X-Gm-Message-State: AMke39kcPTzxfXDgm/bSnV9Haxe54w5BkTfXO5YSI1xYplJ1NOJ3C33db85T29Z+CE8cTw== X-Received: by 10.107.57.198 with SMTP id g189mr3326477ioa.123.1487356009029; Fri, 17 Feb 2017 10:26:49 -0800 (PST) Received: from mail-it0-f53.google.com (mail-it0-f53.google.com. [209.85.214.53]) by smtp.gmail.com with ESMTPSA id j4sm875573ita.29.2017.02.17.10.26.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 10:26:48 -0800 (PST) Received: by mail-it0-f53.google.com with SMTP id h10so28993196ith.1 for ; Fri, 17 Feb 2017 10:26:48 -0800 (PST) X-Received: by 10.107.46.231 with SMTP id u100mr8868394iou.8.1487356007752; Fri, 17 Feb 2017 10:26:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.233.3 with HTTP; Fri, 17 Feb 2017 10:26:47 -0800 (PST) In-Reply-To: <18C350AD-9C5B-4723-B934-4E27DD86FB6B@nostrum.com> References: <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4C004589@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C00464B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0046CD@ESESSMB209.ericsson.se> <18C350AD-9C5B-4723-B934-4E27DD86FB6B@nostrum.com> From: Roman Shpount Date: Fri, 17 Feb 2017 13:26:47 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=001a113524927f5a7d0548be0eb8 Archived-At: Cc: mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 18:26:51 -0000 --001a113524927f5a7d0548be0eb8 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 17, 2017 at 12:55 PM, Ben Campbell wrote: > While it's the chairs' prerogative to judge consensus, it seems to me that > the discussion has been somewhere between "we do need TCP/DTLS/SCTP" and > "we might need it". Since the draft has already been approved by the IESG, > we shouldn't make a material change unless we have a really good reason. I > propose leaving it in. > As you have probably noticed I am strongly for leaving TCP/DTLS/SCTP in the draft, since things will break otherwise and draft will require substantial editing to recover. > On 16 Feb 2017, at 11:54, Christer Holmberg wrote: > > Once nomination process is completed, it should be the selected, not the >>> default >candidate. >>> >>> When session is established or during ICE restart, multiple candidates >>> are sent >in offer/answer and DEFAULT candidate must be used in the m= line. >>> >>> Once nomination process is completed, only the currently selected >>> candidate is >sent in offer/answer and this would be the candidate in the >>> m= line. Resources >associated with other candidates, such as network ports >>> or TURN allocations, >are typically released at that point, so there is no >>> point to include them any >more. >>> >> >> Well, then we need to clarify the text (or remove the text completely, >> and simply refer to the ICE spec), because the ICE considerations section >> talks about offers and answers in general. >> > > To be clear, are you talking about clarifying text in _this_ draft, or > elsewhere? > > Christer is talking about section 12.2 of the draft-ietf-mmusic-sctp-sdp. As the language stands right now, it is not incorrect, but is slightly confusing, since it is talking about default candidates for all ICE related offer/answer exchanges. After ICE nomination process is completed, there is only one candidate left, so there is no default. In session descriptions that describe the session after ICE nomination is complete only one candidate is present, so there is typically no confusion about what goes into the m= line, but this is not spelled out in the draft. I will submit the PR and Christer can merge and resubmit the draft when he is back. Regards, _____________ Roman Shpount --001a113524927f5a7d0548be0eb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 17, 2017 at 12:55 PM, Ben Campbell <<= a href=3D"mailto:ben@nostrum.com" target=3D"_blank">ben@nostrum.com>= wrote:
While it's the chairs' prerogative= to judge consensus, it seems to me that the discussion has been somewhere = between "we do need TCP/DTLS/SCTP" and "we might need it&quo= t;. Since the draft has already been approved by the IESG, we shouldn't= make a material change unless we have a really good reason. I propose leav= ing it in.

As you have probably noticed= I am strongly for leaving TCP/DTLS/SCTP in the draft, since things will br= eak otherwise and draft will require substantial editing to recover.
<= div>=C2=A0
On 16 Feb 2017, at 11:54, Christer Holmberg wrote:

Once nomination process is completed, it should be= the selected, not the default >candidate.

When session is established or during ICE restart, multiple candidates are = sent >in offer/answer and DEFAULT candidate must be used in the m=3D lin= e.

Once nomination process is completed, only the currently selected candidate= is >sent in offer/answer and this would be the candidate in the m=3D li= ne. Resources >associated with other candidates, such as network ports o= r TURN allocations, >are typically released at that point, so there is n= o point to include them any >more.

Well, then we need to clarify the text (or remove the text completely, and = simply refer to the ICE spec), because the ICE considerations section talks= about offers and answers in general.

 To be clear, are you talking about clarifying text in _this_ draft, or else= where?


Christer is talking about section 12.2= of the draft-ietf-mmusic-sctp-sdp. As the language stands right now, it is= not incorrect, but is slightly confusing, since it is talking about defaul= t candidates for all ICE related offer/answer exchanges.=C2=A0 After ICE no= mination process is completed, there is only one candidate left, so there i= s no default. In session descriptions that describe the session after ICE n= omination is complete only one candidate is present, so there is typically = no confusion about what goes into the m=3D line, but this is not spelled ou= t in the draft. I will submit the PR and Christer can merge and resubmit th= e draft when he is back.

Regards,
_____________
Roman Shpount

=C2=A0
--001a113524927f5a7d0548be0eb8-- From nobody Sat Feb 18 01:29:25 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032971294EE for ; Sat, 18 Feb 2017 01:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 C0HbfQD8t-ib for ; Sat, 18 Feb 2017 01:29:22 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414641294D3 for ; Sat, 18 Feb 2017 01:29:22 -0800 (PST) X-AuditID: c1b4fb25-55bff70000001738-33-58a813eef5a3 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 82.30.05944.EE318A85; Sat, 18 Feb 2017 10:29:20 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0319.002; Sat, 18 Feb 2017 10:29:17 +0100 From: Christer Holmberg To: Roman Shpount , Ben Campbell Thread-Topic: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? Thread-Index: AQHSiGuZ0ghkIgIFz0iRXtxKyN1pOqFrt7kAgAAhoiD///XmgIAABf+AgAARKfD///H8AIAAEY/QgAGCcoCAAAjKgIABC/zw Date: Sat, 18 Feb 2017 09:29:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C0075FD@ESESSMB209.ericsson.se> References: <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4C004589@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C00464B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0046CD@ESESSMB209.ericsson.se> <18C350AD-9C5B-4723-B934-4E27DD86FB6B@nostrum.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.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4C0075FDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7me4H4RURBhM6hS3md55mt5i6/DGL xYwLU5kdmD2WLPnJ5DFr5xMWj1tTCgKYo7hsUlJzMstSi/TtErgyDp3YxV7worji07lzbA2M Nwq6GDk5JARMJOY2djGC2EIC6xglpp2V6GLkArIXM0pcX7CHqYuRg4NNwEKi+582SI2IgKtE 1/fpYPXMAvISF5asYQKxhQWcJN68v8oKUeMsce5GEyOEnScxd8VfdhCbRUBV4srGl2A2r4Cv xP07D9ghdi1ilTi3bTozyC5OgUCJOR/iQWoYBcQkvp+CmM8sIC5x68l8JoibBSSW7DnPDGGL Srx8/I8VwlaSWLH9EtRt+RK7uvdB7RKUODnzCcsERpFZSEbNQlI2C0nZLKArmAU0Jdbv0oco UZSY0v2QHcLWkGidM5cdWXwBI/sqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMAoO7jlt+oO xstvHA8xCnAwKvHwfuBfHiHEmlhWXJl7iFGCg1lJhHeCwIoIId6UxMqq1KL8+KLSnNTiQ4zS HCxK4rxmK++HCwmkJ5akZqemFqQWwWSZODilGhjbdc+rnluZLfW3tThWW1RUqtz9UT1XjYDS 7/W/Nv06LVY+oZbtQa/50m93WHPOBnBVtq/0LdK8Zau3696jj5F8qndZJjeaL/H6ffxUwzJO /cvynlfcjN+4OKVn1c1uVM4rTW7YvVXuWMBO/uNedYUtv545XHpT9OhTdo7WtJ0Rc/reJy3x 01JiKc5INNRiLipOBAB+7Y4ArgIAAA== Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 09:29:24 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4C0075FDESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYWdyZWUgd2l0aCBCZW4gYW5kIFJvbWFuLg0KDQooQWxzbywgbm90IHRvbyBsb25n IGFnbyB3ZSBkaWQgZGlzY3VzcyB3aGF0IGlzIHJlbW92ZWQgYW5kIHdoYXQgaXMga2VwdCBpbiwg YW5kIHRoZSBkcmFmdCByZWZsZWN0cyB0aGF0IGRpc2N1c3Npb24uKQ0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQpGcm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21d DQpTZW50OiAxNyBGZWJydWFyeSAyMDE3IDIwOjI3DQpUbzogQmVuIENhbXBiZWxsIDxiZW5Abm9z dHJ1bS5jb20+DQpDYzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT47IG1tdXNpYyBXRyA8bW11c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTVVT SUNdIERvIHdlIHJlYWxseSBuZWVkIFRDUC9EVExTL1NDVFAgcHJvdG8gZmllbGQ/DQoNCk9uIEZy aSwgRmViIDE3LCAyMDE3IGF0IDEyOjU1IFBNLCBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNv bTxtYWlsdG86YmVuQG5vc3RydW0uY29tPj4gd3JvdGU6DQpXaGlsZSBpdCdzIHRoZSBjaGFpcnMn IHByZXJvZ2F0aXZlIHRvIGp1ZGdlIGNvbnNlbnN1cywgaXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUg ZGlzY3Vzc2lvbiBoYXMgYmVlbiBzb21ld2hlcmUgYmV0d2VlbiAid2UgZG8gbmVlZCBUQ1AvRFRM Uy9TQ1RQIiBhbmQgIndlIG1pZ2h0IG5lZWQgaXQiLiBTaW5jZSB0aGUgZHJhZnQgaGFzIGFscmVh ZHkgYmVlbiBhcHByb3ZlZCBieSB0aGUgSUVTRywgd2Ugc2hvdWxkbid0IG1ha2UgYSBtYXRlcmlh bCBjaGFuZ2UgdW5sZXNzIHdlIGhhdmUgYSByZWFsbHkgZ29vZCByZWFzb24uIEkgcHJvcG9zZSBs ZWF2aW5nIGl0IGluLg0KDQpBcyB5b3UgaGF2ZSBwcm9iYWJseSBub3RpY2VkIEkgYW0gc3Ryb25n bHkgZm9yIGxlYXZpbmcgVENQL0RUTFMvU0NUUCBpbiB0aGUgZHJhZnQsIHNpbmNlIHRoaW5ncyB3 aWxsIGJyZWFrIG90aGVyd2lzZSBhbmQgZHJhZnQgd2lsbCByZXF1aXJlIHN1YnN0YW50aWFsIGVk aXRpbmcgdG8gcmVjb3Zlci4NCg0KT24gMTYgRmViIDIwMTcsIGF0IDExOjU0LCBDaHJpc3RlciBI b2xtYmVyZyB3cm90ZToNCk9uY2Ugbm9taW5hdGlvbiBwcm9jZXNzIGlzIGNvbXBsZXRlZCwgaXQg c2hvdWxkIGJlIHRoZSBzZWxlY3RlZCwgbm90IHRoZSBkZWZhdWx0ID5jYW5kaWRhdGUuDQoNCldo ZW4gc2Vzc2lvbiBpcyBlc3RhYmxpc2hlZCBvciBkdXJpbmcgSUNFIHJlc3RhcnQsIG11bHRpcGxl IGNhbmRpZGF0ZXMgYXJlIHNlbnQgPmluIG9mZmVyL2Fuc3dlciBhbmQgREVGQVVMVCBjYW5kaWRh dGUgbXVzdCBiZSB1c2VkIGluIHRoZSBtPSBsaW5lLg0KDQpPbmNlIG5vbWluYXRpb24gcHJvY2Vz cyBpcyBjb21wbGV0ZWQsIG9ubHkgdGhlIGN1cnJlbnRseSBzZWxlY3RlZCBjYW5kaWRhdGUgaXMg PnNlbnQgaW4gb2ZmZXIvYW5zd2VyIGFuZCB0aGlzIHdvdWxkIGJlIHRoZSBjYW5kaWRhdGUgaW4g dGhlIG09IGxpbmUuIFJlc291cmNlcyA+YXNzb2NpYXRlZCB3aXRoIG90aGVyIGNhbmRpZGF0ZXMs IHN1Y2ggYXMgbmV0d29yayBwb3J0cyBvciBUVVJOIGFsbG9jYXRpb25zLCA+YXJlIHR5cGljYWxs eSByZWxlYXNlZCBhdCB0aGF0IHBvaW50LCBzbyB0aGVyZSBpcyBubyBwb2ludCB0byBpbmNsdWRl IHRoZW0gYW55ID5tb3JlLg0KDQpXZWxsLCB0aGVuIHdlIG5lZWQgdG8gY2xhcmlmeSB0aGUgdGV4 dCAob3IgcmVtb3ZlIHRoZSB0ZXh0IGNvbXBsZXRlbHksIGFuZCBzaW1wbHkgcmVmZXIgdG8gdGhl IElDRSBzcGVjKSwgYmVjYXVzZSB0aGUgSUNFIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gdGFsa3Mg YWJvdXQgb2ZmZXJzIGFuZCBhbnN3ZXJzIGluIGdlbmVyYWwuDQoNClRvIGJlIGNsZWFyLCBhcmUg eW91IHRhbGtpbmcgYWJvdXQgY2xhcmlmeWluZyB0ZXh0IGluIF90aGlzXyBkcmFmdCwgb3IgZWxz ZXdoZXJlPw0KDQpDaHJpc3RlciBpcyB0YWxraW5nIGFib3V0IHNlY3Rpb24gMTIuMiBvZiB0aGUg ZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHAuIEFzIHRoZSBsYW5ndWFnZSBzdGFuZHMgcmlnaHQg bm93LCBpdCBpcyBub3QgaW5jb3JyZWN0LCBidXQgaXMgc2xpZ2h0bHkgY29uZnVzaW5nLCBzaW5j ZSBpdCBpcyB0YWxraW5nIGFib3V0IGRlZmF1bHQgY2FuZGlkYXRlcyBmb3IgYWxsIElDRSByZWxh dGVkIG9mZmVyL2Fuc3dlciBleGNoYW5nZXMuICBBZnRlciBJQ0Ugbm9taW5hdGlvbiBwcm9jZXNz IGlzIGNvbXBsZXRlZCwgdGhlcmUgaXMgb25seSBvbmUgY2FuZGlkYXRlIGxlZnQsIHNvIHRoZXJl IGlzIG5vIGRlZmF1bHQuIEluIHNlc3Npb24gZGVzY3JpcHRpb25zIHRoYXQgZGVzY3JpYmUgdGhl IHNlc3Npb24gYWZ0ZXIgSUNFIG5vbWluYXRpb24gaXMgY29tcGxldGUgb25seSBvbmUgY2FuZGlk YXRlIGlzIHByZXNlbnQsIHNvIHRoZXJlIGlzIHR5cGljYWxseSBubyBjb25mdXNpb24gYWJvdXQg d2hhdCBnb2VzIGludG8gdGhlIG09IGxpbmUsIGJ1dCB0aGlzIGlzIG5vdCBzcGVsbGVkIG91dCBp biB0aGUgZHJhZnQuIEkgd2lsbCBzdWJtaXQgdGhlIFBSIGFuZCBDaHJpc3RlciBjYW4gbWVyZ2Ug YW5kIHJlc3VibWl0IHRoZSBkcmFmdCB3aGVuIGhlIGlzIGJhY2suDQoNClJlZ2FyZHMsDQpfX19f X19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B4C0075FDESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmdtYWlsLQ0KCXttc28t c3R5bGUtbmFtZTpnbWFpbC07fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5JIGFncmVlIHdpdGggQmVuIGFuZCBSb21hbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+KEFsc28sIG5vdCB0b28gbG9uZyBhZ28gd2UgZGlkIGRpc2N1 c3Mgd2hhdCBpcyByZW1vdmVkIGFuZCB3aGF0IGlzIGtlcHQgaW4sIGFuZCB0aGUgZHJhZnQgcmVm bGVjdHMgdGhhdCBkaXNjdXNzaW9uLikNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg bmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9tYW4gU2hwb3Vu dCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE3IEZlYnJ1 YXJ5IDIwMTcgMjA6Mjc8YnI+DQo8Yj5Ubzo8L2I+IEJlbiBDYW1wYmVsbCAmbHQ7YmVuQG5vc3Ry dW0uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs7IG1tdXNpYyBXRyAmbHQ7bW11c2ljQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gRG8gd2UgcmVhbGx5IG5lZWQg VENQL0RUTFMvU0NUUCBwcm90byBmaWVsZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEZlYiAxNywgMjAxNyBhdCAxMjo1 NSBQTSwgQmVuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmVuQG5vc3RydW0uY29tIiB0 YXJnZXQ9Il9ibGFuayI+YmVuQG5vc3RydW0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5XaGlsZSBpdCdzIHRoZSBjaGFpcnMnIHByZXJvZ2F0aXZlIHRvIGp1ZGdlIGNvbnNlbnN1 cywgaXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgZGlzY3Vzc2lvbiBoYXMgYmVlbiBzb21ld2hlcmUg YmV0d2VlbiAmcXVvdDt3ZSBkbyBuZWVkIFRDUC9EVExTL1NDVFAmcXVvdDsgYW5kICZxdW90O3dl IG1pZ2h0IG5lZWQgaXQmcXVvdDsuIFNpbmNlIHRoZSBkcmFmdCBoYXMgYWxyZWFkeSBiZWVuIGFw cHJvdmVkIGJ5IHRoZSBJRVNHLCB3ZSBzaG91bGRuJ3QNCiBtYWtlIGEgbWF0ZXJpYWwgY2hhbmdl IHVubGVzcyB3ZSBoYXZlIGEgcmVhbGx5IGdvb2QgcmVhc29uLiBJIHByb3Bvc2UgbGVhdmluZyBp dCBpbi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFzIHlvdSBoYXZlIHByb2JhYmx5IG5vdGljZWQgSSBhbSBzdHJvbmdseSBmb3Ig bGVhdmluZyBUQ1AvRFRMUy9TQ1RQIGluIHRoZSBkcmFmdCwgc2luY2UgdGhpbmdzIHdpbGwgYnJl YWsgb3RoZXJ3aXNlIGFuZCBkcmFmdCB3aWxsIHJlcXVpcmUgc3Vic3RhbnRpYWwgZWRpdGluZyB0 byByZWNvdmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGNsYXNzPSJn bWFpbC0iPk9uIDE2IEZlYiAyMDE3LCBhdCAxMTo1NCwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbmNlIG5vbWluYXRpb24gcHJvY2VzcyBpcyBjb21wbGV0ZWQsIGl0IHNo b3VsZCBiZSB0aGUgc2VsZWN0ZWQsIG5vdCB0aGUgZGVmYXVsdCAmZ3Q7Y2FuZGlkYXRlLjxicj4N Cjxicj4NCldoZW4gc2Vzc2lvbiBpcyBlc3RhYmxpc2hlZCBvciBkdXJpbmcgSUNFIHJlc3RhcnQs IG11bHRpcGxlIGNhbmRpZGF0ZXMgYXJlIHNlbnQgJmd0O2luIG9mZmVyL2Fuc3dlciBhbmQgREVG QVVMVCBjYW5kaWRhdGUgbXVzdCBiZSB1c2VkIGluIHRoZSBtPSBsaW5lLjxicj4NCjxicj4NCk9u Y2Ugbm9taW5hdGlvbiBwcm9jZXNzIGlzIGNvbXBsZXRlZCwgb25seSB0aGUgY3VycmVudGx5IHNl bGVjdGVkIGNhbmRpZGF0ZSBpcyAmZ3Q7c2VudCBpbiBvZmZlci9hbnN3ZXIgYW5kIHRoaXMgd291 bGQgYmUgdGhlIGNhbmRpZGF0ZSBpbiB0aGUgbT0gbGluZS4gUmVzb3VyY2VzICZndDthc3NvY2lh dGVkIHdpdGggb3RoZXIgY2FuZGlkYXRlcywgc3VjaCBhcyBuZXR3b3JrIHBvcnRzIG9yIFRVUk4g YWxsb2NhdGlvbnMsICZndDthcmUgdHlwaWNhbGx5IHJlbGVhc2VkDQogYXQgdGhhdCBwb2ludCwg c28gdGhlcmUgaXMgbm8gcG9pbnQgdG8gaW5jbHVkZSB0aGVtIGFueSAmZ3Q7bW9yZS48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCldlbGws IHRoZW4gd2UgbmVlZCB0byBjbGFyaWZ5IHRoZSB0ZXh0IChvciByZW1vdmUgdGhlIHRleHQgY29t cGxldGVseSwgYW5kIHNpbXBseSByZWZlciB0byB0aGUgSUNFIHNwZWMpLCBiZWNhdXNlIHRoZSBJ Q0UgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0YWxrcyBhYm91dCBvZmZlcnMgYW5kIGFuc3dlcnMg aW4gZ2VuZXJhbC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KVG8gYmUgY2xlYXIsIGFy ZSB5b3UgdGFsa2luZyBhYm91dCBjbGFyaWZ5aW5nIHRleHQgaW4gX3RoaXNfIGRyYWZ0LCBvciBl bHNld2hlcmU/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5DaHJpc3RlciBpcyB0YWxraW5nIGFib3V0IHNlY3Rpb24gMTIuMiBvZiB0 aGUgZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHAuIEFzIHRoZSBsYW5ndWFnZSBzdGFuZHMgcmln aHQgbm93LCBpdCBpcyBub3QgaW5jb3JyZWN0LCBidXQgaXMgc2xpZ2h0bHkgY29uZnVzaW5nLCBz aW5jZSBpdCBpcyB0YWxraW5nIGFib3V0IGRlZmF1bHQgY2FuZGlkYXRlcyBmb3IgYWxsIElDRSBy ZWxhdGVkIG9mZmVyL2Fuc3dlciBleGNoYW5nZXMuJm5ic3A7DQogQWZ0ZXIgSUNFIG5vbWluYXRp b24gcHJvY2VzcyBpcyBjb21wbGV0ZWQsIHRoZXJlIGlzIG9ubHkgb25lIGNhbmRpZGF0ZSBsZWZ0 LCBzbyB0aGVyZSBpcyBubyBkZWZhdWx0LiBJbiBzZXNzaW9uIGRlc2NyaXB0aW9ucyB0aGF0IGRl c2NyaWJlIHRoZSBzZXNzaW9uIGFmdGVyIElDRSBub21pbmF0aW9uIGlzIGNvbXBsZXRlIG9ubHkg b25lIGNhbmRpZGF0ZSBpcyBwcmVzZW50LCBzbyB0aGVyZSBpcyB0eXBpY2FsbHkgbm8gY29uZnVz aW9uIGFib3V0DQogd2hhdCBnb2VzIGludG8gdGhlIG09IGxpbmUsIGJ1dCB0aGlzIGlzIG5vdCBz cGVsbGVkIG91dCBpbiB0aGUgZHJhZnQuIEkgd2lsbCBzdWJtaXQgdGhlIFBSIGFuZCBDaHJpc3Rl ciBjYW4gbWVyZ2UgYW5kIHJlc3VibWl0IHRoZSBkcmFmdCB3aGVuIGhlIGlzIGJhY2suPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4C0075FDESESSMB209erics_-- From nobody Sat Feb 18 01:32:34 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DF31294D3 for ; Sat, 18 Feb 2017 01:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 yP_rPJzR3QTm for ; Sat, 18 Feb 2017 01:32:32 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C486512941D for ; Sat, 18 Feb 2017 01:32:31 -0800 (PST) X-AuditID: c1b4fb3a-f72d4980000021e0-f9-58a814ad20e8 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 6B.6E.08672.DA418A85; Sat, 18 Feb 2017 10:32:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0319.002; Sat, 18 Feb 2017 10:31:48 +0100 From: Christer Holmberg To: Roman Shpount , Ben Campbell Thread-Topic: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? Thread-Index: AQHSiGuZ0ghkIgIFz0iRXtxKyN1pOqFrt7kAgAAhoiD///XmgIAABf+AgAARKfD///H8AIAAEY/QgAGCcoCAAAjKgIABDT9w Date: Sat, 18 Feb 2017 09:31:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C00762F@ESESSMB209.ericsson.se> References: <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4C004589@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C00464B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0046CD@ESESSMB209.ericsson.se> <18C350AD-9C5B-4723-B934-4E27DD86FB6B@nostrum.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.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbE9RHetyIoIg5mtVhbzO0+zW0xd/pjF YsaFqcwOzB5Llvxk8pi18wmLx60pBQHMUVw2Kak5mWWpRfp2CVwZHbdzC6ZxVax79pKlgfEL ZxcjJ4eEgInEjA1LWUFsIYF1jBInNvt3MXIB2YsZJSYtvsLYxcjBwSZgIdH9TxukRkTAVaLr +3RGEJtZQF7iwpI1TCC2sICTxJv3V1khapwlzt1oYoSw8yRmzl4OVsMioCpxecd/FhCbV8BX YtqbuywQuxaxSpzbNp0ZZBenQKDEnA/xIDWMAmIS309BzGcWEJe49WQ+E8TNAhJL9pxnhrBF JV4+/scKYStJrNh+CexkZgFNifW79CFaFSWmdD9kh1grKHFy5hOWCYyis5BMnYXQMQtJxywk HQsYWVYxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBEbMwS2/rXYwHnzueIhRgINRiYf3A//y CCHWxLLiytxDjBIczEoivBMEVkQI8aYkVlalFuXHF5XmpBYfYpTmYFES5zVbeT9cSCA9sSQ1 OzW1ILUIJsvEwSnVwJhw9pfxKs8jZRuLwn23/AkKCrh672Wwv6bPGf5vi/KWaze9vyLVKSLR mtclEbLV+cEMz0WcU24n3mtPtpvOY/9Sq3nzo/o3EsuavAuuzI0NOiFyKa2yfiofh/mTrIKm 56W1EkLhz4WWW63XnWvh8VHe54lEstHqHwV7hZ5P9i3pMV2UZJJ5T4mlOCPRUIu5qDgRALUk BUKUAgAA Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 09:32:33 -0000 SGksDQoNCj4+VG8gYmUgY2xlYXIsIGFyZSB5b3UgdGFsa2luZyBhYm91dCBjbGFyaWZ5aW5nIHRl eHQgaW4gX3RoaXNfIGRyYWZ0LCBvciBlbHNld2hlcmU/DQo+DQo+Q2hyaXN0ZXIgaXMgdGFsa2lu ZyBhYm91dCBzZWN0aW9uIDEyLjIgb2YgdGhlIGRyYWZ0LWlldGYtbW11c2ljLXNjdHAtc2RwLiBB cyB0aGUgbGFuZ3VhZ2Ugc3RhbmRzIHJpZ2h0IA0KPm5vdywgaXQgaXMgbm90IGluY29ycmVjdCwg YnV0IGlzIHNsaWdodGx5IGNvbmZ1c2luZywgc2luY2UgaXQgaXMgdGFsa2luZyBhYm91dCBkZWZh dWx0IGNhbmRpZGF0ZXMgZm9yIGFsbCBJQ0UgDQo+cmVsYXRlZCBvZmZlci9hbnN3ZXIgZXhjaGFu Z2VzLsKgIEFmdGVyIElDRSBub21pbmF0aW9uIHByb2Nlc3MgaXMgY29tcGxldGVkLCB0aGVyZSBp cyBvbmx5IG9uZSBjYW5kaWRhdGUgDQo+bGVmdCwgc28gdGhlcmUgaXMgbm8gZGVmYXVsdC4gSW4g c2Vzc2lvbiBkZXNjcmlwdGlvbnMgdGhhdCBkZXNjcmliZSB0aGUgc2Vzc2lvbiBhZnRlciBJQ0Ug bm9taW5hdGlvbiBpcyBjb21wbGV0ZQ0KPm9ubHkgb25lIGNhbmRpZGF0ZSBpcyBwcmVzZW50LCBz byB0aGVyZSBpcyB0eXBpY2FsbHkgbm8gY29uZnVzaW9uIGFib3V0IHdoYXQgZ29lcyBpbnRvIHRo ZSBtPSBsaW5lLCBidXQgdGhpcyBpcyANCj5ub3Qgc3BlbGxlZCBvdXQgaW4gdGhlIGRyYWZ0LiBJ IHdpbGwgc3VibWl0IHRoZSBQUiBhbmQgQ2hyaXN0ZXIgY2FuIG1lcmdlIGFuZCByZXN1Ym1pdCB0 aGUgZHJhZnQgd2hlbiBoZSBpcyBiYWNrLg0KDQpUaGFua3MhDQoNCkFsc28gbm90ZSB0aGF0IHRo aXMgaXMgc29tZXRoaW5nIHRoYXQgc2hhbGwgYmUgY2xlYXIgaW4gZHJhZnQtaWNlLXNpcC1zZHAs IGJlY2F1c2UgaXQncyBub3QgU0NUUC1TRFAgc3BlY2lmaWMuIEJ1dCwgdGhhdCdzIGEgc2VwYXJh dGUgaXNzdWUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Sat Feb 18 01:35:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1DE1294F9 for ; Sat, 18 Feb 2017 01:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 lngg4duUiwzj for ; Sat, 18 Feb 2017 01:35:43 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1304B1294D3 for ; Sat, 18 Feb 2017 01:35:42 -0800 (PST) X-AuditID: c1b4fb30-e97ff70000002c77-bf-58a8156c4d3d Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id EA.00.11383.C6518A85; Sat, 18 Feb 2017 10:35:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0319.002; Sat, 18 Feb 2017 10:35:40 +0100 From: Christer Holmberg To: Paul Kyzivat , Taylor Brandstetter Thread-Topic: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections Thread-Index: AQHSiMV0wsnKqkRmGEuVhuugjvh/xaFtWdeAgAEo62A= Date: Sat, 18 Feb 2017 09:35:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4C0076FE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbHdWzdXdEWEwfOlshaXVzxktZi6/DGL xYoNB1gdmD3+vv/A5LFgU6nHkiU/mQKYo7hsUlJzMstSi/TtErgy5i0/zFKww7HiVc8D1gbG B/ZdjJwcEgImEgdffGbqYuTiEBJYxygxe+YUNghnMaPEvQ2NQBkODjYBC4nuf9ogDSICoRJ/ /t1gA7GZBVQkXp2+zApiCwuESPRPmMsIUg5Ss+VIJUS5lcSH1RPASlgEVCXmPJnHDGLzCvhK bD12FWpVN7PE3F+TGEESnAIOEuv27GQCsRkFxCS+n1rDBLFLXOLWk/lMEEcLSCzZc54ZwhaV ePn4HyuErSSxYvslsBuYBTQl1u/Sh2hVlJjS/ZAdYq+gxMmZT1gmMIrOQjJ1FkLHLCQds5B0 LGBkWcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGDUHt/w22MH48rnjIUYBDkYlHt4P/Msj hFgTy4orcw8xSnAwK4nwThBYESHEm5JYWZValB9fVJqTWnyIUZqDRUmc12zl/XAhgfTEktTs 1NSC1CKYLBMHp1QDIzOHQoB9R3zSx/ddZy0YLIO6F372525YJ/V2m8i9iQwyqgpfb2eu0fc5 Hr91cu8hxYMvTlZNlfM8w5Dlo93zMeXFx+D1rNoFkwUslpRba0dfWfc0ZvbidUb/DYJz+P6o s37nXyizzNr1iNITuW0xCbb/ve2EIu128yfNmeie/N+w897M4/4vlFiKMxINtZiLihMBLKEs YJYCAAA= Archived-At: Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 09:35:45 -0000 SGksDQoNCkkgaW52aXRlIGFueW9uZSB3aG8gaGFzIGEgc3VnZ2VzdGlvbiBvbiB0ZXh0IHRoYXQg bmVlZHMgdG8gYmUgbW9kaWZpZWQvYWRkZWQvcmVtb3ZlZCB0byBwcm92aWRlIGEgcHVsbCByZXF1 ZXN0IChvciBzZW5kIHRleHQgdG8gdGhlIGxpc3QpIHRvIGRvIHNvOyBpbiBkcmFmdC1idW5kbGUs IGRyYWZ0LW11eC1hdHRyaWJ1dGVzLCBhbmQvb3IgYW55IG90aGVyIHNwZWNpZmljYXRpb24uLi4N Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdV0gDQpTZW50OiAx NyBGZWJydWFyeSAyMDE3IDE4OjUxDQpUbzogVGF5bG9yIEJyYW5kc3RldHRlciA8ZGVhZGJlZWZA Z29vZ2xlLmNvbT4NCkNjOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPjsgSUVURiBNTVVTSUMgV0cgPG1tdXNpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbTU1VU0lDXSBGVzogSXNzdWUgIzI3OiBBbGxvdyBSVFAgYXR0cmlidXRlcyBpbiBub24tbWVk aWEgbT0gc2VjdGlvbnMNCg0KT24gMi8xNi8xNyA5OjI3IFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVy IHdyb3RlOg0KPiAgICAgU28sIHRvIG1ha2UgdGhpcyB3b3JrIEkgdGhpbmsgaXQgd2lsbCBiZSBu ZWNlc3NhcnkgdG8gYW1tZW5kIHRoZQ0KPiAgICAgZGVmaW5pdGlvbnMgb2YgdGhlIHBhcnRpY3Vs YXIgYXR0cmlidXRlcyB0byBzcGVjaWZ5IHRoaXMgdXNhZ2UuIEFuZA0KPiAgICAgdGhlbiBmdXR1 cmUgbmV3IGF0dHJpYnV0ZXMgdGhhdCBwZXJ0YWluIHRvIFJUUCB3b3VsZCBhbHNvIG5lZWQgdG8N Cj4gICAgIGFkZHJlc3MgdGhpcy4NCj4NCj4NCj4gc2RwLW11eC1hdHRyaWJ1dGVzIGFscmVhZHkg YW1lbmRzIHRoZSBkZWZpbml0aW9ucyBvZiB0aGVzZSBhdHRyaWJ1dGVzLCANCj4gc3VjaCB0aGF0 IGEgVFJBTlNQT1JUIGF0dHJpYnV0ZSBpbiBtPSBzZWN0aW9uICJBIiBjYW4gYmUgdXNlZCBmb3Ig DQo+IG1lZGlhIGRlc2NyaWJlZCBieSBtPSBzZWN0aW9uICJCIi4gU28sIEkgZG9uJ3Qgc2VlIHdo eSBpdCBjb3VsZG4ndCBnbyANCj4gYSBzdGVwIGZ1cnRoZXIsIGFuZCBleHBsaWNpdGx5IGFsbG93 IFRSQU5TUE9SVCBhbmQgSURFTlRJQ0FMIGNhdGVnb3J5IA0KPiBhdHRyaWJ1dGVzIHRvIGFwcGVh ciBpbiBtPSBzZWN0aW9ucyB3aXRoIHByb3RvIHZhbHVlcyBub3Qgbm9ybWFsbHkgDQo+IHVzZWQg d2l0aCB0aG9zZSBhdHRyaWJ1dGVzLg0KDQpJIHdpbGwgcmVzZXJ2ZSBqdWRnZW1lbnQgdW50aWwg SSBzZWUgc3BlY2lmaWMgdGV4dC4NCg0KCVRoYW5rcywNCglQYXVsDQoNCj4gT24gVGh1LCBGZWIg MTYsIDIwMTcgYXQgMzo1MCBQTSwgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHUg DQo+IDxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pj4gd3JvdGU6DQo+DQo+ICAgICBPbiAy LzE2LzE3IDEyOjEwIFBNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4NCj4gICAgICAgICBI aSBQYXVsLA0KPg0KPiAgICAgICAgIEkgYXNzdW1lIHlvdSBoYXZlIGFuIG9waW5pb24gb24gdGhp cyA6KQ0KPg0KPiAgICAgICAgIFRoZSBzdWdnZXN0aW9uIGlzIHRvIGFsbG93IFJUUC1zcGVjaWZp YyBwYXJhbWV0ZXJzIChTRFAgcnRjcC1tdXgNCj4gICAgICAgICBhdHRyaWJ1dGVzIGV0YykgaW4g bm9uLVJUUCBtPSBsaW5lcyAoZS5nLiwgZGF0YSBjaGFubmVsKS4NCj4NCj4NCj4gICAgIFRoaXMg aXMgYSBuYXN0eSBpc3N1ZS4NCj4NCj4gICAgIFRoZSBwcm9ibGVtIHdpdGggYWxsb3dpbmcgdGhp cyBpczogd2hhdCBkbyB0aGVzZSBwYXJhbWV0ZXJzICptZWFuKg0KPiAgICAgd2hlbiBzbyBhdHRh Y2hlZD8gQW5kIHdoZXJlIGRvIEkgbG9vayB0byBmaW5kIG91dD8NCj4NCj4gICAgIEknbSBub3Qg Y2VydGFpbiBpZiB0aGV5IGFyZSBjdXJyZW50bHkgcGVybWl0dGVkIG9yIG5vdC4gQUZBSUsgdGhl cmUNCj4gICAgIGlzIG5vICpnZW5lcmFsKiBtZWNoYW5pc20gZm9yIHNwZWNpZnlpbmcgd2l0aCB3 aGljaCBwcm90byB2YWx1ZXMgYQ0KPiAgICAgcGFydGljdWxhciBhdHRyaWJ1dGUgbWF5IGJlIHVz ZWQuIEkgaGF2ZW4ndCBzdHVkaWVkIHRoZSBkZWZpbml0aW9ucw0KPiAgICAgb2YgdGhlICJSVFAt cmVsYXRlZCIgYXR0cmlidXRlcyB0byBzZWUgaWYgdGhleSBtYWtlIGEgc3BlY2lmaWMNCj4gICAg IHN0YXRlbWVudCBhYm91dCB0aGlzLiBNeSBndWVzcyBpcyB0aGF0IHRoZXkgZG9uJ3QsIGJ1dCB0 aGF0IHRoZXkNCj4gICAgIG9ubHkgZGVmaW5lIHRoZSBtZWFuaW5nIGluIHRoZSBjb250ZXh0IG9m IGFuIFJUUCBzZXNzaW9uLg0KPg0KPiAgICAgSWYgdGhhdCBpcyBzbywgcGVyaGFwcyB0aGUgcnVs ZSB0aGF0IHVua25vd24gYXR0cmlidXRlcyBhcmUgdG8gYmUNCj4gICAgIGlnbm9yZWQgc2hvdWxk IGFwcGx5IHRvIHRob3NlIGF0dHJpYnV0ZXMgd2hlbiB1c2VkIHdpdGggYSBub24tUlRQDQo+ICAg ICBtZWRpYSBzZWN0aW9uLiBCdXQgaWYgdGhhdCBydWxlIHdlcmUgdG8gYXBwbHksIHRoZW4gd2Ug d291bGQgZXhwZWN0DQo+ICAgICB0aGF0IHdpdGggTy9BIHRoZSBydWxlcyBmb3IgaG93IHRoZXNl IGF0dHJpYnV0ZXMgaW4gYW4gb2ZmZXIgYWZmZWN0DQo+ICAgICB3aGF0IGdvZXMgaW4gdGhlIGFu c3dlciB3b3VsZCBub3QgYXBwbHkuIEkgZ3Vlc3MgdGhhdCB3b24ndCBiZQ0KPiAgICAgc3VmZmlj aWVudCBoZXJlLg0KPg0KPiAgICAgU28sIHRvIG1ha2UgdGhpcyB3b3JrIEkgdGhpbmsgaXQgd2ls bCBiZSBuZWNlc3NhcnkgdG8gYW1tZW5kIHRoZQ0KPiAgICAgZGVmaW5pdGlvbnMgb2YgdGhlIHBh cnRpY3VsYXIgYXR0cmlidXRlcyB0byBzcGVjaWZ5IHRoaXMgdXNhZ2UuIEFuZA0KPiAgICAgdGhl biBmdXR1cmUgbmV3IGF0dHJpYnV0ZXMgdGhhdCBwZXJ0YWluIHRvIFJUUCB3b3VsZCBhbHNvIG5l ZWQgdG8NCj4gICAgIGFkZHJlc3MgdGhpcy4NCj4NCj4gICAgIElNTyB0aGlzIGlzIGEgY2FuIG9m IHdvcm1zLiBTbyBteSBvcGluaW9uIGlzIHRoYXQgdGhlc2Ugc2hvdWxkICpub3QqDQo+ICAgICBi ZSB1c2VkIHdpdGggbm9uLVJUUCBtLWxpbmVzLCB3aXRoIG9yIHdpdGhvdXQgYnVuZGxlLg0KPg0K PiAgICAgTm90ZSB0aGF0IGRhdGEgY2hhbm5lbCBpcyBhIHNwZWNpYWwgY2FzZS4gV2hpbGUgd2Ug aGF2ZSBhZ3JlZWQgbm90DQo+ICAgICB0byBjb25zaWRlciBpdCBmb3Igbm93LCBpdCBpcyBwb3Nz aWJsZSwgaW4gcHJpbmNpcGxlLCB0byBydW4gUlRQDQo+ICAgICBvdmVyIGEgZGF0YSBjaGFubmVs LiBJZiB0aGF0IHdlcmUgZGVmaW5lZCB0aGVuIHRoZXNlIGF0dHJpYnV0ZXMNCj4gICAgIHdvdWxk IGFsc28gYmUgbmVlZGVkLiBCdXQgdGhlbiB0aGV5IHdvdWxkIG5vdCBiZSB1c2VkIGFzIG1lZGlh LWxldmVsDQo+ICAgICBhdHRyaWJ1dGVzLiBJbnN0ZWFkLCB0aGV5IHdvdWxkIGJlIGRjc2EgYXR0 cmlidXRlcy4NCj4NCj4gICAgICAgICAgICAgVGhhbmtzLA0KPiAgICAgICAgICAgICBQYXVsDQo+ DQo+ICAgICAgICAgKkZyb206Km1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3Jn DQo+ICAgICAgICAgPG1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZz5dICpPbiBCZWhhbGYg T2YgKkNocmlzdGVyDQo+ICAgICAgICAgSG9sbWJlcmcNCj4gICAgICAgICAqU2VudDoqIDE2IEZl YnJ1YXJ5IDIwMTcgMTk6MDcNCj4gICAgICAgICAqVG86KiBFcmljIFJlc2NvcmxhIDxla3JAcnRm bS5jb20gPG1haWx0bzpla3JAcnRmbS5jb20+PjsgbW11c2ljDQo+ICAgICAgICAgV0cgPG1tdXNp Y0BpZXRmLm9yZyA8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4+DQo+ICAgICAgICAgKlN1YmplY3Q6 KiBSZTogW01NVVNJQ10gSXNzdWUgIzI3OiBBbGxvdyBSVFAgYXR0cmlidXRlcyBpbg0KPiAgICAg ICAgIG5vbi1tZWRpYSBtPQ0KPiAgICAgICAgIHNlY3Rpb25zDQo+DQo+DQo+DQo+ICAgICAgICAg SGksDQo+DQo+ICAgICAgICAgKiAqDQo+DQo+ICAgICAgICAgKj4qU2VlOg0KPg0KPiAgICAgICAg ICAgICBodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtc2RwLWJ1bmRsZS9pc3N1ZXMvMjcN Cj4gICAgICAgICAgICAgPGh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1zZHAtYnVuZGxl L2lzc3Vlcy8yNz4NCj4NCj4NCj4gICAgICAgICAgICAgaHR0cHM6Ly9naXRodWIuY29tL3J0Y3dl Yi13Zy9qc2VwL2lzc3Vlcy81MjgNCj4gICAgICAgICAgICAgPGh0dHBzOi8vZ2l0aHViLmNvbS9y dGN3ZWItd2cvanNlcC9pc3N1ZXMvNTI4Pg0KPg0KPg0KPg0KPg0KPiAgICAgICAgICAgICBUaGUg YmFzaWMgaXNzdWUgaXMgdGhhdCBpdCdzIHBvc3NpYmxlIHRvIGhhdmUgYSBzaXR1YXRpb24NCj4g ICAgICAgICAgICAgd2hlcmUgeW91DQo+DQo+ICAgICAgICAgaGF2ZSBib3RoDQo+DQo+ICAgICAg ICAgICAgIG1lZGlhIGFuZCBkYXRhIG09IHNlY3Rpb25zIGJ1dCB0aGUgQlVORExFIHRhZyBpcyBh c3NvY2lhdGVkDQo+ICAgICAgICAgICAgIHdpdGggdGhlIGRhdGENCj4NCj4NCj4gICAgICAgICAg ICAgbT0gc2VjdGlvbiBhbmQgbm93IHlvdSBuZWVkIHRvIHB1dCB0aGUgVFJBTlNQT1JUIGFuZCAN Cj4gSURFTlRJQ0FMDQo+DQo+DQo+ICAgICAgICAgICAgIGF0dHJpYnV0ZXMgc29tZXdoZXJlLiBU aGUgSlNFUCBlZGl0b3JzIGRpc2N1c3NlZCB0aGlzIGFuZA0KPiAgICAgICAgICAgICBjYW1lIHRv IHRoZQ0KPg0KPg0KPiAgICAgICAgICAgICBjb25jbHVzaW9uIHRoYXQgaXQgc2hvdWxkIGdvIHdp dGggdGhlIEJVTkRMRSB0YWcgKGkuZS4sIGluDQo+ICAgICAgICAgICAgIHRoZSBkYXRhIG09DQo+ DQo+ICAgICAgICAgc2VjdGlvbikNCj4NCj4gICAgICAgICAgICAgYW5kIHRoYXQgQlVORExFIHNo b3VsZCBmb3JiaWQgdGhpcywgYnV0IGl0IHJlcXVpcmVzIGEgY2hhbmdlDQo+ICAgICAgICAgICAg IHRvIEJVTkRMRS4NCj4NCj4NCj4NCj4NCj4gICAgICAgICBEaWQgeW91IG1lYW4gdG8gc2F5IHRo YXQgQlVORExFIHNob3VsZCBOT1QgZm9yYmlkIHRoaXM/DQo+DQo+DQo+DQo+ICAgICAgICAgQmFz ZWQgb24geW91ciBHaXRIdWIgZGlzY3Vzc2lvbiwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHlv dQ0KPiAgICAgICAgIHdhbnQgdG8NCj4gICAgICAgICBhbGxvdyB0byBpbmNsdWRlIFJUUC1zcGVj aWZpYyBwYXJhbWV0ZXJzICjigJhydGNwLW11eOKAmSwg4oCYcnRjcOKAmSwNCj4gICAgICAgICDi gJhydGNwLW11eC1vbmx54oCZIGF0dHJpYnV0ZXMgZXRjKSBpbiB0aGUgZGF0YSBtPSBzZWN0aW9u Lg0KPg0KPg0KPg0KPiAgICAgICAgIFRvIHJlcGVhdCB3aGF0IEkgc2FpZCBvbiBHaXRIdWI6DQo+ DQo+DQo+DQo+ICAgICAgICAgVGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgaW4gdGhlIHBhc3QsIGFu ZCB0aGUgb3V0Y29tZSBoYXMgYmVlbiB0byBub3cNCj4gICAgICAgICBhbGxvdyBSVFAtc3BlY2lm aWMgcGFyYW1ldGVycyBpbiBub24tUlRQIG09IHNlY3Rpb25zLg0KPg0KPg0KPg0KPiAgICAgICAg IEEgc29sdXRpb24gd291bGQgYmUgdG8gc2ltcGx5IGNoYW5nZSB0aGUgYnVuZGxlIHRhZyB3aGVu IHRoZSBSVFAgbT0NCj4gICAgICAgICBzZWN0aW9ucyBhcmUgYWRkZWQuDQo+DQo+DQo+DQo+ICAg ICAgICAg4oCmT1IsIHdlIGNoYW5nZSB0aGUgbXV4IGNhdGVnb3J5IGZvciB0aGUgUlRQLXNwZWNp ZmljIHBhcmFtZXRlcnMuDQo+ICAgICAgICAgQnV0LA0KPiAgICAgICAgIHRoYXQgb2YgY291cnNl IG1lYW5zIHRoZXkgaGF2ZSB0byBiZSBhZGRlZCB0byBldmVyeSBSVFAgbT0gc2VjdGlvbi4NCj4N Cj4NCj4NCj4gICAgICAgICBSZWdhcmRzLA0KPg0KPg0KPg0KPiAgICAgICAgIENocmlzdGVyDQo+ DQo+DQo+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiAgICAgbW11c2ljIG1haWxpbmcgbGlzdA0KPiAgICAgbW11c2ljQGlldGYub3JnIDxtYWls dG86bW11c2ljQGlldGYub3JnPg0KPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tbXVzaWMNCj4gICAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21tdXNpYz4NCj4NCj4NCg0K From nobody Sat Feb 18 08:09:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D2B126BF7 for ; Sat, 18 Feb 2017 08:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 KxQ1NmVc-Ib2 for ; Sat, 18 Feb 2017 08:09:52 -0800 (PST) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53BD1293E8 for ; Sat, 18 Feb 2017 08:09:52 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-12v.sys.comcast.net with SMTP id f7YdcITvHnZkvf7a4cMqfG; Sat, 18 Feb 2017 16:09:52 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-14v.sys.comcast.net with SMTP id f7a3ceNxIqUWef7a3c9OZy; Sat, 18 Feb 2017 16:09:52 +0000 To: Christer Holmberg , Taylor Brandstetter References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0076FE@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <66341809-4c3e-2989-5039-a3369c0fa503@alum.mit.edu> Date: Sat, 18 Feb 2017 11:09:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4C0076FE@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfAguQxfLVcLKxVK3VHF8mVa47lWDgMcF0F1p1cgtADx6MoMytM8a1VrpQSMUIb323K3ioeNlN0k2QzJWj2Q4PrwqC3Xq9o4yTEkPDLf2PdQo5dhY57j3 O84yE3qRqTfvjpfgZR541nDiXodcX3BphP4eJlJbm0B0Awam54cx3kNrxMr/qgPromLWG+9AzOt27xASqsS7Mg1tQUBK7jGMcWUhXAy3Kl5Q0xfpci/7wYpW kRwMneWNcy7ji0iTATi31Q== Archived-At: Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 16:09:54 -0000 On 2/18/17 4:35 AM, Christer Holmberg wrote: > Hi, > > I invite anyone who has a suggestion on text that needs to be modified/added/removed to provide a pull request (or send text to the list) to do so; in draft-bundle, draft-mux-attributes, and/or any other specification... IMO it doesn't make sense to put attributes on one bundled m-line that only apply to some other bundled m-line - current or future. As an alternative, how about picking the first tag in the bundle attribute that identifies an m-line of an appropriate type to carry the attribute? Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 17 February 2017 18:51 > To: Taylor Brandstetter > Cc: Christer Holmberg ; IETF MMUSIC WG > Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections > > On 2/16/17 9:27 PM, Taylor Brandstetter wrote: >> So, to make this work I think it will be necessary to ammend the >> definitions of the particular attributes to specify this usage. And >> then future new attributes that pertain to RTP would also need to >> address this. >> >> >> sdp-mux-attributes already amends the definitions of these attributes, >> such that a TRANSPORT attribute in m= section "A" can be used for >> media described by m= section "B". So, I don't see why it couldn't go >> a step further, and explicitly allow TRANSPORT and IDENTICAL category >> attributes to appear in m= sections with proto values not normally >> used with those attributes. > > I will reserve judgement until I see specific text. > > Thanks, > Paul > >> On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat > > wrote: >> >> On 2/16/17 12:10 PM, Christer Holmberg wrote: >> >> Hi Paul, >> >> I assume you have an opinion on this :) >> >> The suggestion is to allow RTP-specific parameters (SDP rtcp-mux >> attributes etc) in non-RTP m= lines (e.g., data channel). >> >> >> This is a nasty issue. >> >> The problem with allowing this is: what do these parameters *mean* >> when so attached? And where do I look to find out? >> >> I'm not certain if they are currently permitted or not. AFAIK there >> is no *general* mechanism for specifying with which proto values a >> particular attribute may be used. I haven't studied the definitions >> of the "RTP-related" attributes to see if they make a specific >> statement about this. My guess is that they don't, but that they >> only define the meaning in the context of an RTP session. >> >> If that is so, perhaps the rule that unknown attributes are to be >> ignored should apply to those attributes when used with a non-RTP >> media section. But if that rule were to apply, then we would expect >> that with O/A the rules for how these attributes in an offer affect >> what goes in the answer would not apply. I guess that won't be >> sufficient here. >> >> So, to make this work I think it will be necessary to ammend the >> definitions of the particular attributes to specify this usage. And >> then future new attributes that pertain to RTP would also need to >> address this. >> >> IMO this is a can of worms. So my opinion is that these should *not* >> be used with non-RTP m-lines, with or without bundle. >> >> Note that data channel is a special case. While we have agreed not >> to consider it for now, it is possible, in principle, to run RTP >> over a data channel. If that were defined then these attributes >> would also be needed. But then they would not be used as media-level >> attributes. Instead, they would be dcsa attributes. >> >> Thanks, >> Paul >> >> *From:*mmusic [mailto:mmusic-bounces@ietf.org >> ] *On Behalf Of *Christer >> Holmberg >> *Sent:* 16 February 2017 19:07 >> *To:* Eric Rescorla >; mmusic >> WG > >> *Subject:* Re: [MMUSIC] Issue #27: Allow RTP attributes in >> non-media m= >> sections >> >> >> >> Hi, >> >> * * >> >> *>*See: >> >> https://github.com/cdh4u/draft-sdp-bundle/issues/27 >> >> >> >> https://github.com/rtcweb-wg/jsep/issues/528 >> >> >> >> >> >> The basic issue is that it's possible to have a situation >> where you >> >> have both >> >> media and data m= sections but the BUNDLE tag is associated >> with the data >> >> >> m= section and now you need to put the TRANSPORT and >> IDENTICAL >> >> >> attributes somewhere. The JSEP editors discussed this and >> came to the >> >> >> conclusion that it should go with the BUNDLE tag (i.e., in >> the data m= >> >> section) >> >> and that BUNDLE should forbid this, but it requires a change >> to BUNDLE. >> >> >> >> >> Did you mean to say that BUNDLE should NOT forbid this? >> >> >> >> Based on your GitHub discussion, my understanding is that you >> want to >> allow to include RTP-specific parameters (‘rtcp-mux’, ‘rtcp’, >> ‘rtcp-mux-only’ attributes etc) in the data m= section. >> >> >> >> To repeat what I said on GitHub: >> >> >> >> This has been discussed in the past, and the outcome has been to now >> allow RTP-specific parameters in non-RTP m= sections. >> >> >> >> A solution would be to simply change the bundle tag when the RTP m= >> sections are added. >> >> >> >> …OR, we change the mux category for the RTP-specific parameters. >> But, >> that of course means they have to be added to every RTP m= section. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> > From nobody Sat Feb 18 10:45:58 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5FF1295AF for ; Sat, 18 Feb 2017 10:45:56 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQOmUjUGNM2r for ; Sat, 18 Feb 2017 10:45:55 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D532128E19 for ; Sat, 18 Feb 2017 10:45:55 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id l19so35886546ywc.2 for ; Sat, 18 Feb 2017 10:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YgdM0KYghY5ndz4JBT+nYCuuuDPHqiKYUrO/P4zD9hE=; b=f4TKDdh/5oQiCC0YjOyrWuB+OHezlsh1H9A9Tp06uH3zvEs+NkAnP5Ubz055h00mp+ dbXGeEcFLhiscnLNwRTojJ27pD6sQgYnirvLQtlPa71VFjQz39Xtu9t7OBISSQxyzPpD IMlbJNT19RbiUtB3CsSmR9W4z69ko4AVDsc/uTVK+V6OymHgznAYcXHYsJnogldG7OpL CXEdGaHaiwYSrm7tGLv5dlvoWceD/ccvSWixO72gK6Ejehb3QSbNAj0fE6HNrW5xASOw qgG14By1qFmSIZYNi/dIb4EwUBXDI9c7urC1FblGKaoW9qGmMxRLLBu/0FHa+4Qn0GC8 nEPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YgdM0KYghY5ndz4JBT+nYCuuuDPHqiKYUrO/P4zD9hE=; b=OEACxtKajE+9+tKBY7uW5tDkgUL0Az4tP01bBiVwsoj/snatG57++djaIDYAmVMV+U m7WYjW3WM2I6kK17cgfLSMc3uh/hHbvLKAvZF4+Ghln2NSsarlq/Fns0kCEHz7nxCq8Z 2Sib7ZCmnzpoLWcs2xkxTtlkJauWby6IPaqVZz2NfphtwS4tYPLFop/y8rU6KX71v/4x +7Z+V00jM7mh/0ImzlkgxSdCBNz0U/exP1ZNtJb9lsmu/YqWiY4SZqWeHjjpmDE0Ad9c hZIHCozIWUxDYWnIpPY3Y5inLSP7IPH4w5bfdoTWQWiawCOWPzYL6lRklgb/fXPMkV0T +AeQ== X-Gm-Message-State: AMke39mjcOY0YOPPcJInOUhZ/fLcEA41Q1OTWRZB02cSI8bDs+H9864fYYi32nE8i6tnppHrH6mJHpBiliARiw== X-Received: by 10.129.125.84 with SMTP id y81mr10034150ywc.120.1487443554189; Sat, 18 Feb 2017 10:45:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.153.200 with HTTP; Sat, 18 Feb 2017 10:45:13 -0800 (PST) In-Reply-To: <66341809-4c3e-2989-5039-a3369c0fa503@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0076FE@ESESSMB209.ericsson.se> <66341809-4c3e-2989-5039-a3369c0fa503@alum.mit.edu> From: Eric Rescorla Date: Sat, 18 Feb 2017 10:45:13 -0800 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a114928baabf4ea0548d27000 Archived-At: Cc: IETF MMUSIC WG , Christer Holmberg Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 18:45:57 -0000 --001a114928baabf4ea0548d27000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat wrote= : > On 2/18/17 4:35 AM, Christer Holmberg wrote: > >> Hi, >> >> I invite anyone who has a suggestion on text that needs to be >> modified/added/removed to provide a pull request (or send text to the li= st) >> to do so; in draft-bundle, draft-mux-attributes, and/or any other >> specification... >> > > IMO it doesn't make sense to put attributes on one bundled m-line that > only apply to some other bundled m-line - current or future. > Why? The whole principle is that they are supposed to span all the m=3D lin= es. > As an alternative, how about picking the first tag in the bundle attribut= e > that identifies an m-line of an appropriate type to carry the attribute? > Seems much more complicated to implement and specify. To conserve e-mails, responding to Christer as well here: I don't think we need to update any of the relevant RFCs (other than potentially putting them in some useless Updates: line at the top of the doc). The idea here is that BUNDLE overrides them for cases where it applies. -Ekr > Thanks, > Paul > > > Regards, >> >> Christer >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 17 February 2017 18:51 >> To: Taylor Brandstetter >> Cc: Christer Holmberg ; IETF MMUSIC WG < >> mmusic@ietf.org> >> Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= =3D >> sections >> >> On 2/16/17 9:27 PM, Taylor Brandstetter wrote: >> >>> So, to make this work I think it will be necessary to ammend the >>> definitions of the particular attributes to specify this usage. And >>> then future new attributes that pertain to RTP would also need to >>> address this. >>> >>> >>> sdp-mux-attributes already amends the definitions of these attributes, >>> such that a TRANSPORT attribute in m=3D section "A" can be used for >>> media described by m=3D section "B". So, I don't see why it couldn't go >>> a step further, and explicitly allow TRANSPORT and IDENTICAL category >>> attributes to appear in m=3D sections with proto values not normally >>> used with those attributes. >>> >> >> I will reserve judgement until I see specific text. >> >> Thanks, >> Paul >> >> On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat >> > wrote: >>> >>> On 2/16/17 12:10 PM, Christer Holmberg wrote: >>> >>> Hi Paul, >>> >>> I assume you have an opinion on this :) >>> >>> The suggestion is to allow RTP-specific parameters (SDP rtcp-mu= x >>> attributes etc) in non-RTP m=3D lines (e.g., data channel). >>> >>> >>> This is a nasty issue. >>> >>> The problem with allowing this is: what do these parameters *mean* >>> when so attached? And where do I look to find out? >>> >>> I'm not certain if they are currently permitted or not. AFAIK there >>> is no *general* mechanism for specifying with which proto values a >>> particular attribute may be used. I haven't studied the definitions >>> of the "RTP-related" attributes to see if they make a specific >>> statement about this. My guess is that they don't, but that they >>> only define the meaning in the context of an RTP session. >>> >>> If that is so, perhaps the rule that unknown attributes are to be >>> ignored should apply to those attributes when used with a non-RTP >>> media section. But if that rule were to apply, then we would expect >>> that with O/A the rules for how these attributes in an offer affect >>> what goes in the answer would not apply. I guess that won't be >>> sufficient here. >>> >>> So, to make this work I think it will be necessary to ammend the >>> definitions of the particular attributes to specify this usage. And >>> then future new attributes that pertain to RTP would also need to >>> address this. >>> >>> IMO this is a can of worms. So my opinion is that these should *not= * >>> be used with non-RTP m-lines, with or without bundle. >>> >>> Note that data channel is a special case. While we have agreed not >>> to consider it for now, it is possible, in principle, to run RTP >>> over a data channel. If that were defined then these attributes >>> would also be needed. But then they would not be used as media-leve= l >>> attributes. Instead, they would be dcsa attributes. >>> >>> Thanks, >>> Paul >>> >>> *From:*mmusic [mailto:mmusic-bounces@ietf.org >>> ] *On Behalf Of *Christer >>> Holmberg >>> *Sent:* 16 February 2017 19:07 >>> *To:* Eric Rescorla >; mmusi= c >>> WG > >>> *Subject:* Re: [MMUSIC] Issue #27: Allow RTP attributes in >>> non-media m=3D >>> sections >>> >>> >>> >>> Hi, >>> >>> * * >>> >>> *>*See: >>> >>> https://github.com/cdh4u/draft-sdp-bundle/issues/27 >>> >>> >>> >>> https://github.com/rtcweb-wg/jsep/issues/528 >>> >>> >>> >>> >>> >>> The basic issue is that it's possible to have a situation >>> where you >>> >>> have both >>> >>> media and data m=3D sections but the BUNDLE tag is associat= ed >>> with the data >>> >>> >>> m=3D section and now you need to put the TRANSPORT and >>> IDENTICAL >>> >>> >>> attributes somewhere. The JSEP editors discussed this and >>> came to the >>> >>> >>> conclusion that it should go with the BUNDLE tag (i.e., in >>> the data m=3D >>> >>> section) >>> >>> and that BUNDLE should forbid this, but it requires a chang= e >>> to BUNDLE. >>> >>> >>> >>> >>> Did you mean to say that BUNDLE should NOT forbid this? >>> >>> >>> >>> Based on your GitHub discussion, my understanding is that you >>> want to >>> allow to include RTP-specific parameters (=E2=80=98rtcp-mux=E2= =80=99, =E2=80=98rtcp=E2=80=99, >>> =E2=80=98rtcp-mux-only=E2=80=99 attributes etc) in the data m= =3D section. >>> >>> >>> >>> To repeat what I said on GitHub: >>> >>> >>> >>> This has been discussed in the past, and the outcome has been t= o >>> now >>> allow RTP-specific parameters in non-RTP m=3D sections. >>> >>> >>> >>> A solution would be to simply change the bundle tag when the RT= P >>> m=3D >>> sections are added. >>> >>> >>> >>> =E2=80=A6OR, we change the mux category for the RTP-specific pa= rameters. >>> But, >>> that of course means they have to be added to every RTP m=3D >>> section. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> _______________________________________________ >>> 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 > --001a114928baabf4ea0548d27000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat <pkyzivat@alum.mit.e= du> wrote:
On 2/18/17 4:35 AM, Christer Holmberg wrote:
Hi,

I invite anyone who has a suggestion on text that needs to be modified/adde= d/removed to provide a pull request (or send text to the list) to do so; in= draft-bundle, draft-mux-attributes, and/or any other specification...

 IMO it doesn't make sense to put attributes on one bundled m-line that = only apply to some other bundled m-line - current or future.

Why? The whole principle is that they are supposed to= span all the m=3D lines.

=C2=A0
As an alternative, how about picking the first tag in the bundle attribute = that identifies an m-line of an appropriate type to carry the attribute?

Seems much more complicated to implement = and specify.

To conserve e-mails, responding to Ch= rister as well here: I don't think we need to update any of the relevan= t RFCs (other than potentially putting them in some
useless Updat= es: line at the top of the doc). The idea here is that BUNDLE overrides the= m for cases where it applies.

-Ekr
=C2= =A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
Sent: 17 February 2017 18:51
To: Taylor Brandstetter <deadbeef@google.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>; IETF MMUSIC= WG <mmusic@ietf.or= g>
Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m=3D= sections

On 2/16/17 9:27 PM, Taylor Brandstetter wrote:
=C2=A0 =C2=A0 So, to make this work I think it will be necessary to ammend = the
=C2=A0 =C2=A0 definitions of the particular attributes to specify this usag= e. And
=C2=A0 =C2=A0 then future new attributes that pertain to RTP would also nee= d to
=C2=A0 =C2=A0 address this.


sdp-mux-attributes already amends the definitions of these attributes,
such that a TRANSPORT attribute in m=3D section "A" can be used f= or
media described by m=3D section "B". So, I don't see why it c= ouldn't go
a step further, and explicitly allow TRANSPORT and IDENTICAL category
attributes to appear in m=3D sections with proto values not normally
used with those attributes.

I will reserve judgement until I see specific text.

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

On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=C2=A0 =C2=A0 On 2/16/17 12:10 PM, Christer Holmberg wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Paul,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I assume you have an opinion on this :)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The suggestion is to allow RTP-specific paramet= ers (SDP rtcp-mux
=C2=A0 =C2=A0 =C2=A0 =C2=A0 attributes etc) in non-RTP m=3D lines (e.g., da= ta channel).


=C2=A0 =C2=A0 This is a nasty issue.

=C2=A0 =C2=A0 The problem with allowing this is: what do these parameters *= mean*
=C2=A0 =C2=A0 when so attached? And where do I look to find out?

=C2=A0 =C2=A0 I'm not certain if they are currently permitted or not. A= FAIK there
=C2=A0 =C2=A0 is no *general* mechanism for specifying with which proto val= ues a
=C2=A0 =C2=A0 particular attribute may be used. I haven't studied the d= efinitions
=C2=A0 =C2=A0 of the "RTP-related" attributes to see if they make= a specific
=C2=A0 =C2=A0 statement about this. My guess is that they don't, but th= at they
=C2=A0 =C2=A0 only define the meaning in the context of an RTP session.

=C2=A0 =C2=A0 If that is so, perhaps the rule that unknown attributes are t= o be
=C2=A0 =C2=A0 ignored should apply to those attributes when used with a non= -RTP
=C2=A0 =C2=A0 media section. But if that rule were to apply, then we would = expect
=C2=A0 =C2=A0 that with O/A the rules for how these attributes in an offer = affect
=C2=A0 =C2=A0 what goes in the answer would not apply. I guess that won'= ;t be
=C2=A0 =C2=A0 sufficient here.

=C2=A0 =C2=A0 So, to make this work I think it will be necessary to ammend = the
=C2=A0 =C2=A0 definitions of the particular attributes to specify this usag= e. And
=C2=A0 =C2=A0 then future new attributes that pertain to RTP would also nee= d to
=C2=A0 =C2=A0 address this.

=C2=A0 =C2=A0 IMO this is a can of worms. So my opinion is that these shoul= d *not*
=C2=A0 =C2=A0 be used with non-RTP m-lines, with or without bundle.

=C2=A0 =C2=A0 Note that data channel is a special case. While we have agree= d not
=C2=A0 =C2=A0 to consider it for now, it is possible, in principle, to run = RTP
=C2=A0 =C2=A0 over a data channel. If that were defined then these attribut= es
=C2=A0 =C2=A0 would also be needed. But then they would not be used as medi= a-level
=C2=A0 =C2=A0 attributes. Instead, they would be dcsa attributes.

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *From:*mmusic [mailto:mmusic-bounces@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mmusic-bounces@ietf.org>] *On Behalf O= f *Christer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Holmberg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Sent:* 16 February 2017 19:07
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *To:* Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>>; mmusic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 WG <mmusic@ietf.org <mailto:mmusic@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Subject:* Re: [MMUSIC] Issue #27: Allow RTP at= tributes in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 non-media m=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sections



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 * *

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *>*See:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https:/= /github.com/cdh4u/draft-sdp-bundle/issues/27
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <htt= ps://github.com/cdh4u/draft-sdp-bundle/issues/27>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://github= .com/rtcweb-wg/jsep/issues/528
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://gi= thub.com/rtcweb-wg/jsep/issues/528>




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The basic issue is that it's = possible to have a situation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 where you

=C2=A0 =C2=A0 =C2=A0 =C2=A0 have both

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 media and data m=3D sections but = the BUNDLE tag is associated
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with the data


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m=3D section and now you need to = put the TRANSPORT and
IDENTICAL


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attributes somewhere. The JSEP ed= itors discussed this and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 came to the


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conclusion that it should go with= the BUNDLE tag (i.e., in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the data m=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 section)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and that BUNDLE should forbid thi= s, but it requires a change
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to BUNDLE.




=C2=A0 =C2=A0 =C2=A0 =C2=A0 Did you mean to say that BUNDLE should NOT forb= id this?



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Based on your GitHub discussion, my understandi= ng is that you
=C2=A0 =C2=A0 =C2=A0 =C2=A0 want to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 allow to include RTP-specific parameters (=E2= =80=98rtcp-mux=E2=80=99, =E2=80=98rtcp=E2=80=99,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=98rtcp-mux-only=E2=80=99 attributes etc)= in the data m=3D section.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 To repeat what I said on GitHub:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 This has been discussed in the past, and the ou= tcome has been to now
=C2=A0 =C2=A0 =C2=A0 =C2=A0 allow RTP-specific parameters in non-RTP m=3D s= ections.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 A solution would be to simply change the bundle= tag when the RTP m=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sections are added.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A6OR, we change the mux category for the= RTP-specific parameters.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 But,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that of course means they have to be added to e= very RTP m=3D section.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Christer


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 mmusic mailing list
=C2=A0 =C2=A0 mmusic@i= etf.org <mailto:mmusic@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/mmusic
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/list= info/mmusic>




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

--001a114928baabf4ea0548d27000-- From nobody Sat Feb 18 11:44:28 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984961295B2 for ; Sat, 18 Feb 2017 11:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG_GXiaCUE5X for ; Sat, 18 Feb 2017 11:44:24 -0800 (PST) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEE812955D for ; Sat, 18 Feb 2017 11:44:24 -0800 (PST) Received: by mail-yb0-x236.google.com with SMTP id i66so6442474yba.1 for ; Sat, 18 Feb 2017 11:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L03V5b1CVXJd1jUfrj9LVLolUYpS/1zuzpupbJ6lpMk=; b=UTSN+uGkrxDm/Kld46qaJfsclVpmQR2R3Noe+0sOVA+/MUhwRp0peCK1DDk+w98Of3 SAt5DF0wR6G5Xmkuw3D01Cw0+cy92Idm+FaJz5gxxpJPZ7Vny/X5RS1NMB04gMlxBvpJ RlZ9pDULryQUeiBv0sYQ6RmC1e0vER7x4gOUS24CbUosyq+dIN2/uXqDYysynB7D1SvE hGveUc2BJ4e7F5u8GSD6DtTOgu+p521wrqnHjUxufJZZRVZnA5HZBHbAF9EDyERp3MDO 5YhsS2pCA0kXm0NXa3ZUsZ4BJbies6LnKQmOl/6mVuMIb+0fy+gRS7nfHz/j8ZMsdMFL rD6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L03V5b1CVXJd1jUfrj9LVLolUYpS/1zuzpupbJ6lpMk=; b=RbfdHvsuNQ7FZoG4TB3O9LwYBeah7LbQ1W7x6jbgH2lUlDrLkYaBibF0clokuxg4hL Nfh+ApFh727sZF3bMA5x72jC/qWnZA0uIJ4vsZ4Hf/eK7LycaSFmr148BNfJztDcfe62 0S7pePcFGespv+NP4VdkoN5SzSGHlCudO1gTRoSrpr6Z9LeUTs1oa3UDey0ZGpqscTOq QBbbIf/2WSvlh4Az4mh2Gz68JpuhXJiqYssYfLOww3cnX0YETBg8rTpNnDU4OzgTaC6K MT4trgUg26pacljrCJe+jxFecRI6UBOiHQ4mNs1kIo7FBtAa2X1MI3KMiEHFC6JwjVkI 68xA== X-Gm-Message-State: AMke39lOwqPZ88vTT29hKoRnUkl5XM9ju3lXyUJMBkfct9tDkr9yz1f2KNuQOh58YQVIx3CF96Q9Ab/Hyky4LA== X-Received: by 10.37.246.10 with SMTP id t10mr11107425ybd.107.1487447063866; Sat, 18 Feb 2017 11:44:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.153.200 with HTTP; Sat, 18 Feb 2017 11:43:43 -0800 (PST) In-Reply-To: <405b8725-7173-19f2-58a4-ebae6cbd7814@comcast.net> References: <7594FB04B1934943A5C02806D1A2204B4C005232@ESESSMB209.ericsson.se> <405b8725-7173-19f2-58a4-ebae6cbd7814@comcast.net> From: Eric Rescorla Date: Sat, 18 Feb 2017 11:43:43 -0800 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f403045dc858dd64ca0548d341fe Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 19:44:26 -0000 --f403045dc858dd64ca0548d341fe Content-Type: text/plain; charset=UTF-8 On Fri, Feb 17, 2017 at 9:04 AM, Paul Kyzivat wrote: > On 2/17/17 3:46 AM, Christer Holmberg wrote: > >> Hi, >> >> Based on the comments from Ekr, I've submitted a new version of >> draft-mux-exclusive. >> >> The SDP 'rtcp-mux-only' attribute is now only allowed in SDP offers. >> > > With the new text the offerer never knows if the answerer supports > rtcp-mux-only. He only knows that the answerer supports rtcp-mux. > Yes. I don't think this matters for that O/A, but it might matter for subsequent > O/As. > Why? -Ekjr > At the least, I think section 4.5 is now confusing. For m-lines previously > negotiated with rtcp-mux-only, must the side that is sending a new offer > include the attribute again, while the side that is answering must *not* > include it? (Note the implications when the new offer is in the opposite > direction from the original one.) I think this will be somewhat of a pain - > perhaps more pain than simply always including it in all offers and answers. > > Thanks, > Paul > > > Regards, >> >> Christer >> >> >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: 17 February 2017 10:44 >> To: i-d-announce@ietf.org >> Cc: mmusic@ietf.org >> Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-11.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Multiparty Multimedia Session Control of >> the IETF. >> >> Title : Indicating Exclusive Support of RTP/RTCP >> Multiplexing using SDP >> Author : Christer Holmberg >> Filename : draft-ietf-mmusic-mux-exclusive-11.txt >> Pages : 12 >> Date : 2017-02-17 >> >> Abstract: >> This document defines a new SDP media-level attribute, 'rtcp-mux- >> only', that can be used by an endpoint to indicate exclusive support >> of RTP/RTCP multiplexing. The document also updates RFC 5761, by >> clarifying that an offerer can use a mechanism to indicate that it is >> not able to send and receive RTCP on separate ports. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-11 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-mux-exclusive-11 >> >> >> 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/ >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --f403045dc858dd64ca0548d341fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 17, 2017 at 9:04 AM, Paul Kyzivat <paul.kyzivat@com= cast.net> wrote:
On 2/17/17 3:46 AM, Christer Holmberg wrote:
Hi,

Based on the comments from Ekr, I've submitted a new version of draft-m= ux-exclusive.

The SDP 'rtcp-mux-only' attribute is now only allowed in SDP offers= .

 With the new text the offerer never knows if the answerer supports rtcp-mux= -only. He only knows that the answerer supports rtcp-mux.
<= div>
Yes.


I don't think this matters for that O/A, but it might matter for subseq= uent O/As.

Why?

-Ekjr
=C2=A0
At the least, I think section 4.5 is now confusing. For m-lines previously = negotiated with rtcp-mux-only, must the side that is sending a new offer in= clude the attribute again, while the side that is answering must *not* incl= ude it? (Note the implications when the new offer is in the opposite direct= ion from the original one.) I think this will be somewhat of a pain - perha= ps more pain than simply always including it in all offers and answers.

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

Regards,

Christer


-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: 17 February 2017 10:44
To: i-d-announce= @ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-11.txt

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Multiparty Multimedia Session Control of t= he IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Chri= ster Holmberg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-mux-exclusive-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =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 := 2017-02-17

Abstract:
=C2=A0 =C2=A0This document defines a new SDP media-level attribute, 'rt= cp-mux-
=C2=A0 =C2=A0only', that can be used by an endpoint to indicate exclusi= ve support
=C2=A0 =C2=A0of RTP/RTCP multiplexing.=C2=A0 The document also updates RFC = 5761, by
=C2=A0 =C2=A0clarifying that an offerer can use a mechanism to indicate tha= t it is
=C2=A0 =C2=A0not able to send and receive RTCP on separate ports.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/d= oc/draft-ietf-mmusic-mux-exclusive/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft= -ietf-mmusic-mux-exclusive-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-mmusic-mux-exclusive-11


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/

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

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

--f403045dc858dd64ca0548d341fe-- From nobody Sat Feb 18 13:38:36 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEBB129622 for ; Sat, 18 Feb 2017 13:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 bILDaCPpEwl1 for ; Sat, 18 Feb 2017 13:38:33 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BAAC129621 for ; Sat, 18 Feb 2017 13:38:33 -0800 (PST) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-08v.sys.comcast.net with SMTP id fChecosxJq9PlfCi8cPAHW; Sat, 18 Feb 2017 21:38:32 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-04v.sys.comcast.net with SMTP id fCi7cgTRB4o4TfCi8cjK8E; Sat, 18 Feb 2017 21:38:32 +0000 To: Eric Rescorla References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0076FE@ESESSMB209.ericsson.se> <66341809-4c3e-2989-5039-a3369c0fa503@alum.mit.edu> From: Paul Kyzivat Message-ID: <7df97f84-613d-2f5c-2290-aca82621f5ba@alum.mit.edu> Date: Sat, 18 Feb 2017 16:38:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfLTFpI5xfSPQZ/UR5Ze4CePAW/sU3/6Y/oeHSis3tnNCFbE+ejE/AbLn+7txVMnG9i0z/Qo3XzHSZ6S1Xm+vCyxY9egAIGIfaioraP0mRzKkwr1CcL1R UwyZDyE33vyU7Cwc8Y61mcEq0NfpIvOGIlc3TPjHvOh8I/wzrv1xal2nMwC/PeQQuaX4Wu6ZtAIa7vY2Oe/5+ES8SDJdQ5WSwjhq6PIwG0pLY7fbQ1Drqc9N ECrlBQs+xSYqc8WJbhoOpHIKdukKYI+kVlI6HzASac0= Archived-At: Cc: IETF MMUSIC WG , Christer Holmberg Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 21:38:35 -0000 On 2/18/17 1:45 PM, Eric Rescorla wrote: > > > On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat > wrote: > > On 2/18/17 4:35 AM, Christer Holmberg wrote: > > Hi, > > I invite anyone who has a suggestion on text that needs to be > modified/added/removed to provide a pull request (or send text > to the list) to do so; in draft-bundle, draft-mux-attributes, > and/or any other specification... > > > IMO it doesn't make sense to put attributes on one bundled m-line > that only apply to some other bundled m-line - current or future. > > > Why? The whole principle is that they are supposed to span all the m= lines. They are supposed to span all the m-lines in the bundle that it is meaningful for them to be used with. The closest thing we currently have to this situation is session-level attributes. Some of those are defined as valid at both session and media level, and that the value at session level is a default for media level. These in some sense need to be evaluated in the context of every m-line, even the ones where they aren't defined. But we have no standard rule for these. Every attribute needs to say if it is defined at session level and if that should be treated as a default for a value at media level. And in the process it is specifying (at least implicitly) which m-lines it applies to. In principle this could also be done for all the attributes that are to be identical in bundles. But that means making all the changes to do that, and maintain it in the future. > As an alternative, how about picking the first tag in the bundle > attribute that identifies an m-line of an appropriate type to carry > the attribute? > > Seems much more complicated to implement and specify. > > To conserve e-mails, responding to Christer as well here: I don't think > we need to update any of the relevant RFCs (other than potentially > putting them in some > useless Updates: line at the top of the doc). The idea here is that > BUNDLE overrides them for cases where it applies. Again, maybe it is possible to craft some words that clearly and precisely state how this is to work, in a general way without taking it one attribute at a time. But I want to see them. Then we can discuss whether that is simpler than what I suggested above. Thanks, Paul > -Ekr > > > Thanks, > Paul > > > Regards, > > Christer > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu > ] > Sent: 17 February 2017 18:51 > To: Taylor Brandstetter > > Cc: Christer Holmberg >; IETF MMUSIC WG > > > Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in > non-media m= sections > > On 2/16/17 9:27 PM, Taylor Brandstetter wrote: > > So, to make this work I think it will be necessary to > ammend the > definitions of the particular attributes to specify this > usage. And > then future new attributes that pertain to RTP would > also need to > address this. > > > sdp-mux-attributes already amends the definitions of these > attributes, > such that a TRANSPORT attribute in m= section "A" can be > used for > media described by m= section "B". So, I don't see why it > couldn't go > a step further, and explicitly allow TRANSPORT and IDENTICAL > category > attributes to appear in m= sections with proto values not > normally > used with those attributes. > > > I will reserve judgement until I see specific text. > > Thanks, > Paul > > On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat > > >> wrote: > > On 2/16/17 12:10 PM, Christer Holmberg wrote: > > Hi Paul, > > I assume you have an opinion on this :) > > The suggestion is to allow RTP-specific parameters > (SDP rtcp-mux > attributes etc) in non-RTP m= lines (e.g., data > channel). > > > This is a nasty issue. > > The problem with allowing this is: what do these > parameters *mean* > when so attached? And where do I look to find out? > > I'm not certain if they are currently permitted or not. > AFAIK there > is no *general* mechanism for specifying with which > proto values a > particular attribute may be used. I haven't studied the > definitions > of the "RTP-related" attributes to see if they make a > specific > statement about this. My guess is that they don't, but > that they > only define the meaning in the context of an RTP session. > > If that is so, perhaps the rule that unknown attributes > are to be > ignored should apply to those attributes when used with > a non-RTP > media section. But if that rule were to apply, then we > would expect > that with O/A the rules for how these attributes in an > offer affect > what goes in the answer would not apply. I guess that > won't be > sufficient here. > > So, to make this work I think it will be necessary to > ammend the > definitions of the particular attributes to specify this > usage. And > then future new attributes that pertain to RTP would > also need to > address this. > > IMO this is a can of worms. So my opinion is that these > should *not* > be used with non-RTP m-lines, with or without bundle. > > Note that data channel is a special case. While we have > agreed not > to consider it for now, it is possible, in principle, to > run RTP > over a data channel. If that were defined then these > attributes > would also be needed. But then they would not be used as > media-level > attributes. Instead, they would be dcsa attributes. > > Thanks, > Paul > > *From:*mmusic [mailto:mmusic-bounces@ietf.org > > >] *On Behalf Of *Christer > Holmberg > *Sent:* 16 February 2017 19:07 > *To:* Eric Rescorla >>; mmusic > WG > >> > *Subject:* Re: [MMUSIC] Issue #27: Allow RTP > attributes in > non-media m= > sections > > > > Hi, > > * * > > *>*See: > > > https://github.com/cdh4u/draft-sdp-bundle/issues/27 > > > > > > > https://github.com/rtcweb-wg/jsep/issues/528 > > > > > > > > The basic issue is that it's possible to have a > situation > where you > > have both > > media and data m= sections but the BUNDLE tag is > associated > with the data > > > m= section and now you need to put the TRANSPORT and > IDENTICAL > > > attributes somewhere. The JSEP editors discussed > this and > came to the > > > conclusion that it should go with the BUNDLE tag > (i.e., in > the data m= > > section) > > and that BUNDLE should forbid this, but it > requires a change > to BUNDLE. > > > > > Did you mean to say that BUNDLE should NOT forbid this? > > > > Based on your GitHub discussion, my understanding is > that you > want to > allow to include RTP-specific parameters > (‘rtcp-mux’, ‘rtcp’, > ‘rtcp-mux-only’ attributes etc) in the data m= section. > > > > To repeat what I said on GitHub: > > > > This has been discussed in the past, and the outcome > has been to now > allow RTP-specific parameters in non-RTP m= sections. > > > > A solution would be to simply change the bundle tag > when the RTP m= > sections are added. > > > > …OR, we change the mux category for the RTP-specific > parameters. > But, > that of course means they have to be added to every > RTP m= section. > > > > Regards, > > > > Christer > > > _______________________________________________ > 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 Sat Feb 18 14:29:05 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D63129654 for ; Sat, 18 Feb 2017 14:29:04 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0azgB2URShUj for ; Sat, 18 Feb 2017 14:29:02 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6649129651 for ; Sat, 18 Feb 2017 14:29:01 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id l19so36883568ywc.2 for ; Sat, 18 Feb 2017 14:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t1HhagNj8so7TA2N9JiDckrow2onIi2ZVo/Nlne/bWo=; b=2A/o/bxrIWRXP9ZSx1ojFVElLHb0679tkZTQbIBD9+p/fMMjd4xfNwbZU6L7coQyAA d+Q/p8KKTGelNYuJEbqY5JVu+N5JYxNUV8irPDtED0VcLCjrqeIyTeCMNSn/zh7Zi5v1 oTJNGEovSRmHdyprJ0wf/s3ctgunt2+PHGUdgXpZYARyeM5PpynHAWINim7oiNJuru1S MpdnmwsByt6eSE9db6AqNQIhAzwOcb1CpqOzc84u0iqUFDg/6KHwWYTTOtkvCpM9pZNv v+oTb2S9370MifiVRQVIog7QNRwv6MAj6Ys7x4LTjCjb4bxq150jLMNcQLKSO+ZyzRGi 2NpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t1HhagNj8so7TA2N9JiDckrow2onIi2ZVo/Nlne/bWo=; b=rLLAuqKLNuxaG6LNBM2s5RDWqzQpowA9DrOVznvY692gqNZozMwkt5/ELA5rLsztjF 88sZ4MBhn3abf1Sqf2oyHe9p/SkxtpMyXRj8vTs/Sw1cFQEnxJ7RfvKDEyGLJoJ/FGa1 bEhk3qvK2mbniYShaRqkWuoSiz4cup8u8wIfexDHhCL0P5MMeumiZqMsRX/1KIexIyy9 xcAwjcHoXksPwme0quEWrKcFxheBUeE9C/3djiKCF9C6+k+2mINjSMAwG0KLwSVCmFib f9cVmFddtamgeXnw2NTuwQVG0ScpDHoZHnSYZk9L3+tq2Ovk1sB4fluMecEPZjJ9KEZ0 j/wQ== X-Gm-Message-State: AMke39koPYLfP+d1J7mS9aen5CK3BrvC2MlZ8b5oJfbFyl37GYHF+h2q7dlWdGyAujyDlmLX7FxY4f+5Gybn8g== X-Received: by 10.129.137.129 with SMTP id z123mr11722046ywf.327.1487456940826; Sat, 18 Feb 2017 14:29:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.153.200 with HTTP; Sat, 18 Feb 2017 14:28:20 -0800 (PST) In-Reply-To: <7df97f84-613d-2f5c-2290-aca82621f5ba@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0076FE@ESESSMB209.ericsson.se> <66341809-4c3e-2989-5039-a3369c0fa503@alum.mit.edu> <7df97f84-613d-2f5c-2290-aca82621f5ba@alum.mit.edu> From: Eric Rescorla Date: Sat, 18 Feb 2017 14:28:20 -0800 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=94eb2c06bf3893dc220548d58e5b Archived-At: Cc: IETF MMUSIC WG , Christer Holmberg Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 22:29:04 -0000 --94eb2c06bf3893dc220548d58e5b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Feb 18, 2017 at 1:38 PM, Paul Kyzivat wrote= : > On 2/18/17 1:45 PM, Eric Rescorla wrote: > >> >> >> On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat > > wrote: >> >> On 2/18/17 4:35 AM, Christer Holmberg wrote: >> >> Hi, >> >> I invite anyone who has a suggestion on text that needs to be >> modified/added/removed to provide a pull request (or send text >> to the list) to do so; in draft-bundle, draft-mux-attributes, >> and/or any other specification... >> >> >> IMO it doesn't make sense to put attributes on one bundled m-line >> that only apply to some other bundled m-line - current or future. >> >> >> Why? The whole principle is that they are supposed to span all the m=3D >> lines. >> > > They are supposed to span all the m-lines in the bundle that it is > meaningful for them to be used with. > Yes, and so it doesn't matter which one they are attached to. The closest thing we currently have to this situation is session-level > attributes. Some of those are defined as valid at both session and media > level, and that the value at session level is a default for media level. > These in some sense need to be evaluated in the context of every m-line, > even the ones where they aren't defined. > > But we have no standard rule for these. Every attribute needs to say if i= t > is defined at session level and if that should be treated as a default fo= r > a value at media level. And in the process it is specifying (at least > implicitly) which m-lines it applies to. > > In principle this could also be done for all the attributes that are to b= e > identical in bundles. But that means making all the changes to do that, a= nd > maintain it in the future. Huh? We already have a document that analyzes every single attribute and tells you how it is to be handled ( https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-16) and tells you how to hoist stuff from one m=3D line to all of them. And we're already handling it that way if the m=3D line associated with the bundle tag is a media section. The only difference is how it's handled if it's a data section. -Ekr As an alternative, how about picking the first tag in the bundle >> attribute that identifies an m-line of an appropriate type to carry >> the attribute? >> >> Seems much more complicated to implement and specify. >> >> To conserve e-mails, responding to Christer as well here: I don't think >> we need to update any of the relevant RFCs (other than potentially >> putting them in some >> useless Updates: line at the top of the doc). The idea here is that >> BUNDLE overrides them for cases where it applies. >> > > Again, maybe it is possible to craft some words that clearly and precisel= y > state how this is to work, in a general way without taking it one attribu= te > at a time. But I want to see them. > > Then we can discuss whether that is simpler than what I suggested above. > > Thanks, > Paul > > -Ekr >> >> >> Thanks, >> Paul >> >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu >> ] >> Sent: 17 February 2017 18:51 >> To: Taylor Brandstetter > > >> Cc: Christer Holmberg > >; IETF MMUSIC WG >> > >> Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in >> non-media m=3D sections >> >> On 2/16/17 9:27 PM, Taylor Brandstetter wrote: >> >> So, to make this work I think it will be necessary to >> ammend the >> definitions of the particular attributes to specify this >> usage. And >> then future new attributes that pertain to RTP would >> also need to >> address this. >> >> >> sdp-mux-attributes already amends the definitions of these >> attributes, >> such that a TRANSPORT attribute in m=3D section "A" can be >> used for >> media described by m=3D section "B". So, I don't see why it >> couldn't go >> a step further, and explicitly allow TRANSPORT and IDENTICAL >> category >> attributes to appear in m=3D sections with proto values not >> normally >> used with those attributes. >> >> >> I will reserve judgement until I see specific text. >> >> Thanks, >> Paul >> >> On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat >> >> > >> >> wrote: >> >> On 2/16/17 12:10 PM, Christer Holmberg wrote: >> >> Hi Paul, >> >> I assume you have an opinion on this :) >> >> The suggestion is to allow RTP-specific parameters >> (SDP rtcp-mux >> attributes etc) in non-RTP m=3D lines (e.g., data >> channel). >> >> >> This is a nasty issue. >> >> The problem with allowing this is: what do these >> parameters *mean* >> when so attached? And where do I look to find out? >> >> I'm not certain if they are currently permitted or not. >> AFAIK there >> is no *general* mechanism for specifying with which >> proto values a >> particular attribute may be used. I haven't studied the >> definitions >> of the "RTP-related" attributes to see if they make a >> specific >> statement about this. My guess is that they don't, but >> that they >> only define the meaning in the context of an RTP session= . >> >> If that is so, perhaps the rule that unknown attributes >> are to be >> ignored should apply to those attributes when used with >> a non-RTP >> media section. But if that rule were to apply, then we >> would expect >> that with O/A the rules for how these attributes in an >> offer affect >> what goes in the answer would not apply. I guess that >> won't be >> sufficient here. >> >> So, to make this work I think it will be necessary to >> ammend the >> definitions of the particular attributes to specify this >> usage. And >> then future new attributes that pertain to RTP would >> also need to >> address this. >> >> IMO this is a can of worms. So my opinion is that these >> should *not* >> be used with non-RTP m-lines, with or without bundle. >> >> Note that data channel is a special case. While we have >> agreed not >> to consider it for now, it is possible, in principle, to >> run RTP >> over a data channel. If that were defined then these >> attributes >> would also be needed. But then they would not be used as >> media-level >> attributes. Instead, they would be dcsa attributes. >> >> Thanks, >> Paul >> >> *From:*mmusic [mailto:mmusic-bounces@ietf.org >> >> > >] *On Behalf Of *Christer >> Holmberg >> *Sent:* 16 February 2017 19:07 >> *To:* Eric Rescorla > > >>; mmusic >> WG >> >> >> >> *Subject:* Re: [MMUSIC] Issue #27: Allow RTP >> attributes in >> non-media m=3D >> sections >> >> >> >> Hi, >> >> * * >> >> *>*See: >> >> >> https://github.com/cdh4u/draft-sdp-bundle/issues/27 >> >> >> > > >> >> >> https://github.com/rtcweb-wg/jsep/issues/528 >> >> > > >> >> >> >> >> The basic issue is that it's possible to have a >> situation >> where you >> >> have both >> >> media and data m=3D sections but the BUNDLE tag = is >> associated >> with the data >> >> >> m=3D section and now you need to put the TRANSPO= RT >> and >> IDENTICAL >> >> >> attributes somewhere. The JSEP editors discussed >> this and >> came to the >> >> >> conclusion that it should go with the BUNDLE tag >> (i.e., in >> the data m=3D >> >> section) >> >> and that BUNDLE should forbid this, but it >> requires a change >> to BUNDLE. >> >> >> >> >> Did you mean to say that BUNDLE should NOT forbid >> this? >> >> >> >> Based on your GitHub discussion, my understanding is >> that you >> want to >> allow to include RTP-specific parameters >> (=E2=80=98rtcp-mux=E2=80=99, =E2=80=98rtcp=E2=80=99, >> =E2=80=98rtcp-mux-only=E2=80=99 attributes etc) in t= he data m=3D >> section. >> >> >> >> To repeat what I said on GitHub: >> >> >> >> This has been discussed in the past, and the outcome >> has been to now >> allow RTP-specific parameters in non-RTP m=3D sectio= ns. >> >> >> >> A solution would be to simply change the bundle tag >> when the RTP m=3D >> sections are added. >> >> >> >> =E2=80=A6OR, we change the mux category for the RTP-= specific >> parameters. >> But, >> that of course means they have to be added to every >> RTP m=3D section. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> _______________________________________________ >> 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 >> >> >> >> > --94eb2c06bf3893dc220548d58e5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Feb 18, 2017 at 1:38 PM, Paul Kyzivat <pkyzivat@alum.mit.e= du> wrote:
On 2/18/17 1:45 PM, Eric Rescorla wrote:


On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
 <mailto:pkyzi= vat@alum.mit.edu>> wrote:

=C2=A0 =C2=A0 On 2/18/17 4:35 AM, Christer Holmberg wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I invite anyone who has a suggestion on text th= at needs to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 modified/added/removed to provide a pull reques= t (or send text
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to the list) to do so; in draft-bundle, draft-m= ux-attributes,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and/or any other specification...


=C2=A0 =C2=A0 IMO it doesn't make sense to put attributes on one bundle= d m-line
=C2=A0 =C2=A0 that only apply to some other bundled m-line - current or fut= ure.


Why? The whole principle is that they are supposed to span all the m=3D lin= es.

They are supposed to span all the m-lines in the bundle that it is meaningf= ul for them to be used with.

Yes, and s= o it doesn't matter which one they are attached to.


The closest thing we currently have to this situation is session-level attr= ibutes. Some of those are defined as valid at both session and media level,= and that the value at session level is a default for media level. These in= some sense need to be evaluated in the context of every m-line, even the o= nes where they aren't defined.

But we have no standard rule for these. Every attribute needs to say if it = is defined at session level and if that should be treated as a default for = a value at media level. And in the process it is specifying (at least impli= citly) which m-lines it applies to.

In principle this could also be done for all the attributes that are to be = identical in bundles. But that means making all the changes to do that, and= maintain it in the future.

Huh? We already= have a document that analyzes every single attribute and tells you how it<= /div>
tells you how to hoist stuff f= rom one m=3D line to all of them. And we're already handling
= it that way if the m=3D line associated with the bundle tag is a media sect= ion. The only
difference is how it's handled if it's a da= ta section.

-Ekr

=C2=A0 =C2=A0 As an alternative, how about picking the first tag in the bun= dle
=C2=A0 =C2=A0 attribute that identifies an m-line of an appropriate type to= carry
=C2=A0 =C2=A0 the attribute?

Seems much more complicated to implement and specify.

To conserve e-mails, responding to Christer as well here: I don't think=
we need to update any of the relevant RFCs (other than potentially
putting them in some
useless Updates: line at the top of the doc). The idea here is that
BUNDLE overrides them for cases where it applies.

 Again, maybe it is possible to craft some words that clearly and precisely = state how this is to work, in a general way without taking it one attribute= at a time. But I want to see them.

Then we can discuss whether that is simpler than what I suggested above.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

-Ekr


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


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Christer

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Original Message-----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:pkyzivat@alum.mit.edu>]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent: 17 February 2017 18:51
=C2=A0 =C2=A0 =C2=A0 =C2=A0 To: Taylor Brandstetter <deadbeef@google.com
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:deadbeef@google.com>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cc: Christer Holmberg <christer.holmberg@ericsson.c= om
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:christer.holmberg@ericsson.com>= >; IETF MMUSIC WG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mmusic@ietf.org <mailto:mmusic@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP = attributes in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 non-media m=3D sections

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 2/16/17 9:27 PM, Taylor Brandstetter wrote:<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 So, to make this wo= rk I think it will be necessary to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ammend the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definitions of the = particular attributes to specify this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 usage. And
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 then future new att= ributes that pertain to RTP would
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 also need to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address this.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sdp-mux-attributes already amends= the definitions of these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attributes,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such that a TRANSPORT attribute i= n m=3D section "A" can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 used for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 media described by m=3D section &= quot;B". So, I don't see why it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 couldn't go
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a step further, and explicitly al= low TRANSPORT and IDENTICAL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 category
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attributes to appear in m=3D sect= ions with proto values not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 normally
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 used with those attributes.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I will reserve judgement until I see specific t= ext.

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Feb 16, 2017 at 3:50 PM, = Paul Kyzivat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:pkyzivat@alum.mit.edu

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:pkyzivat@alum.mit.edu>>= > wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 2/16/17 12:10 PM= , Christer Holmberg wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Pa= ul,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I ass= ume you have an opinion on this :)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The s= uggestion is to allow RTP-specific parameters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (SDP rtcp-mux
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attri= butes etc) in non-RTP m=3D lines (e.g., data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 channel).


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is a nasty iss= ue.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The problem with al= lowing this is: what do these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 parameters *mean*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when so attached? A= nd where do I look to find out?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I'm not certain= if they are currently permitted or not.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AFAIK there
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is no *general* mec= hanism for specifying with which
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 proto values a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 particular attribut= e may be used. I haven't studied the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definitions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the "RTP-re= lated" attributes to see if they make a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specific
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 statement about thi= s. My guess is that they don't, but
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that they
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 only define the mea= ning in the context of an RTP session.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If that is so, perh= aps the rule that unknown attributes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 are to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ignored should appl= y to those attributes when used with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a non-RTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 media section. But = if that rule were to apply, then we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 would expect
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that with O/A the r= ules for how these attributes in an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 offer affect
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 what goes in the an= swer would not apply. I guess that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 won't be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sufficient here.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 So, to make this wo= rk I think it will be necessary to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ammend the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definitions of the = particular attributes to specify this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 usage. And
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 then future new att= ributes that pertain to RTP would
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 also need to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address this.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IMO this is a can o= f worms. So my opinion is that these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 should *not*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be used with non-RT= P m-lines, with or without bundle.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Note that data chan= nel is a special case. While we have
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 agreed not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to consider it for = now, it is possible, in principle, to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 run RTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 over a data channel= . If that were defined then these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attributes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 would also be neede= d. But then they would not be used as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 media-level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attributes. Instead= , they would be dcsa attributes.

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *From= :*mmusic [mailto:mmusic-bounces@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mmusic-bounces@ietf.org>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <m= ailto:mmusic-b= ounces@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mmusic-bounces@ietf.org>= >] *On Behalf Of *Christer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Holmb= erg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *Sent= :* 16 February 2017 19:07
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *To:*= Eric Rescorla <ekr@rt= fm.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ekr@rtfm.com> <mailto:ekr@rtfm.com<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ekr@rtfm.com>>>; mmusic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WG &l= t;mmusic@ietf.org = <mailto:mmusic@ietf= .org>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *Subj= ect:* Re: [MMUSIC] Issue #27: Allow RTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attributes in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 non-m= edia m=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 secti= ons



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *>= *See:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https:/= /github.com/cdh4u/draft-sdp-bundle/issues/27
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <htt= ps://github.com/cdh4u/draft-sdp-bundle/issues/27>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <htt= ps://github.com/cdh4u/draft-sdp-bundle/issues/27
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <htt= ps://github.com/cdh4u/draft-sdp-bundle/issues/27>>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 https://github.com/rtcweb-wg/jsep/issues= /528
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://gi= thub.com/rtcweb-wg/jsep/issues/528>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <https://github.com/rtcweb-wg/jsep/is= sues/528
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://gi= thub.com/rtcweb-wg/jsep/issues/528>>




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 The basic issue is that it's possible to have a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 situation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 where you

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 have = both

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 media and data m=3D sections but the BUNDLE tag is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 associated
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 with the data


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 m=3D section and now you need to put the TRANSPORT and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IDENTICAL


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 attributes somewhere. The JSEP editors discussed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 came to the


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 conclusion that it should go with the BUNDLE tag
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (i.e., in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 the data m=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 secti= on)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 and that BUNDLE should forbid this, but it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 requires a change
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 to BUNDLE.




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Did y= ou mean to say that BUNDLE should NOT forbid this?



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Based= on your GitHub discussion, my understanding is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that you
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 want = to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 allow= to include RTP-specific parameters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (=E2=80=98rtcp-mux=E2=80=99, =E2= =80=98rtcp=E2=80=99,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2= =80=98rtcp-mux-only=E2=80=99 attributes etc) in the data m=3D section.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 To re= peat what I said on GitHub:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This = has been discussed in the past, and the outcome
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 has been to now
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 allow= RTP-specific parameters in non-RTP m=3D sections.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A sol= ution would be to simply change the bundle tag
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when the RTP m=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 secti= ons are added.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2= =80=A6OR, we change the mux category for the RTP-specific
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 parameters.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 But,<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that = of course means they have to be added to every
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RTP m=3D section.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Regar= ds,



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Chris= ter


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mmusic mailing list=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mmusic@ietf.org <mailto:mmusic@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = https://www.ietf.org/mailman/listinfo/mmusic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://ww= w.ietf.org/mailman/listinfo/mmusic>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinfo/mmusic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://ww= w.ietf.org/mailman/listinfo/mmusic>>




=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 mmusic mailing list
=C2=A0 =C2=A0 mmusic@i= etf.org <mailto:mmusic@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/mmusic
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/list= info/mmusic>




--94eb2c06bf3893dc220548d58e5b-- From nobody Sun Feb 19 02:04:40 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43AC129458 for ; Sun, 19 Feb 2017 02:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 MnANeX9Be2Ya for ; Sun, 19 Feb 2017 02:04:37 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1318129434 for ; Sun, 19 Feb 2017 02:04:36 -0800 (PST) Received: (qmail 13543 invoked from network); 19 Feb 2017 11:04:34 +0100 Received: from p5dec2b50.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.43.80) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Feb 2017 11:04:34 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Sun, 19 Feb 2017 11:04:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <41D72B07-0B15-47A9-A118-5C67670F9F4F@kuehlewind.net> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> To: Roman Shpount X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , The IESG , Christer Holmberg , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2017 10:04:39 -0000 Hi Roman, thanks again. And again I think more text is needed in the draft. Mirja > Am 16.02.2017 um 18:39 schrieb Roman Shpount = : >=20 > Hi All, >=20 > I think a little bit of background will help here. >=20 > UDP/DTLS/SCTP and TCP/DTLS/SCTP are designed to work with ICE (RFC = 5245). >=20 > In ICE environments, during the nomination process, end points go = through multiple candidate pairs, until the most preferred pair is = found. During this selection process, data can be sent as soon as the = first working pair is found, but the process still continues and = candidate pairs can change while data is sent. Furthermore, if end = points roam, for instance when mobile end point switches from mobile = internet to wifi, end points will initiate an ICE restart, which will = trigger a new nomination process between the new set of candidates and = likely result in new nominated candidiate pair. When these candidates = change, the same DTLS association continues to run, regardless whether = it is running over udp or tcp candidate pair. Because of this, ICE tcp = requires using RFC 4571 framing when sending data = (https://tools.ietf.org/html/rfc6544#section-10.1). Otherwise, if TLS = were used, a new TLS or DTLS session would be required every time = candidate pair switches between tcp and udp candidates. In order to = simplify transition between different underlying transports, DTLS is = used for both udp and tcp candidates and TCP/DTLS/SCTP transport tag is = defined to differentiate it from other protocols. >=20 > As far as TCP/DTLS/SCTP transport tag is concerned, please note that = ICE end points are supposed to send a re-INVITE after nomination process = is completed with the selected candidate address in the m=3D line. So, = if tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP = transport tag in the m=3D line. Also, any offers/answers after the ICE = nomination is complete, are supposed to send the currently selected = candidate in the m=3D line, which will also be TCP/DTLS/SCTP in case tcp = candidate is selected. >=20 > I hope this addresses your concern and explains why TCP/DTLS/SCTP is = defined instead of TLS/SCTP. >=20 > Regards, > _____________ > Roman Shpount >=20 > On Thu, Feb 16, 2017 at 10:24 AM, Christer Holmberg = wrote: > Hi, >=20 > =20 >=20 > =E2=80=A6 >=20 > =20 >=20 > >The only question is what should appear in the m=3D proto line. >=20 > =20 >=20 > Even if nobody puts it in the m=3D line, I think it=E2=80=99s useful = to keep it in the document, as it gives an overview how it=E2=80=99s = realized etc. >=20 > =20 >=20 > It doesn=E2=80=99t cause any harm to keep it, and it=E2=80=99s = =E2=80=9Cfuture proof=E2=80=9D IF someone wants to use it without ICE at = some point. >=20 > =20 >=20 > Regards, >=20 > =20 >=20 > Christer >=20 > =20 >=20 >=20 > > Am 16.02.2017 um 16:02 schrieb Eric Rescorla : > > > > As Christer says. This design is optimized for making the media = stack simpler, which > > using TLS here would not do. > > > > -Ekr > > > > > > > > > > On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg = wrote: > > Hi, > > > > = ---------------------------------------------------------------------- > > DISCUSS: > > = ---------------------------------------------------------------------- > > > > >>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP? > > >>> > > >> Because the way it is realized is by transporting SCTP on top of = DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and > > >> transporting DTLS on top of TCP (defined in RFC 4571). > > > > > > I got this but DTLS is a mapping to use TLS with UDP because UDP = is an unreliable datagram transport. If you use TCP, you > > > should use TLS. And rfc4571 is not a mapping of DTLS to TCP. > > > > The framing mechanism of RFC 4571 is used, with DTLS packets sent = instead of RTP packets. > > > > Regards, > > > > Christer > > > > >=20 > =20 >=20 >=20 From nobody Sun Feb 19 06:08:36 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0610E1296B7 for ; Sun, 19 Feb 2017 06:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 qjLBTMBsgc8J for ; Sun, 19 Feb 2017 06:08:33 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2196A1296B2 for ; Sun, 19 Feb 2017 06:08:32 -0800 (PST) Received: (qmail 25798 invoked from network); 19 Feb 2017 15:01:50 +0100 Received: from p5dec2b50.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.43.80) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Feb 2017 15:01:50 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <41D72B07-0B15-47A9-A118-5C67670F9F4F@kuehlewind.net> Date: Sun, 19 Feb 2017 15:02:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E30B705-9E74-4460-87D8-1395925B74F8@kuehlewind.net> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> <41D72B07-0B15-47A9-A118-5C67670F9F4F@kuehlewind.net> To: Roman Shpount X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , The IESG , Christer Holmberg , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2017 14:08:35 -0000 Hi again, actually I have one more mostly editorial comment. I would probably = recommend to not just say that the framing of rfc 4571 is used but = instead specify the framing in this draft (where you oft course still = can say that the framing is similar to 4571). The reason is that other = than the framing format itself the rest of rfc 4571 is not relevant = because you use SCTP on top. And again, it would probably also be good to talk a little more about = implication when you use SCTP on top of TCP, mostly regarding the two = layers of congestion control that you get. Mirja > Am 19.02.2017 um 11:04 schrieb Mirja Kuehlewind (IETF) = : >=20 > Hi Roman, >=20 > thanks again. And again I think more text is needed in the draft. >=20 > Mirja >=20 >=20 >> Am 16.02.2017 um 18:39 schrieb Roman Shpount = : >>=20 >> Hi All, >>=20 >> I think a little bit of background will help here. >>=20 >> UDP/DTLS/SCTP and TCP/DTLS/SCTP are designed to work with ICE (RFC = 5245). >>=20 >> In ICE environments, during the nomination process, end points go = through multiple candidate pairs, until the most preferred pair is = found. During this selection process, data can be sent as soon as the = first working pair is found, but the process still continues and = candidate pairs can change while data is sent. Furthermore, if end = points roam, for instance when mobile end point switches from mobile = internet to wifi, end points will initiate an ICE restart, which will = trigger a new nomination process between the new set of candidates and = likely result in new nominated candidiate pair. When these candidates = change, the same DTLS association continues to run, regardless whether = it is running over udp or tcp candidate pair. Because of this, ICE tcp = requires using RFC 4571 framing when sending data = (https://tools.ietf.org/html/rfc6544#section-10.1). Otherwise, if TLS = were used, a new TLS or DTLS session would be required every time = candidate pair switches between tcp and udp candidates. In order to = simplify transition between different underlying transports, DTLS is = used for both udp and tcp candidates and TCP/DTLS/SCTP transport tag is = defined to differentiate it from other protocols. >>=20 >> As far as TCP/DTLS/SCTP transport tag is concerned, please note that = ICE end points are supposed to send a re-INVITE after nomination process = is completed with the selected candidate address in the m=3D line. So, = if tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP = transport tag in the m=3D line. Also, any offers/answers after the ICE = nomination is complete, are supposed to send the currently selected = candidate in the m=3D line, which will also be TCP/DTLS/SCTP in case tcp = candidate is selected. >>=20 >> I hope this addresses your concern and explains why TCP/DTLS/SCTP is = defined instead of TLS/SCTP. >>=20 >> Regards, >> _____________ >> Roman Shpount >>=20 >> On Thu, Feb 16, 2017 at 10:24 AM, Christer Holmberg = wrote: >> Hi, >>=20 >>=20 >>=20 >> =E2=80=A6 >>=20 >>=20 >>=20 >>> The only question is what should appear in the m=3D proto line. >>=20 >>=20 >>=20 >> Even if nobody puts it in the m=3D line, I think it=E2=80=99s useful = to keep it in the document, as it gives an overview how it=E2=80=99s = realized etc. >>=20 >>=20 >>=20 >> It doesn=E2=80=99t cause any harm to keep it, and it=E2=80=99s = =E2=80=9Cfuture proof=E2=80=9D IF someone wants to use it without ICE at = some point. >>=20 >>=20 >>=20 >> Regards, >>=20 >>=20 >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>> Am 16.02.2017 um 16:02 schrieb Eric Rescorla : >>>=20 >>> As Christer says. This design is optimized for making the media = stack simpler, which >>> using TLS here would not do. >>>=20 >>> -Ekr >>>=20 >>>=20 >>>=20 >>>=20 >>> On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg = wrote: >>> Hi, >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>>>>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP? >>>>>>=20 >>>>> Because the way it is realized is by transporting SCTP on top of = DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and >>>>> transporting DTLS on top of TCP (defined in RFC 4571). >>>>=20 >>>> I got this but DTLS is a mapping to use TLS with UDP because UDP is = an unreliable datagram transport. If you use TCP, you >>>> should use TLS. And rfc4571 is not a mapping of DTLS to TCP. >>>=20 >>> The framing mechanism of RFC 4571 is used, with DTLS packets sent = instead of RTP packets. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >=20 From nobody Sun Feb 19 08:46:27 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE5F129847 for ; Sun, 19 Feb 2017 08:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=turbobridge.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wskIZ4VDfG2k for ; Sun, 19 Feb 2017 08:46:22 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D56C129801 for ; Sun, 19 Feb 2017 08:46:20 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id l66so16115876ioi.1 for ; Sun, 19 Feb 2017 08:46:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=turbobridge.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hevHb0x24hBINl5HBi6hENC8o7IjVjN8F+J6FxFVMC0=; b=b08ZjC91lQLaDlXf0PI3FNZwBIzrOwyzr67uX8+1IfywUFJ4OmR1kbmFisBbqy6juC d7a4+NhvxuRfPSOhRuLtlVYcIO3nGIJxV8z3Ggr86qTzihkA3Esjorl+1Tk6z+4q0gCn nRTv39FVtQCJshbpM5pDA8MZptUS/B5TFp8r4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hevHb0x24hBINl5HBi6hENC8o7IjVjN8F+J6FxFVMC0=; b=Elfe0Ad6L+iW9kHu7f7ZUxgo3gC7fTD1W4oHzo8YsBGlhrky45IntyukC5UYt+06fr 4Iz4yw/JIQ8ncfzH8ZX8IJpuG/+p3DAlYcALDitkJPhXnM+7u1g/2nfEBiczSYwCHsGE nD3SG6+cd/awHQxY3UrQ6hlZwGH7cYqUe1FtVf9kNpuy/F1q45lOpYwtmbry++yUpIp5 ZTYLyb+QYIODH/jHlRVz4LWzb0SHEs7M/COmcLnf/qYo9luEQxVebVGM+ARfD1KBOpfP CpjdAHeic2mBsnCnhxDUfC5lGeYSMCmjrp2Ikn42nKIi9D6BMqfPLaRbR+oVJTsHgNro XKdw== X-Gm-Message-State: AMke39mU7Pql+BODckCR0lJs/k/LN7D8nBIdg1t4JgpWG6QG2GckkzIyObfhNlvNVbM8ow== X-Received: by 10.107.199.130 with SMTP id x124mr13501980iof.216.1487522779615; Sun, 19 Feb 2017 08:46:19 -0800 (PST) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com. [209.85.214.52]) by smtp.gmail.com with ESMTPSA id a4sm7952514ioa.43.2017.02.19.08.46.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Feb 2017 08:46:18 -0800 (PST) Received: by mail-it0-f52.google.com with SMTP id 203so2906842ith.0; Sun, 19 Feb 2017 08:46:18 -0800 (PST) X-Received: by 10.36.79.71 with SMTP id c68mr9868771itb.47.1487522778629; Sun, 19 Feb 2017 08:46:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.233.3 with HTTP; Sun, 19 Feb 2017 08:46:18 -0800 (PST) In-Reply-To: <1E30B705-9E74-4460-87D8-1395925B74F8@kuehlewind.net> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> <41D72B07-0B15-47A9-A118-5C67670F9F4F@kuehlewind.net> <1E30B705-9E74-4460-87D8-1395925B74F8@kuehlewind.net> From: Roman Shpount Date: Sun, 19 Feb 2017 11:46:18 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: multipart/alternative; boundary=001a11449e02d0d12e0548e4e29d Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , The IESG , Christer Holmberg , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2017 16:46:23 -0000 --001a11449e02d0d12e0548e4e29d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mirja, As I have mentioned before, protocols described in this draft are intended to work with ICE. The framing for ICE TCP is defined in RFC 6544 ( https://tools.ietf.org/html/rfc6544#section-10.1) and this document explicitly specifies RFC 4571 framing. The same document describes why the same framing must be used for RTP, STUN or non-RTP media, such as DTLS packets carrying SCTP. Current draft simply restates the framing requirement from RFC 6544 and defines a protocol that will satisfy RFC 6544 requirements. Because of this, and because the framing must be identical for all the protocols that use ICE TCP, we cannot re-define the framing in this draft. The definition must stay in the same place, so that any changes made to framing are verified to be compatible with other protocols which are using it and will propagate to these protocols as well. We are happy to add any informational content to describe the implications of running SCTP on top of TCP, but we would prefer not to redefine how ICE operates (including framing used for ICE TCP) in this draft. I think, generic ICE procedures belong in ICE related drafts. Regards, _____________ Roman Shpount On Sun, Feb 19, 2017 at 9:02 AM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > Hi again, > > actually I have one more mostly editorial comment. I would probably > recommend to not just say that the framing of rfc 4571 is used but instea= d > specify the framing in this draft (where you oft course still can say tha= t > the framing is similar to 4571). The reason is that other than the framin= g > format itself the rest of rfc 4571 is not relevant because you use SCTP o= n > top. > > And again, it would probably also be good to talk a little more about > implication when you use SCTP on top of TCP, mostly regarding the two > layers of congestion control that you get. > > Mirja > > > > > > Am 19.02.2017 um 11:04 schrieb Mirja Kuehlewind (IETF) < > ietf@kuehlewind.net>: > > > > Hi Roman, > > > > thanks again. And again I think more text is needed in the draft. > > > > Mirja > > > > > >> Am 16.02.2017 um 18:39 schrieb Roman Shpount >: > >> > >> Hi All, > >> > >> I think a little bit of background will help here. > >> > >> UDP/DTLS/SCTP and TCP/DTLS/SCTP are designed to work with ICE (RFC > 5245). > >> > >> In ICE environments, during the nomination process, end points go > through multiple candidate pairs, until the most preferred pair is found. > During this selection process, data can be sent as soon as the first > working pair is found, but the process still continues and candidate pair= s > can change while data is sent. Furthermore, if end points roam, for > instance when mobile end point switches from mobile internet to wifi, end > points will initiate an ICE restart, which will trigger a new nomination > process between the new set of candidates and likely result in new > nominated candidiate pair. When these candidates change, the same DTLS > association continues to run, regardless whether it is running over udp o= r > tcp candidate pair. Because of this, ICE tcp requires using RFC 4571 > framing when sending data (https://tools.ietf.org/html/ > rfc6544#section-10.1). Otherwise, if TLS were used, a new TLS or DTLS > session would be required every time candidate pair switches between tcp > and udp candidates. In order to simplify transition between different > underlying transports, DTLS is used for both udp and tcp candidates and > TCP/DTLS/SCTP transport tag is defined to differentiate it from other > protocols. > >> > >> As far as TCP/DTLS/SCTP transport tag is concerned, please note that > ICE end points are supposed to send a re-INVITE after nomination process = is > completed with the selected candidate address in the m=3D line. So, if tc= p > candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP transpor= t > tag in the m=3D line. Also, any offers/answers after the ICE nomination i= s > complete, are supposed to send the currently selected candidate in the m= =3D > line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected. > >> > >> I hope this addresses your concern and explains why TCP/DTLS/SCTP is > defined instead of TLS/SCTP. > >> > >> Regards, > >> _____________ > >> Roman Shpount > >> > >> On Thu, Feb 16, 2017 at 10:24 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, > >> > >> > >> > >> =E2=80=A6 > >> > >> > >> > >>> The only question is what should appear in the m=3D proto line. > >> > >> > >> > >> Even if nobody puts it in the m=3D line, I think it=E2=80=99s useful t= o keep it > in the document, as it gives an overview how it=E2=80=99s realized etc. > >> > >> > >> > >> It doesn=E2=80=99t cause any harm to keep it, and it=E2=80=99s =E2=80= =9Cfuture proof=E2=80=9D IF > someone wants to use it without ICE at some point. > >> > >> > >> > >> Regards, > >> > >> > >> > >> Christer > >> > >> > >> > >> > >>> Am 16.02.2017 um 16:02 schrieb Eric Rescorla : > >>> > >>> As Christer says. This design is optimized for making the media stack > simpler, which > >>> using TLS here would not do. > >>> > >>> -Ekr > >>> > >>> > >>> > >>> > >>> On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >>> Hi, > >>> > >>> ---------------------------------------------------------------------= - > >>> DISCUSS: > >>> ---------------------------------------------------------------------= - > >>> > >>>>>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP? > >>>>>> > >>>>> Because the way it is realized is by transporting SCTP on top of > DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and > >>>>> transporting DTLS on top of TCP (defined in RFC 4571). > >>>> > >>>> I got this but DTLS is a mapping to use TLS with UDP because UDP is > an unreliable datagram transport. If you use TCP, you > >>>> should use TLS. And rfc4571 is not a mapping of DTLS to TCP. > >>> > >>> The framing mechanism of RFC 4571 is used, with DTLS packets sent > instead of RTP packets. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >> > >> > >> > >> > > > > --001a11449e02d0d12e0548e4e29d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mirja,

As I have mentioned before, prot= ocols described in this draft are intended to work with ICE. The framing fo= r ICE TCP is defined in RFC 6544 (https://tools.ietf.org/html/rfc6544#section-10.1) a= nd this document explicitly specifies RFC 4571 framing. The same document d= escribes why the same framing must be used for RTP, STUN or non-RTP media, = such as DTLS packets carrying SCTP. Current draft simply restates the frami= ng requirement from RFC 6544 and defines a protocol that will satisfy RFC 6= 544 requirements. Because of this, and because the framing must be identica= l for all the protocols that use ICE TCP, we cannot re-define the framing i= n this draft. The definition must stay in the same place, so that any chang= es made to framing are verified to be compatible with other protocols which= are using it and will propagate to these protocols as well.

=
We are happy to add any informational content to describe the im= plications of running SCTP on top of TCP, but we would prefer not to redefi= ne how ICE operates (including framing used for ICE TCP) in this draft. I t= hink, generic ICE procedures belong in ICE related drafts.

Regards,

<= div>
_____= ________
Roman Shpount

On Sun, Feb 19, 2017 at 9:02 AM, Mirja Kuehl= ewind (IETF) <ietf@kuehlewind.net> wrote:
Hi again,

actually I have one more mostly editorial comment. I would probably recomme= nd to not just say that the framing of rfc 4571 is used but instead specify= the framing in this draft (where you oft course still can say that the fra= ming is similar to 4571). The reason is that other than the framing format = itself the rest of rfc 4571 is not relevant because you use SCTP on top.
And again, it would probably also be good to talk a little more about impli= cation when you use SCTP on top of TCP, mostly regarding the two layers of = congestion control that you get.

Mirja




> Am 19.02.2017 um 11:04 schrieb Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>:
>
> Hi Roman,
>
> thanks again. And again I think more text is needed in the draft.
>
> Mirja
>
>
>> Am 16.02.2017 um 18:39 schrieb Roman Shpount <rshpount@turbobridge.com>:
>>
>> Hi All,
>>
>> I think a little bit of background will help here.
>>
>> UDP/DTLS/SCTP and TCP/DTLS/SCTP are designed to work with ICE (RFC= 5245).
>>
>> In ICE environments, during the nomination process, end points go = through multiple candidate pairs, until the most preferred pair is found. D= uring this selection process, data can be sent as soon as the first working= pair is found, but the process still continues and candidate pairs can cha= nge while data is sent. Furthermore, if end points roam, for instance when = mobile end point switches from mobile internet to wifi, end points will ini= tiate an ICE restart, which will trigger a new nomination process between t= he new set of candidates and likely result in new nominated candidiate pair= . When these candidates change, the same DTLS association continues to run,= regardless whether it is running over udp or tcp candidate pair. Because o= f this, ICE tcp requires using RFC 4571 framing when sending data (https://tools.ietf.org/html/rfc6544#section-10.1).= Otherwise, if TLS were used, a new TLS or DTLS session would be required e= very time candidate pair switches between tcp and udp candidates. In order = to simplify transition between different underlying transports, DTLS is use= d for both udp and tcp candidates and TCP/DTLS/SCTP transport tag is define= d to differentiate it from other protocols.
>>
>> As far as TCP/DTLS/SCTP transport tag is concerned, please note th= at ICE end points are supposed to send a re-INVITE after nomination process= is completed with the selected candidate address in the m=3D line. So, if = tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP transp= ort tag in the m=3D line. Also, any offers/answers after the ICE nomination= is complete, are supposed to send the currently selected candidate in the = m=3D line, which will also be TCP/DTLS/SCTP in case tcp candidate is select= ed.
>>
>> I hope this addresses your concern and explains why TCP/DTLS/SCTP = is defined instead of TLS/SCTP.
>>
>> Regards,
>> _____________
>> Roman Shpount
>>
>> On Thu, Feb 16, 2017 at 10:24 AM, Christer Holmberg <christer.holmberg@ericsson.com= > wrote:
>> Hi,
>>
>>
>>
>> =E2=80=A6
>>
>>
>>
>>> The only question is what should appear in the m=3D proto line= .
>>
>>
>>
>> Even if nobody puts it in the m=3D line, I think it=E2=80=99s usef= ul to keep it in the document, as it gives an overview how it=E2=80=99s rea= lized etc.
>>
>>
>>
>> It doesn=E2=80=99t cause any harm to keep it, and it=E2=80=99s =E2= =80=9Cfuture proof=E2=80=9D IF someone wants to use it without ICE at some = point.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>>
>>
>>
>>> Am 16.02.2017 um 16:02 schrieb Eric Rescorla <ekr@rtfm.com>:
>>>
>>> As Christer says. This design is optimized for making the medi= a stack simpler, which
>>> using TLS here would not do.
>>>
>>> -Ekr
>>>
>>>
>>>
>>>
>>> On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg <christer.holmberg@ericsson.= com> wrote:
>>> Hi,
>>>
>>> ---------------------------------------------------------= -------------
>>> DISCUSS:
>>> ---------------------------------------------------------= -------------
>>>
>>>>>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS= /SCTP?
>>>>>>
>>>>> Because the way it is realized is by transporting SCTP= on top of DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and<= br> >>>>> transporting DTLS on top of TCP (defined in RFC 4571).=
>>>>
>>>> I got this but DTLS is a mapping to use TLS with UDP becau= se UDP is an unreliable datagram transport. If you use TCP, you
>>>> should use TLS. And rfc4571 is not a mapping of DTLS to TC= P.
>>>
>>> The framing mechanism of RFC 4571 is used, with DTLS packets s= ent instead of RTP packets.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>
>>
>>
>>
>


--001a11449e02d0d12e0548e4e29d-- From nobody Sun Feb 19 16:20:10 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF1A1295EE for ; Sun, 19 Feb 2017 16:20:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOnl2KwyhEgc for ; Sun, 19 Feb 2017 16:20:06 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85FEA1295B4 for ; Sun, 19 Feb 2017 16:20:06 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id v186so64000081wmd.0 for ; Sun, 19 Feb 2017 16:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=77sQCE4MFzOmFQMBPEwxnXModNkxfQWdXOGspL5+o3c=; b=Gm1ARu3ttg0P1aoxVjCISNJSb2PgOCV41D62KK5+3Rgu76Qqa2RIBDwdDlthLul9+b A/v435kgZL9HBmqAg2uTP2y6ZTdPiQ49nNbDsrtL0bdKpQkXDe1xOVjRJLR0lUs+hOsU 0rluecdoV4tYTvggH+oamQCO+XxgOZ/6W9Eq99aWbWBnKwhvFChB0jgML9xWcznzAuQE puxkM7x+WQjDo/ByQPjNu2pwN+2gsaEwwLKC4apyVgZceGsCKEPd250J1aZ5QNkT8pD1 OmrxQFeIy98Ybfx3rJvU7iRSEBlVQXPQxhVTZvADl2J5NLGCxD0IIfcCj0XcNBiQTWd8 FplA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=77sQCE4MFzOmFQMBPEwxnXModNkxfQWdXOGspL5+o3c=; b=KPDnkEIZW7eUPT3MNzfW73BzkLT577n9Aw+WWJ0CJVfZ46TdsfZSYy4n+Dxko1cqSB 3l4HvVGJvUoHbzHHmXyPOYTQ2Zw/UMCyEUsQq/ENDWnE6b/tdAncB4DAYLaCDL3EkLG2 7iYrctErcRLIPbK21252vGNNIuQ1bNrPJ5i99G/FYO9eAe+bVdD1Pxaf/e8JSpMvj697 6HwNfSz77vXRpJtCQMDiTq1vq5W8CNeA7a7xuXMfKou+IIBj8Z19eMHusymdpPFLsZu0 0/HBTzdXdVn/lpkOwl9tM43dkLoRRtjw8hhaYbZfvLKn688bIGZHtJtcSGE28/iHpRhQ +S1A== X-Gm-Message-State: AMke39m1aX/w/lBuf4K8mYEeUvj365wQ+H+yH7rVufIDW5mvRv2zftRTPVP1pgHcPnUOH+hMabgp2yMdQk/1eQ== X-Received: by 10.28.97.2 with SMTP id v2mr16387343wmb.3.1487550004900; Sun, 19 Feb 2017 16:20:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.182.85 with HTTP; Sun, 19 Feb 2017 16:19:44 -0800 (PST) In-Reply-To: References: <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4C004589@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Feb 2017 01:19:44 +0100 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ben Campbell , mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 00:20:09 -0000 2017-02-16 18:38 GMT+01:00 Eric Rescorla : > I also think the re-INVITE is unnecessary. Such a re-INVITE is like "hey, we have agreed on a candidate pair by using ICE procedures and, hence, now I send you a message confirming it to you, which is totally useless because you already know that". --=20 I=C3=B1aki Baz Castillo From nobody Sun Feb 19 18:42:24 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3738129623 for ; Sun, 19 Feb 2017 18:42:23 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmHsdDlcwKTZ for ; Sun, 19 Feb 2017 18:42:21 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F35D129629 for ; Sun, 19 Feb 2017 18:42:21 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id y135so12615545itc.1 for ; Sun, 19 Feb 2017 18:42:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4Pmkxa3L5a4x0V7EfO1JfeMA/9H4sVU810xL3f1Imbo=; b=dTIh8jM3uTAHr2guUwU+jVDgiY7mTzj4+zkCEUHVe4PxpvMDV1giWlW3vZdxsnKeO/ lbPa72N3BXA5koiXy8JC/P9xybpSHs4iH8a69T47eBuJyZkFyeXitySi0LrpXEth7TOm KTWmJxbtcg/Qs9bWYjbSraL3MCSM/W1pTIRXUBjXGBKGLR5uLtHFYOeqtAnZQbwulCkQ VMLlCsydjQkLcuJsW0EOpuB+gnD5G34ndka1Km+hKNeTjCwPAO5w8f+d6VsKazyhsnZA nau4EvXOOTI0KSrnAJkSAUr9lz5lSnbzK2cr1vr7n4jFsqFUjBAh4kQW/VxCf1wq6Yrd rX3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4Pmkxa3L5a4x0V7EfO1JfeMA/9H4sVU810xL3f1Imbo=; b=MGRptD2QHz0P0L3HaeDEQxM7mTX3MCreyYTr5ymXSLsJG5KuKSu82jGx8jMeUZB3x7 uGsS9MHgY23KNV6ezQKxceSMKC71MVNBYJYlJ1dvmzlOmQ2XAA9dt+EKoofbrE59It7v mY2cLIcmx+rE/I3wwvd7awuaHMf+WLTFxvoSsFjYrer5Ry0Jo8g1UyvQQVYXBmlI9/v3 wQn7sax1nIHpOv769+oUhn56R9iNhDEBzIcWpYbEoRm8eZr5QIj05kOb+8jb5XW4dbXP Z9EOuI4k5QeynpS9cCGLEDC6z6mF1SQEP5wyjDFXCQBTa4dQ6k+q70xMNH3O/C864It6 Hp+Q== X-Gm-Message-State: AMke39loDtwV5eQfGzotwqxpm9Qj3vuevS/kjQHqwOFrZ+4rcEqLV61eCS+jOR9SP6QzkQ== X-Received: by 10.36.123.136 with SMTP id q130mr18893465itc.25.1487558540706; Sun, 19 Feb 2017 18:42:20 -0800 (PST) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com. [209.85.214.42]) by smtp.gmail.com with ESMTPSA id l3sm8481549ioa.31.2017.02.19.18.42.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Feb 2017 18:42:19 -0800 (PST) Received: by mail-it0-f42.google.com with SMTP id y135so12615294itc.1 for ; Sun, 19 Feb 2017 18:42:19 -0800 (PST) X-Received: by 10.36.219.3 with SMTP id c3mr7694718itg.52.1487558538941; Sun, 19 Feb 2017 18:42:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.233.3 with HTTP; Sun, 19 Feb 2017 18:42:18 -0800 (PST) In-Reply-To: References: <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4C004589@ESESSMB209.ericsson.se> From: Roman Shpount Date: Sun, 19 Feb 2017 21:42:18 -0500 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=94eb2c05fe704c020e0548ed36ed Archived-At: Cc: Ben Campbell , mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 02:42:24 -0000 --94eb2c05fe704c020e0548ed36ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As it was mentioned before, this is not only the re-INVITE caused by ICE completion, but also any re-INVITE after ICE nomination completes. So, any re-INVITE sent, for instance to update the codecs, which does not initiate ICE restart will have one ICE candidate and will use the appropriate transport in the m=3D line. We have a current ICE specification and this is how it works. I agree we can update ICE SDP specification to define ICE transport tag, which will allow us to stop all this nonsense. Until this is done we need transport tags for both UDP and TCP ICE candidates. The discussed draft (draft-ietf-mmusic-sctp-sdp) is not the right place to update ICE specifications and we do want to finish it before all the ICE updates. Regards, _____________ Roman Shpount On Sun, Feb 19, 2017 at 7:19 PM, I=C3=B1aki Baz Castillo wr= ote: > 2017-02-16 18:38 GMT+01:00 Eric Rescorla : > > I also think the re-INVITE is unnecessary. > > Such a re-INVITE is like "hey, we have agreed on a candidate pair by > using ICE procedures and, hence, now I send you a message confirming > it to you, which is totally useless because you already know that". > > > -- > I=C3=B1aki Baz Castillo > > --94eb2c05fe704c020e0548ed36ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As it was mentioned before, this is not only the re-INVITE= caused by ICE completion, but also any re-INVITE after ICE nomination comp= letes. So, any re-INVITE sent, for instance to update the codecs, which doe= s not initiate ICE restart will have one ICE candidate and will use the app= ropriate transport in the m=3D line. We have a current ICE specification an= d this is how it works. I agree we can update ICE SDP specification to defi= ne ICE transport tag, which will allow us to stop all this nonsense. Until = this is done we need transport tags for both UDP and TCP ICE candidates. Th= e discussed draft=C2=A0(draft-ietf-mmusic-sctp-sdp) is not the right place = to update ICE specifications and we do want to finish it before all the ICE= updates.

Regards,
_____________
Roman Shpount

On Sun, Feb 19, 2017 at 7:19 PM, I=C3=B1aki = Baz Castillo <ibc@aliax.net> wrote:
2017-02-16 18:38 GMT+01:00= Eric Rescorla <ekr@rtfm.com>: > I also think the re-INVITE is unnecessary.

Such a re-INVITE is like "hey, we have agreed on a candidate pa= ir by
using ICE procedures and, hence, now I send you a message confirming
it to you, which is totally useless because you already know that".

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

--94eb2c05fe704c020e0548ed36ed-- From nobody Mon Feb 20 01:49:24 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CB812960C; Mon, 20 Feb 2017 01:49: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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 YkAlpEm-5o9J; Mon, 20 Feb 2017 01:49:17 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE81128B38; Mon, 20 Feb 2017 01:49:16 -0800 (PST) Received: from [192.168.111.218] ([88.190.148.61]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v1K9n6wt042820 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 20 Feb 2017 03:49:09 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [88.190.148.61] claimed to be [192.168.111.218] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (14D27) In-Reply-To: Date: Mon, 20 Feb 2017 10:49:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <86C5D8B5-40B6-4228-BF10-00BF9DFEB93C@nostrum.com> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> <41D72B07-0B15-47A9-A118-5C67670F9F4F@kuehlewind.net> <1E30B705-9E74-4460-87D8-1395925B74F8@kuehlewind.net> To: Roman Shpount Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , "Mirja Kuehlewind \(IETF\)" , The IESG , Christer Holmberg , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 09:49:18 -0000 >=20 > On Feb 19, 2017, at 5:46 PM, Roman Shpount wrot= e: >=20 [...] > We are happy to add any informational content to describe the implications= of running SCTP on top of TCP, but we would prefer not to redefine how ICE o= perates (including framing used for ICE TCP) in this draft. I think, generic= ICE procedures belong in ICE related drafts. I agree in principle; this draft is about signaling, not the media stream it= self. But Mirja's comments suggest that the referenced specs may not fully d= escribe how the stream works. Is there anything else we could reference (e.g= . RTCWEB data-channel or transports drafts) that would help clarify? (Plea= se feel free to argue that the referenced docs do in fact describe things su= fficiently for the purposes of this draft, if you believe that to be true :-= ) ) Thanks, Ben.= From nobody Mon Feb 20 03:12:06 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A0B129999 for ; Mon, 20 Feb 2017 03:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 5IjEF2_j0ZOD for ; Mon, 20 Feb 2017 03:12:02 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D05A1299AA for ; Mon, 20 Feb 2017 03:12:00 -0800 (PST) Received: (qmail 25854 invoked from network); 20 Feb 2017 12:05:18 +0100 Received: from vpn-global-dhcp3-197.ethz.ch (129.132.210.197) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Feb 2017 12:05:18 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <86C5D8B5-40B6-4228-BF10-00BF9DFEB93C@nostrum.com> Date: Mon, 20 Feb 2017 12:05:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <492F1BF9-2F1C-4D16-8B9B-B9FD13592E13@kuehlewind.net> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> <41D72B07-0B15-47A9-A118-5C67670F9F4F@kuehlewind.net> <1E30B705-9E74-4460-87D8-1395925B74F8@kuehlewind.net> <86C5D8B5-40B6-4228-BF10-00BF9DFEB93C@nostrum.com> To: Roman Shpount X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , Ben Campbell , "fandreas@cisco.com" , The IESG , Christer Holmberg , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 11:12:03 -0000 Hi Roman, I think the problem is that someone who would not want to use ICE would = not look at RFC6544. This means at least this part of RFC6544 is missing = as general guidance in this draft: "For media streams that are not RTP-based and do not normally use=20 RFC4571, the agent treats the media stream as a byte stream and = assumes that it has its own framing of some sort, if needed. It then takes an arbitrary number of bytes from the byte stream and places that as a payload in the RFC 4571 frames, including the length." Usually duplicating text is not recommendable. However it this case it = might be the easiest solution if you want to keep the document generally = applicable even if you don=E2=80=99t use ICE.=20 Also I=E2=80=99m not sure if the ICE part is fully specified. In your = previously mail you wrote "As far as TCP/DTLS/SCTP transport tag is concerned, please note that = ICE end points are supposed to send a re-INVITE after nomination process = is completed with the selected candidate address in the m=3D line. So, = if tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP = transport tag in the m=3D line. Also, any offers/answers after the ICE = nomination is complete, are supposed to send the currently selected = candidate in the m=3D line, which will also be TCP/DTLS/SCTP in case tcp = candidate is selected.=E2=80=9C =46rom what I understood from ekr, you might not in any case send an = re-invite; but maybe I understood this wrongly. I guess that could also = be further explained in the draft. Mirja > Am 20.02.2017 um 10:49 schrieb Ben Campbell : >=20 >>=20 >> On Feb 19, 2017, at 5:46 PM, Roman Shpount = wrote: >>=20 >=20 > [...] >=20 >> We are happy to add any informational content to describe the = implications of running SCTP on top of TCP, but we would prefer not to = redefine how ICE operates (including framing used for ICE TCP) in this = draft. I think, generic ICE procedures belong in ICE related drafts. >=20 > I agree in principle; this draft is about signaling, not the media = stream itself. But Mirja's comments suggest that the referenced specs = may not fully describe how the stream works. Is there anything else we = could reference (e.g. RTCWEB data-channel or transports drafts) that = would help clarify? (Please feel free to argue that the referenced docs = do in fact describe things sufficiently for the purposes of this draft, = if you believe that to be true :-) ) >=20 >=20 > Thanks, >=20 > Ben. From nobody Fri Feb 24 09:17:04 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A670129422 for ; Fri, 24 Feb 2017 09:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4VdA5GAMud5 for ; Fri, 24 Feb 2017 09:17:02 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA11129421 for ; Fri, 24 Feb 2017 09:17:01 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id s205so13621507oif.3 for ; Fri, 24 Feb 2017 09:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=stV0oshd8fGDoVJhZhw0Ewd68x0K8WrtjJ3dlrjVbwo=; b=Ju165isAiRm8pGvwMi6C/5D/cCJqY+Hn/Nqqn1SFxSl1MKeG+tL4viOkjWR3FNOb0U Zy/CVdXZnoA7qWeu1bbYjBKaRVrtK6TbwEdxXzw2oJDT8B4c00l+4m6xavhSwAm59SpL R7cAgTEAdwgpP11hEcVyjgHMYRIpSEtC6btiShVwBwnKLgd3pog/Tb2DyKBQNYXfnci9 sPPa2bETPYKkrTUNW5O1QGAvAclDunU8PGyu3h4u2eKeO+k8EeHE5Zy7zX4/hj3w2Ysk CWWq6pDKB5wzvhiPZnHK2FwGkyI/pUf6YJURALVZE3nKswWCnhU9cOe/WgterwbsuiyL 5ZAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=stV0oshd8fGDoVJhZhw0Ewd68x0K8WrtjJ3dlrjVbwo=; b=knKs8pHQyUMcb1xMuDCnxCATsbTel8CmiiDOwDEF3eFJv05zPr/Oloqcc8NTbXxqon YJmctBffyZW79xe6wputYBTtYodFrJ/Pi7Z3DRvHv++B0bjfWFo2gUJPRaDWHqG4XA7+ hX4p3Z7KUDoJUrTU8byP0xHsaCz2lo1fuSEWjKSK5V3MWhhZBGYnTdgDAfUN+dRTgBVq v6m8Qb/wEFWuUd1Ne+6qriZXciuO7wp5HZJ3c9bQQYYmvbmB2zVyz+wpBi49MxYjheNC eGwh6QE5vd7CuQPlZl/HS7b+tUHSTa10txuZbSn/2qocKoPfFu6ZgcNh1NjooIUqxTOp GkPg== X-Gm-Message-State: AMke39mHRp3v9Q8xSZm07xmUJVwcaqmqZMutqVGCrp+irJmhrFQOMH9344ynzXO9f1T2sg== X-Received: by 10.202.5.5 with SMTP id 5mr2188281oif.141.1487956621060; Fri, 24 Feb 2017 09:17:01 -0800 (PST) Received: from ?IPv6:2602:301:77fd:e0a0:f535:2b3a:977f:cf04? ([2602:301:77fd:e0a0:f535:2b3a:977f:cf04]) by smtp.googlemail.com with ESMTPSA id 5sm3046672oig.38.2017.02.24.09.17.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 09:17:00 -0800 (PST) To: mmusic WG From: Byron Campen Message-ID: <73e087ca-a179-a571-0431-d580392e0439@gmail.com> Date: Fri, 24 Feb 2017 11:16:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] A corner-case: Rejection/change of bundle tag, bundle-only, and trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:17:03 -0000 Let's say we have an offer like the following (very pruned down, for clarity). Note that it is using trickle ICE, and no candidates have been gathered yet. a=group:BUNDLE 1 2 3 m=audio 9 ... a=mid:1 ... m=video 9 ... a=mid:2 ... m=application 0 ... a=mid:3 a=bundle-only ... I see a couple of questions here about what transport (if any) mid 3 uses: * What happens if the answerer rejects mid 1? (2 seems reasonable?) * What happens if the answerer moves mid 1 out of the bundle? (2 seems reasonable?) * What happens if the answerer rejects both mid 1 and 2? (Uh oh...) * What happens for combinations of rejecting mids, and moving them out of the bundle? (Oh fun...) From the signaling alone, it is not always clear to the offerer which mid the answerer has chosen to use for transport stuff, so saying the answerer chooses arbitrarily doesn't quite solve the problem. I suppose the offerer could wait for the first trickle candidate, and use the mid specified there (provided it is valid, which I'm not sure has been adequately specified...). Best regards, Byron Campen From nobody Fri Feb 24 11:08:03 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBBE1294D1 for ; Fri, 24 Feb 2017 11:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooElj6V50i92 for ; Fri, 24 Feb 2017 11:08:00 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789AB1294CF for ; Fri, 24 Feb 2017 11:08:00 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id x71so26641788qkb.3 for ; Fri, 24 Feb 2017 11:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4vWKDP0j9aiXwvcK0TR+y85bSJ9huM0G/7crqa5fB0g=; b=BVH2Q26WonoMHI8KUyVJglIGyfKCZgNKVrOUlucobElZO0qrWtBXqXhNIZbYNMiCle TEHym0atKkrh+5adywsYlP/IPOXDyPci7/KVoUtXQ63JguXExWqTUi/sCcFpvVjLCngO TIL2jVvt6yPGDTD5yetijoneQ1q7Cd+vQf/5XwyrZQ4RDn4BlQR2m0UYECIJeVUiz/KH eHTtghVi/fV0V3czL0V/aOD6xKgRjhM6y97by0V1WH3RtRC4DmHpSKE+p1k0uivoyJaw kGpfKqxC4MFUJ9yOT9NYFub2SJ9tRX/kibqiO8D/Rn2ggRl73JCFyCPmPfUc0nlbMJhD V8yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4vWKDP0j9aiXwvcK0TR+y85bSJ9huM0G/7crqa5fB0g=; b=puTd/vRyXIQm2XsniJMH/isw/vuf9eMKR/raEx6kGis8JM7qmuYR4Wy9anKWEkgYLU QU128m4V4IY8/mda7YpmoCe9ldJ+XSNUkroVFbZjF6gAsbJ0QrXDrzcz0ILOBBWO0PSQ k20tK+5HBq7kDsaEHJTG+F40UxcjODK1bqvGF+b1nNpW9YYtIimCP9lCb5cbowU0eFUJ 5H4Qk9EdLp2R8IGxqLTslddET+drlQFctsWHU7mbCtbNWkxARi7sBLfk96Rb22ATfboa AfB0KFtQnZKWOUl1x9Wl5P3XRQmTK6+7+29Cv6ZfKEJ+bpfxh9VmAZUzqsmNIZt/VvKj WcRQ== X-Gm-Message-State: AMke39lLCxNv3jVcHW60kPoZiYhdhwoJoCFS7rrnhqa9htwZPCycbO6aiNRWqLq4Dk35DWE6fNQYBaA1johx/T/r X-Received: by 10.55.166.81 with SMTP id p78mr4245426qke.142.1487963279246; Fri, 24 Feb 2017 11:07:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.38.163 with HTTP; Fri, 24 Feb 2017 11:07:58 -0800 (PST) In-Reply-To: <73e087ca-a179-a571-0431-d580392e0439@gmail.com> References: <73e087ca-a179-a571-0431-d580392e0439@gmail.com> From: Taylor Brandstetter Date: Fri, 24 Feb 2017 11:07:58 -0800 Message-ID: To: Byron Campen Content-Type: multipart/alternative; boundary=94eb2c06e24cb3499805494b7292 Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] A corner-case: Rejection/change of bundle tag, bundle-only, and trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 19:08:02 -0000 --94eb2c06e24cb3499805494b7292 Content-Type: text/plain; charset=UTF-8 > What happens if the answerer rejects mid 1? (2 seems reasonable?) As currently specified: 2 > What happens if the answerer moves mid 1 out of the bundle? (2 seems reasonable?) As currently specified: 2 > What happens if the answerer rejects both mid 1 and 2? (Uh oh...) As currently specified: This isn't supported. I discussed these sorts of issues with Christer here: https://github.com/cdh4u/draft-sdp-bundle/issues/21 And here: https://github.com/cdh4u/draft-sdp-bundle/issues/22 And the conclusion so far is, "you should make sure the m= section things are bundled on isn't one that's likely to be rejected". > What happens for combinations of rejecting mids, and moving them out of the bundle? (Oh fun...) Whichever one ends up as the "answerer BUNDLE tag", aka the first tag in "a=group:BUNDLE" in the answer, ends up being used. And this can't be the mid of something that was "a=bundle-only" in the offer (see above). On Fri, Feb 24, 2017 at 9:16 AM, Byron Campen wrote: > Let's say we have an offer like the following (very pruned down, for > clarity). Note that it is using trickle ICE, and no candidates have been > gathered yet. > > a=group:BUNDLE 1 2 3 > > m=audio 9 ... > > a=mid:1 > > ... > > m=video 9 ... > > a=mid:2 > > ... > > m=application 0 ... > > a=mid:3 > > a=bundle-only > > ... > > > I see a couple of questions here about what transport (if any) mid 3 uses: > > * What happens if the answerer rejects mid 1? (2 seems reasonable?) > > * What happens if the answerer moves mid 1 out of the bundle? (2 seems > reasonable?) > > * What happens if the answerer rejects both mid 1 and 2? (Uh oh...) > > * What happens for combinations of rejecting mids, and moving them out of > the bundle? (Oh fun...) > > From the signaling alone, it is not always clear to the offerer which > mid the answerer has chosen to use for transport stuff, so saying the > answerer chooses arbitrarily doesn't quite solve the problem. I suppose the > offerer could wait for the first trickle candidate, and use the mid > specified there (provided it is valid, which I'm not sure has been > adequately specified...). > > Best regards, > > Byron Campen > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c06e24cb3499805494b7292 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> What happens if the = answerer rejects mid 1? (2 seems reasonable?)

As = currently specified: 2

> What= happens if the answerer moves mid 1 out of the bundle? (2 seems reasonable= ?)

As currently specified: 2

> What happens if the answerer rejects both mid 1 and 2? (Uh oh...)=

As currently specified: This isn't sup= ported.

I discussed these sorts of issues with Chr= ister here: https://github.com/cdh4u/draft-sdp-bundle/issues/21

And= the conclusion so far is, "you should make sure the m=3D section thin= gs are bundled on isn't one that's likely to be rejected".

>= What happens for combinations of rejecting mids, and moving them out of th= e bundle? (Oh fun...)

Whichever one ends up as the "answerer BUNDLE tag", aka t= he first tag in "a=3Dgroup:BUNDLE" in the answer, ends up being u= sed. And this can't be the mid of something that was "a=3Dbundle-o= nly" in the offer (see above).

On Fri, Feb 24, 2017 at 9:16 AM, Byron= Campen <docfaraday@gmail.com> wrote:
=C2=A0 =C2=A0 Let's say we have an offer like the follow= ing (very pruned down, for clarity). Note that it is using trickle ICE, and= no candidates have been gathered yet.

a=3Dgroup:BUNDLE 1 2 3

m=3Daudio 9 ...

a=3Dmid:1

...

m=3Dvideo 9 ...

a=3Dmid:2

...

m=3Dapplication 0 ...

a=3Dmid:3

a=3Dbundle-only

...


I see a couple of questions here about what transport (if any) mid 3 uses:<= br>
* What happens if the answerer rejects mid 1? (2 seems reasonable?)

* What happens if the answerer moves mid 1 out of the bundle? (2 seems reas= onable?)

* What happens if the answerer rejects both mid 1 and 2? (Uh oh...)

* What happens for combinations of rejecting mids, and moving them out of t= he bundle? (Oh fun...)

=C2=A0 =C2=A0 From the signaling alone, it is not always clear to the offer= er which mid the answerer has chosen to use for transport stuff, so saying = the answerer chooses arbitrarily doesn't quite solve the problem. I sup= pose the offerer could wait for the first trickle candidate, and use the mi= d specified there (provided it is valid, which I'm not sure has been ad= equately specified...).

Best regards,

Byron Campen

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

--94eb2c06e24cb3499805494b7292-- From nobody Fri Feb 24 11:27:10 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC111294E1 for ; Fri, 24 Feb 2017 11:27:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6Icl6bZAZCc for ; Fri, 24 Feb 2017 11:27:06 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAABC1294E3 for ; Fri, 24 Feb 2017 11:27:05 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id j38so20561369otb.3 for ; Fri, 24 Feb 2017 11:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=vBC5DPRIhoA3dCTevdR0L2+ljvPsHXyihrP/NOZhNWw=; b=rn+mGqbzQxzbt0gDQgvk21DiI8I4YUuzbViKmLW2TnHLVFc4lUMOyGlVa8mI0T6v16 OPtU7MEB66lWx3/A2ue09yf2p6jgQToPOcbsC2O02Zf0PrH2PcK21+4tXeQ7kRLu8CKb 4oGPDoLUJ4F+XQEQIbxDSInn3Y9CfY1rcWomHK6yfV/YnIwGe7WEip1EzbianNkyBZpu vWQG7Si6MUN27bjHJNOUMsi8rz6FAdc9quJ2wUp1ksRmP297bZeKkKzKyydKSWHvJXnq BFip1tf3C/wuzfCp/HbO1uYHs+8KY8g6zzK/czPgPuvfWFq1kWyLJ1bmiXef4JqtTE34 UqYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=vBC5DPRIhoA3dCTevdR0L2+ljvPsHXyihrP/NOZhNWw=; b=NVYmGc8E++/VjId/BD3Hk6NPHZQiv5YNT3Jb0bYXyVIJ4Ac9gs9CpoKF7+5W1Hm3VE AZbKQuO8hXaVPdcAT/kkU22De20Dh9oikdOW1UMuW6/OQ+DiAZZdIUxLcpaZhuSHsGo4 1oFZGGqHRvbVQYRA+TGPdnYnFXzQUnqsLCu771OigiOVgi2kSEm0KoPw3+8ytd47mXZJ hOcxfhQTFHfiKJslfjhmE8ovyv4484B9oVjG9jlc2cYH7WIYGfuvmsxUWr0AP6WWYF94 J8JhgreZHiDHwpTo9QJ3q63DIFzEtDAhZZXKJXFzPVbZ21mvA+Ge1N06RMMTOLtFdnoF 6Eyg== X-Gm-Message-State: AMke39kYLUwk5p7KBHimfmGnaMulYnVOfPoWco0AHmAHmyerAqmp49NoGCT5JefRqC540w== X-Received: by 10.157.25.140 with SMTP id k12mr2884974otk.174.1487964425339; Fri, 24 Feb 2017 11:27:05 -0800 (PST) Received: from ?IPv6:2602:301:77fd:e0a0:f535:2b3a:977f:cf04? ([2602:301:77fd:e0a0:f535:2b3a:977f:cf04]) by smtp.googlemail.com with ESMTPSA id m35sm3099189otm.43.2017.02.24.11.27.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 11:27:04 -0800 (PST) To: Taylor Brandstetter References: <73e087ca-a179-a571-0431-d580392e0439@gmail.com> From: Byron Campen Message-ID: Date: Fri, 24 Feb 2017 13:27:03 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9C7B986D59BD72C1220EF1DF" Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] A corner-case: Rejection/change of bundle tag, bundle-only, and trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 19:27:09 -0000 This is a multi-part message in MIME format. --------------9C7B986D59BD72C1220EF1DF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/24/17 1:07 PM, Taylor Brandstetter wrote: > > And the conclusion so far is, "you should make sure the m= section > things are bundled on isn't one that's likely to be rejected". Oof. That's a pretty bad gotcha... Best regards, Byron Campen --------------9C7B986D59BD72C1220EF1DF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/24/17 1:07 PM, Taylor Brandstetter wrote:

And the conclusion so far is, "you should make sure the m= section things are bundled on isn't one that's likely to be rejected".

    Oof. That's a pretty bad gotcha...

Best regards,
Byron Campen
--------------9C7B986D59BD72C1220EF1DF-- From nobody Mon Feb 27 04:20:33 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0454129E51 for ; Mon, 27 Feb 2017 04:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 mFaKF4Ppkf_n for ; Mon, 27 Feb 2017 04:20:31 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B95129E63 for ; Mon, 27 Feb 2017 04:20:30 -0800 (PST) X-AuditID: c1b4fb3a-ae2b298000007c1e-9d-58b4198ccb91 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id E7.24.31774.C8914B85; Mon, 27 Feb 2017 13:20:28 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0319.002; Mon, 27 Feb 2017 13:20:26 +0100 From: Christer Holmberg To: Byron Campen , Taylor Brandstetter Thread-Topic: [MMUSIC] A corner-case: Rejection/change of bundle tag, bundle-only, and trickle ICE Thread-Index: AQHSjsHTRjELw7Me80+nfdYuVIM/+6F4dFcAgAAFVYCABGIBgA== Date: Mon, 27 Feb 2017 12:20:25 +0000 Message-ID: References: <73e087ca-a179-a571-0431-d580392e0439@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D4D9E61F18658christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM2J7uG6P5JYIg3fXZSwur3jIajHxwA9G i6nLH7M4MHvsnHWX3WPBplKPJUt+MgUwR3HZpKTmZJalFunbJXBlrHv3krVgEm/FzyeH2RsY F3B3MXJySAiYSDR33WTqYuTiEBJYxyhx9+1yRghnMaPEiaZrQBkODjYBC4nuf9ogDSICIRJb j3QygdjMAvISF5asAbOFBZIlnvxpYIOoSZF4dGIpC4TtJPHz8lF2EJtFQFXi9ZuDrCA2r4C1 xMyvd5ghdm1jlLj54jJYglPAVmLukRlgDYwCYhLfT62BWiYucevJfCaIqwUkluw5zwxhi0q8 fPwPrFdUQE9i+fM1UHFFiZ1n25khehMkTi3dzw6xWFDi5MwnLBMYRWchGTsLSdksJGUQcR2J Bbs/sUHY2hLLFr5mhrHPHHgM1WstsaF/KSuymgWMHKsYRYtTi4tz042M9FKLMpOLi/Pz9PJS SzYxAmPz4JbfVjsYDz53PMQowMGoxMP7IXZzhBBrYllxZe4hRgkOZiUR3pZvQCHelMTKqtSi /Pii0pzU4kOM0hwsSuK8ZivvhwsJpCeWpGanphakFsFkmTg4pRoYdS/rT/b+H7s/xiXQ+s2t /18/XdL2Y5HNv7jEf3G9V5TTFcOjSrXH3ETOC1/cXVaXnuTHxjnt+g7GQ6uYzxz56yAtFf6R 8WDYtlWv/QTDhdM3aW+2So6QvfXwCe/3UylCnJZ33wYtkD+muD4kvLhavVvL/HV0D/8rrXen D56amGJ/f0lt5/VbSizFGYmGWsxFxYkABSNcwMkCAAA= Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] A corner-case: Rejection/change of bundle tag, bundle-only, and trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 12:20:32 -0000 --_000_D4D9E61F18658christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >> And the conclusion so far is, "you should make sure the m=3D section thi= ngs are bundled on isn't one that's likely to be rejected". > > Oof. That's a pretty bad gotcha... Just to clarify: this is a design design decision that was made when the bu= ndle-only concept was introduced. Regards, Christer --_000_D4D9E61F18658christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

>> And the conclusion so far is, "you should ma= ke sure the m=3D section things are bundled on isn't one that's likely to b= e rejected".
>
> Oof. That's a pretty bad gotcha...

Just to clarify: this is a design design decision that was made when t= he bundle-only concept was introduced.

Regards,

Christer
--_000_D4D9E61F18658christerholmbergericssoncom_-- From nobody Mon Feb 27 05:07:01 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5297D129F46; Mon, 27 Feb 2017 05:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 EhviSvH4iRMV; Mon, 27 Feb 2017 05:06:59 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8627F1298BA; Mon, 27 Feb 2017 05:06:58 -0800 (PST) X-AuditID: c1b4fb2d-973309800000393f-fc-58b4246fd3f3 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id B7.7E.14655.F6424B85; Mon, 27 Feb 2017 14:06:56 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0319.002; Mon, 27 Feb 2017 14:06:00 +0100 From: Christer Holmberg To: "Mirja Kuehlewind (IETF)" , Roman Shpount Thread-Topic: =?iso-8859-1?Q?Mirja_K=FChlewind's_Discuss_on_draft-ietf-mmusic-sctp-sdp-?= =?iso-8859-1?Q?23:_(with_DISCUSS)?= Thread-Index: AQHSiEaxS+qNKsn/A0y+WNY+OfKww6Frs1fQ///1IwCAABFeUP//8EEAgAAA4YCAAAH3gIAAE4kggAAVhACABDfnAIAAQksAgAAt4QCAAR3EAIAAFWGAgAtEKQA= Date: Mon, 27 Feb 2017 13:06:00 +0000 Message-ID: References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> <41D72B07-0B15-47A9-A118-5C67670F9F4F@kuehlewind.net> <1E30B705-9E74-4460-87D8-1395925B74F8@kuehlewind.net> <86C5D8B5-40B6-4228-BF10-00BF9DFEB93C@nostrum.com> <492F1BF9-2F1C-4D16-8B9B-B9FD13592E13@kuehlewind.net> In-Reply-To: <492F1BF9-2F1C-4D16-8B9B-B9FD13592E13@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <947CF61112D1604B8BA0FFA6F879B5EA@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsUyM2K7om6BypYIgy9H2S3md55mt3i1bj6z xYrX59gt3l/QtZjxZyKzxYvrH5ktzu9cz2QxdfljFovrT3exOHB6TPm9kdVjyZKfTB4tHxey esza+YTFY/LjNmaPrX//sgWwRXHZpKTmZJalFunbJXBlnHlxgrFgIUdFz/VzLA2MF9m6GDk5 JARMJG5+ecHexcjFISSwjlFi4p1JTBDOYkaJWV1dQA4HB5uAhUT3P22QBhGBeIk/e5qZQWqY BTYxSUz4fZERJCEsUCdxYNEFNoiieonXi96CTRUR6GKUuHz2MCtIgkVAVWLaokUsIDavgLXE vg1P2CC2NbFLHLj3Hmwbp4CTxO5+bpAaRgExie+n1jCB2MwC4hK3nsxngjhbQGLJnvPMELao xMvH/8DmiwroSSx/voYZZIyEgKLE8n45iFY9iRtTp7BB2NYSu/91MULY2hLLFr5mhjhHUOLk zCcsExjFZyHZNgtJ+ywk7bOQtM9C0r6AkXUVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmB0 H9zyW3cH4+rXjocYBTgYlXh4P8RujhBiTSwrrsw9xCjBwawkwvtcYUuEEG9KYmVValF+fFFp TmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxSDYyB1wWfPb9196eaMbu61dxGw5ZE L2NBrtsaB89X5uxriTqX/eACV0yvxNvM62eYL2bOFtodeDG5I2J58IMJ7lrxi0XYL1yrm9Aq q8mh71UvKvv5x30XzRt7k/bszirT0X396c6dS54rp/Ys7G1Vd23RO1kSuX1yj8EvybWT8k/8 5BRepKc2zU2JpTgj0VCLuag4EQCC+ePO6gIAAA== Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , Ben Campbell , "fandreas@cisco.com" , The IESG , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 13:07:00 -0000 Hi, ... >Also I=B9m not sure if the ICE part is fully specified. In your previously >mail you wrote > >"As far as TCP/DTLS/SCTP transport tag is concerned, please note that ICE >end points are supposed to send a re-INVITE after nomination process is >completed with the selected candidate address in the m=3D line. So, if tcp >candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP >transport tag in the m=3D line. Also, any offers/answers after the ICE >nomination is complete, are supposed to send the currently selected >candidate in the m=3D line, which will also be TCP/DTLS/SCTP in case tcp >candidate is selected.=B3 > >From what I understood from ekr, you might not in any case send an >re-invite; but maybe I understood this wrongly. I guess that could also >be further explained in the draft. Ekr was talking about the specific re-INVITE that is sent directly after ICE nomination. *Other* re-INVITEs can always be sent during the session. But, that is not specific to this draft. Regards, Christer From nobody Mon Feb 27 05:10:36 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82ABB129894 for ; Mon, 27 Feb 2017 05:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 foNOI_EsF1zT for ; Mon, 27 Feb 2017 05:10:31 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D919B12965D for ; Mon, 27 Feb 2017 05:10:30 -0800 (PST) X-AuditID: c1b4fb25-4b3ff70000007fa8-75-58b425443b64 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id CB.53.32680.44524B85; Mon, 27 Feb 2017 14:10:29 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0319.002; Mon, 27 Feb 2017 14:10:28 +0100 From: Christer Holmberg To: Eric Rescorla , Paul Kyzivat Thread-Topic: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections Thread-Index: AQHSiMV0wsnKqkRmGEuVhuugjvh/xaFtWdeAgAEo62CAAF3NgIAAK2mAgAAwa4CAAA3rAIANq1KA Date: Mon, 27 Feb 2017 13:10:28 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0076FE@ESESSMB209.ericsson.se> <66341809-4c3e-2989-5039-a3369c0fa503@alum.mit.edu> <7df97f84-613d-2f5c-2290-aca82621f5ba@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D4D9F20218680christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyM2J7uK6r6pYIg9YZXBaXVzxktVjx+hy7 xdTlj1ksVmw4wOrA4vH3/QcmjwWbSj2WLPnJ5DH5cRtzAEsUl01Kak5mWWqRvl0CV8aX/1tY C2YdYar4+nc3WwPj5CamLkZODgkBE4n/bSdYuhi5OIQE1jFK3Pt0mRHCWcwosfLgdyCHg4NN wEKi+582SIOIgJvE35kPGEFsZoFAifWLpoLZwgIhEvOndICViwiESmw5UglRHiXxc/l6VhCb RUBVYvqfTnYQm1fAWuL7uW6wG4QETrJKPNxvCNLKCTRy9p1ckDCjgJjE91NrmCA2iUvcejIf 6mQBiSV7zjND2KISLx//AxsvKqAnsfz5Gqi4ksSPDZdYQEYyCyRIdM61g9gqKHFy5hOWCYyi s5BMnYVQNQtJFUSJgcT7c/OZIWxtiWULX0PZ+hIbv5xlhGi1lvi0SBNZyQJGjlWMosWpxUm5 6UbGeqlFmcnFxfl5enmpJZsYgXF6cMtv1R2Ml984HmIU4GBU4uH9ELs5Qog1say4MvcQowQH s5II73OFLRFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEec1W3g8XEkhPLEnNTk0tSC2CyTJxcEo1 MJp+jrJhMyycttPoyN6DNzfOyDw3tfDrBN9sSaU2U/HXW6dJfzrYWmJ9e5K68qb+g/lbQhiq RT49eaWUKLPFu+usmZ0HK88lhwy3wm03bQrNzk21ELggzCSbqV4tPGn3tw2Xwgtd+pdfZAlm qVj6jL09atvslzHqa//sft+fUKt6Vrd0ZuD510osxRmJhlrMRcWJAFXlmnHPAgAA Archived-At: Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 13:10:34 -0000 --_000_D4D9F20218680christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Do people think we need to discuss this face-to-face in Chicago? Note that = I have currently NOT requested agenda time for BUNDLE. As far as document changes are concerned, we would AT LEAST need some clari= fication text in BUNDLE and/or draft-mux-attributes. Regards, Christer From: Eric Rescorla > Date: Sunday 19 February 2017 at 00:28 To: "pkyzivat@alum.mit.edu" > Cc: Christer Holmberg >, Taylor Brandstetter >, "mmusic@ietf.org" > Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m=3D= sections On Sat, Feb 18, 2017 at 1:38 PM, Paul Kyzivat > wrote: On 2/18/17 1:45 PM, Eric Rescorla wrote: On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat >> wrote: On 2/18/17 4:35 AM, Christer Holmberg wrote: Hi, I invite anyone who has a suggestion on text that needs to be modified/added/removed to provide a pull request (or send text to the list) to do so; in draft-bundle, draft-mux-attributes, and/or any other specification... IMO it doesn't make sense to put attributes on one bundled m-line that only apply to some other bundled m-line - current or future. Why? The whole principle is that they are supposed to span all the m=3D lin= es. They are supposed to span all the m-lines in the bundle that it is meaningf= ul for them to be used with. Yes, and so it doesn't matter which one they are attached to. The closest thing we currently have to this situation is session-level attr= ibutes. Some of those are defined as valid at both session and media level,= and that the value at session level is a default for media level. These in= some sense need to be evaluated in the context of every m-line, even the o= nes where they aren't defined. But we have no standard rule for these. Every attribute needs to say if it = is defined at session level and if that should be treated as a default for = a value at media level. And in the process it is specifying (at least impli= citly) which m-lines it applies to. In principle this could also be done for all the attributes that are to be = identical in bundles. But that means making all the changes to do that, and= maintain it in the future. Huh? We already have a document that analyzes every single attribute and te= lls you how it is to be handled (https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-att= ributes-16) and tells you how to hoist stuff from one m=3D line to all of them. And we're a= lready handling it that way if the m=3D line associated with the bundle tag is a media sect= ion. The only difference is how it's handled if it's a data section. -Ekr As an alternative, how about picking the first tag in the bundle attribute that identifies an m-line of an appropriate type to carry the attribute? Seems much more complicated to implement and specify. To conserve e-mails, responding to Christer as well here: I don't think we need to update any of the relevant RFCs (other than potentially putting them in some useless Updates: line at the top of the doc). The idea here is that BUNDLE overrides them for cases where it applies. Again, maybe it is possible to craft some words that clearly and precisely = state how this is to work, in a general way without taking it one attribute= at a time. But I want to see them. Then we can discuss whether that is simpler than what I suggested above. Thanks, Paul -Ekr Thanks, Paul Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu >] Sent: 17 February 2017 18:51 To: Taylor Brandstetter >> Cc: Christer Holmberg >>; IETF MMUSIC WG >> Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m=3D sections On 2/16/17 9:27 PM, Taylor Brandstetter wrote: So, to make this work I think it will be necessary to ammend the definitions of the particular attributes to specify this usage. And then future new attributes that pertain to RTP would also need to address this. sdp-mux-attributes already amends the definitions of these attributes, such that a TRANSPORT attribute in m=3D section "A" can be used for media described by m=3D section "B". So, I don't see why it couldn't go a step further, and explicitly allow TRANSPORT and IDENTICAL category attributes to appear in m=3D sections with proto values not normally used with those attributes. I will reserve judgement until I see specific text. Thanks, Paul On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat > >>> = wrote: On 2/16/17 12:10 PM, Christer Holmberg wrote: Hi Paul, I assume you have an opinion on this :) The suggestion is to allow RTP-specific parameters (SDP rtcp-mux attributes etc) in non-RTP m=3D lines (e.g., data channel). This is a nasty issue. The problem with allowing this is: what do these parameters *mean* when so attached? And where do I look to find out? I'm not certain if they are currently permitted or not. AFAIK there is no *general* mechanism for specifying with which proto values a particular attribute may be used. I haven't studied the definitions of the "RTP-related" attributes to see if they make a specific statement about this. My guess is that they don't, but that they only define the meaning in the context of an RTP session. If that is so, perhaps the rule that unknown attributes are to be ignored should apply to those attributes when used with a non-RTP media section. But if that rule were to apply, then we would expect that with O/A the rules for how these attributes in an offer affect what goes in the answer would not apply. I guess that won't be sufficient here. So, to make this work I think it will be necessary to ammend the definitions of the particular attributes to specify this usage. And then future new attributes that pertain to RTP would also need to address this. IMO this is a can of worms. So my opinion is that these should *not* be used with non-RTP m-lines, with or without bundle. Note that data channel is a special case. While we have agreed not to consider it for now, it is possible, in principle, to run RTP over a data channel. If that were defined then these attributes would also be needed. But then they would not be used as media-level attributes. Instead, they would be dcsa attributes. Thanks, Paul *From:*mmusic [mailto:mmusic-bounces@ietf.org = > = >>] *On Behalf Of *Christer Holmberg *Sent:* 16 February 2017 19:07 *To:* Eric Rescorla > >>>; mmusic WG > >>> *Subject:* Re: [MMUSIC] Issue #27: Allow RTP attributes in non-media m=3D sections Hi, * * *>*See: https://github.com/cdh4u/draft-sdp-bundle/issues/27 > https://github.com/rtcweb-wg/jsep/issues/528 > The basic issue is that it's possible to have a situation where you have both media and data m=3D sections but the BUNDLE tag is associated with the data m=3D section and now you need to put the TRANSPORT = and IDENTICAL attributes somewhere. The JSEP editors discussed this and came to the conclusion that it should go with the BUNDLE tag (i.e., in the data m=3D section) and that BUNDLE should forbid this, but it requires a change to BUNDLE. Did you mean to say that BUNDLE should NOT forbid this? Based on your GitHub discussion, my understanding is that you want to allow to include RTP-specific parameters (=91rtcp-mux=92, =91rtcp=92, =91rtcp-mux-only=92 attributes etc) in the data m=3D se= ction. To repeat what I said on GitHub: This has been discussed in the past, and the outcome has been to now allow RTP-specific parameters in non-RTP m=3D sections. A solution would be to simply change the bundle tag when the RTP m=3D sections are added. =85OR, we change the mux category for the RTP-specific parameters. But, that of course means they have to be added to every RTP m=3D section. Regards, Christer _______________________________________________ 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 --_000_D4D9F20218680christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8B1B219D28C7EA409EEBFC5E69302F65@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Do people think we need to discuss this face-to-face in Chicago? Note = that I have currently NOT requested agenda time for BUNDLE.

As far as document changes are concerned, we would AT LEAST need some = clarification text in BUNDLE and/or draft-mux-attributes.

Regards,

Christer

From: Eric Rescorla <ekr@rtfm.com>
Date: Sunday 19 February 2017 at 00= :28
To: "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Taylor Brandstetter <dead= beef@google.com>, "mmusic@ie= tf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] FW: Issue #27= : Allow RTP attributes in non-media m=3D sections



On Sat, Feb 18, 2017 at 1:38 PM, Paul Kyzivat <pkyzivat@alu= m.mit.edu> wrote:
On 2/18/17 1:45 PM, Eric Rescorla wrote:


On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzivat@alum.mit.edu>> wrote:

    On 2/18/17 4:35 AM, Christer Holmberg wrote:

        Hi,

        I invite anyone who has a suggestion on text th= at needs to be
        modified/added/removed to provide a pull reques= t (or send text
        to the list) to do so; in draft-bundle, draft-m= ux-attributes,
        and/or any other specification...


    IMO it doesn't make sense to put attributes on one bundled m-= line
    that only apply to some other bundled m-line - current or fut= ure.


Why? The whole principle is that they are supposed to span all the m=3D lin= es.

They are supposed to span all the m-lines in the bundle that it is meaningf= ul for them to be used with.

Yes, and so it doesn't matter which one they are attached to.


The closest thing we currently have to this situation is session-level attr= ibutes. Some of those are defined as valid at both session and media level,= and that the value at session level is a default for media level. These in= some sense need to be evaluated in the context of every m-line, even the ones where they aren't defined.
But we have no standard rule for these. Every attribute needs to say if it = is defined at session level and if that should be treated as a default for = a value at media level. And in the process it is specifying (at least impli= citly) which m-lines it applies to.

In principle this could also be done for all the attributes that are to be = identical in bundles. But that means making all the changes to do that, and= maintain it in the future.

Huh? We already have a document that analyzes every single attribute a= nd tells you how it
tells you how to hoist stuff from one m=3D line to all of them. And we= 're already handling
it that way if the m=3D line associated with the bundle tag is a media= section. The only
difference is how it's handled if it's a data section.

-Ekr

    As an alternative, how about picking the first tag in the bun= dle
    attribute that identifies an m-line of an appropriate type to= carry
    the attribute?

Seems much more complicated to implement and specify.

To conserve e-mails, responding to Christer as well here: I don't think
we need to update any of the relevant RFCs (other than potentially
putting them in some
useless Updates: line at the top of the doc). The idea here is that
BUNDLE overrides them for cases where it applies.

Again, maybe it is possible to craft some words that clearly and pre= cisely state how this is to work, in a general way without taking it one at= tribute at a time. But I want to see them.

Then we can discuss whether that is simpler than what I suggested above.
        Thanks,
        Paul

-Ekr


            Thanks,
            Paul


        Regards,

        Christer

        -----Original Message-----
        From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu
        <mailto:pkyzivat@alum.mit.edu>]
        Sent: 17 February 2017 18:51
        To: Taylor Brandstetter <deadbeef@google.com
        <mailto:deadbeef@google.com&= gt;>
        Cc: Christer Holmberg <christer.holmberg@ericsson.c= om
        <mailto:christer.holmberg@e= ricsson.com>>; IETF MMUSIC WG
        <mmusic@ietf.org <mailto:mmusic@ietf.org>>
        Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP = attributes in
        non-media m=3D sections

        On 2/16/17 9:27 PM, Taylor Brandstetter wrote:<= br>
                So, to make this wo= rk I think it will be necessary to
            ammend the
                definitions of the = particular attributes to specify this
            usage. And
                then future new att= ributes that pertain to RTP would
            also need to
                address this.


            sdp-mux-attributes already amends= the definitions of these
            attributes,
            such that a TRANSPORT attribute i= n m=3D section "A" can be
            used for
            media described by m=3D section &= quot;B". So, I don't see why it
            couldn't go
            a step further, and explicitly al= low TRANSPORT and IDENTICAL
            category
            attributes to appear in m=3D sect= ions with proto values not
            normally
            used with those attributes.


        I will reserve judgement until I see specific t= ext.

                Thanks,
                Paul

            On Thu, Feb 16, 2017 at 3:50 PM, = Paul Kyzivat
            <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>
            <mailto:pkyzivat@alum.mit.edu

            <mailto:pkyzivat@alum.mit.edu>>= > wrote:

                On 2/16/17 12:10 PM= , Christer Holmberg wrote:

                    Hi Pa= ul,

                    I ass= ume you have an opinion on this :)

                    The s= uggestion is to allow RTP-specific parameters
            (SDP rtcp-mux
                    attri= butes etc) in non-RTP m=3D lines (e.g., data
            channel).


                This is a nasty iss= ue.

                The problem with al= lowing this is: what do these
            parameters *mean*
                when so attached? A= nd where do I look to find out?

                I'm not certain if = they are currently permitted or not.
            AFAIK there
                is no *general* mec= hanism for specifying with which
            proto values a
                particular attribut= e may be used. I haven't studied the
            definitions
                of the "RTP-re= lated" attributes to see if they make a
            specific
                statement about thi= s. My guess is that they don't, but
            that they
                only define the mea= ning in the context of an RTP session.

                If that is so, perh= aps the rule that unknown attributes
            are to be
                ignored should appl= y to those attributes when used with
            a non-RTP
                media section. But = if that rule were to apply, then we
            would expect
                that with O/A the r= ules for how these attributes in an
            offer affect
                what goes in the an= swer would not apply. I guess that
            won't be
                sufficient here.
                So, to make this wo= rk I think it will be necessary to
            ammend the
                definitions of the = particular attributes to specify this
            usage. And
                then future new att= ributes that pertain to RTP would
            also need to
                address this.

                IMO this is a can o= f worms. So my opinion is that these
            should *not*
                be used with non-RT= P m-lines, with or without bundle.

                Note that data chan= nel is a special case. While we have
            agreed not
                to consider it for = now, it is possible, in principle, to
            run RTP
                over a data channel= . If that were defined then these
            attributes
                would also be neede= d. But then they would not be used as
            media-level
                attributes. Instead= , they would be dcsa attributes.

                     = ;   Thanks,
                     = ;   Paul

                    *From= :*mmusic [mailto:mmusic-bounces@ietf.org
            <mailto:mmusic-bounces@ietf.org>=
                    <m= ailto:mmusic-b= ounces@ietf.org
            <mailto:mmusic-bounces@ietf.org>= >] *On Behalf Of *Christer
                    Holmb= erg
                    *Sent= :* 16 February 2017 19:07
                    *To:*= Eric Rescorla <ekr@rt= fm.com
            <mailto:ekr@rtfm.com> <mailto:ekr@rtfm.com<= br>             <mailto:ekr@rtfm.com>>>; mmusic
                    WG &l= t;mmusic@ietf.org = <mailto:mmusic@ietf= .org>
            <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>&= gt;

                    *Subj= ect:* Re: [MMUSIC] Issue #27: Allow RTP
            attributes in
                    non-m= edia m=3D
                    secti= ons



                    Hi,
                    * *
                    *>= *See:


            https://github.com/cdh4u/draft-sdp-bundle/issues/27
            <htt= ps://github.com/cdh4u/draft-sdp-bundle/issues/27>

            <htt= ps://github.com/cdh4u/draft-sdp-bundle/issues/27
            <htt= ps://github.com/cdh4u/draft-sdp-bundle/issues/27>>


                     = ;   https://github.com/rtcweb-wg/jsep/issues/528
            <https://gi= thub.com/rtcweb-wg/jsep/issues/528>
                     = ;   <https://github.com/rtcweb-wg/jsep/is= sues/528
            <https://gi= thub.com/rtcweb-wg/jsep/issues/528>>




                     = ;   The basic issue is that it's possible to have a
            situation
                     = ;   where you

                    have = both

                     = ;   media and data m=3D sections but the BUNDLE tag is
            associated
                     = ;   with the data


                     = ;   m=3D section and now you need to put the TRANSPORT and
            IDENTICAL


                     = ;   attributes somewhere. The JSEP editors discussed
            this and
                     = ;   came to the


                     = ;   conclusion that it should go with the BUNDLE tag
            (i.e., in
                     = ;   the data m=3D

                    secti= on)

                     = ;   and that BUNDLE should forbid this, but it
            requires a change
                     = ;   to BUNDLE.




                    Did y= ou mean to say that BUNDLE should NOT forbid this?



                    Based= on your GitHub discussion, my understanding is
            that you
                    want = to
                    allow= to include RTP-specific parameters
            (=91rtcp-mux=92, =91rtcp=92,
                    =91rt= cp-mux-only=92 attributes etc) in the data m=3D section.



                    To re= peat what I said on GitHub:



                    This = has been discussed in the past, and the outcome
            has been to now
                    allow= RTP-specific parameters in non-RTP m=3D sections.



                    A sol= ution would be to simply change the bundle tag
            when the RTP m=3D
                    secti= ons are added.



                    =85OR= , we change the mux category for the RTP-specific
            parameters.
                    But,<= br>                     that = of course means they have to be added to every
            RTP m=3D section.



                    Regar= ds,



                    Chris= ter


                ___________________= ____________________________
                mmusic mailing list=
                mmusic@ietf.org <mailto:mmusic@ietf.org>
            <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>
                https://www.ietf.org/mailman/listinfo/mmusic
            <https://ww= w.ietf.org/mailman/listinfo/mmusic>
                <https://www.ietf.org/mailman/listinfo/mmusic
            <https://ww= w.ietf.org/mailman/listinfo/mmusic>>




    _______________________________________________
    mmusic mailing list
    mmusic@i= etf.org <mailto:mmusic@ietf.org>
    https://www.ietf.org/mailman/listinfo/mmusic
    <https://www.ietf.org/mailman/list= info/mmusic>




 --_000_D4D9F20218680christerholmbergericssoncom_-- From nobody Mon Feb 27 06:34:03 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E124C12A022 for ; Mon, 27 Feb 2017 06:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svrDOK684Ob7 for ; Mon, 27 Feb 2017 06:33:43 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C98129F57 for ; Mon, 27 Feb 2017 06:33:35 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id l138so12512497ywc.0 for ; Mon, 27 Feb 2017 06:33:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pfW3zuIXZbFDaA1TrvzjOgGGicOmsOTdT/+B13KfX9U=; b=aHg2m0TYVBUKuEiTWwmMN8h88UiEQtT4a0ufMDXQYzztr/+uqlk+I9VpiPWHPSjO2F ERcb9AQDgL4BT9bTXJvT0deknXPdfTnga+rgOdbaw69mAfLh/mgQtzTAwHAxv6OZ0pw9 FCONArxfiO9Mq/nvh/fGdTcYdzFHiiIaFgSvTGAfNwYaTZbPGeuypWqSZmAyZjeOf68q pzGuMQn2hvkHZ5jBgDnOlJNkKQV5ghYUmnfQTfB/V5eohOAX2lhRGkqSbKtxRq9v+1N1 a3puYrOmjhLNtdmfwoUX8MG/lpxSCxGNkybukv0Nn2iQTbwQqZOKRceUS6ZfXRPYNbPk ysVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pfW3zuIXZbFDaA1TrvzjOgGGicOmsOTdT/+B13KfX9U=; b=OczAIk9ZOouYoj4jZK0YHBvkyXCSZouH2fw8Hy+KBsF4v3g7HrP7tZYkF13czoxcJS TzxMufUpxvAWOWNfW64R5QHqJvE06+2zgq4A2Wz8IxLY/zU8rBHdQladXjovo3OIqAIP vVAt5bsd8LcPhXwyuZRAVwezWcowyzt/U9NmGOZhLZeEgB6b7y1hFMkodd3JVNuXXJPM zUmbeflTNxbx6sPr7X08sLIH7xMkuomho/hH8G31TvBoM7/TP92MzBEqAVk8MwufAhb/ WpZY5SLfdAAExIUgQpvKpzslwYJkDPb6BlobRYBOTtqcVTkBcPUeFkVW+WH7UxwFF1be nMUQ== X-Gm-Message-State: AMke39nzfouQKSnpc+8tzrBQ+bavXKpr70ncpsPQbfG8AGoWncxC0ykAhXBMY0Y3de3cjBk9TPlyCWs/Uwq2SA== X-Received: by 10.37.224.81 with SMTP id x78mr11292591ybg.80.1488206014626; Mon, 27 Feb 2017 06:33:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Mon, 27 Feb 2017 06:32:54 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0076FE@ESESSMB209.ericsson.se> <66341809-4c3e-2989-5039-a3369c0fa503@alum.mit.edu> <7df97f84-613d-2f5c-2290-aca82621f5ba@alum.mit.edu> From: Eric Rescorla Date: Mon, 27 Feb 2017 06:32:54 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c087358daec0a054983f683 Archived-At: Cc: IETF MMUSIC WG , Paul Kyzivat Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 14:33:50 -0000 --94eb2c087358daec0a054983f683 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, I think we do On Mon, Feb 27, 2017 at 5:10 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Do people think we need to discuss this face-to-face in Chicago? Note tha= t > I have currently NOT requested agenda time for BUNDLE. > > As far as document changes are concerned, we would AT LEAST need some > clarification text in BUNDLE and/or draft-mux-attributes. > > Regards, > > Christer > > From: Eric Rescorla > Date: Sunday 19 February 2017 at 00:28 > To: "pkyzivat@alum.mit.edu" > Cc: Christer Holmberg , Taylor > Brandstetter , "mmusic@ietf.org" > > Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= =3D > sections > > > > On Sat, Feb 18, 2017 at 1:38 PM, Paul Kyzivat > wrote: > >> On 2/18/17 1:45 PM, Eric Rescorla wrote: >> >>> >>> >>> On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat >> > wrote: >>> >>> On 2/18/17 4:35 AM, Christer Holmberg wrote: >>> >>> Hi, >>> >>> I invite anyone who has a suggestion on text that needs to be >>> modified/added/removed to provide a pull request (or send text >>> to the list) to do so; in draft-bundle, draft-mux-attributes, >>> and/or any other specification... >>> >>> >>> IMO it doesn't make sense to put attributes on one bundled m-line >>> that only apply to some other bundled m-line - current or future. >>> >>> >>> Why? The whole principle is that they are supposed to span all the m=3D >>> lines. >>> >> >> They are supposed to span all the m-lines in the bundle that it is >> meaningful for them to be used with. >> > > Yes, and so it doesn't matter which one they are attached to. > > > The closest thing we currently have to this situation is session-level >> attributes. Some of those are defined as valid at both session and media >> level, and that the value at session level is a default for media level. >> These in some sense need to be evaluated in the context of every m-line, >> even the ones where they aren't defined. >> >> But we have no standard rule for these. Every attribute needs to say if >> it is defined at session level and if that should be treated as a defaul= t >> for a value at media level. And in the process it is specifying (at leas= t >> implicitly) which m-lines it applies to. >> >> In principle this could also be done for all the attributes that are to >> be identical in bundles. But that means making all the changes to do tha= t, >> and maintain it in the future. > > > Huh? We already have a document that analyzes every single attribute and > tells you how it > is to be handled (https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux- > attributes-16) and > tells you how to hoist stuff from one m=3D line to all of them. And we're > already handling > it that way if the m=3D line associated with the bundle tag is a media > section. The only > difference is how it's handled if it's a data section. > > -Ekr > > As an alternative, how about picking the first tag in the bundle >>> attribute that identifies an m-line of an appropriate type to carry >>> the attribute? >>> >>> Seems much more complicated to implement and specify. >>> >>> To conserve e-mails, responding to Christer as well here: I don't think >>> we need to update any of the relevant RFCs (other than potentially >>> putting them in some >>> useless Updates: line at the top of the doc). The idea here is that >>> BUNDLE overrides them for cases where it applies. >>> >> >> Again, maybe it is possible to craft some words that clearly and >> precisely state how this is to work, in a general way without taking it = one >> attribute at a time. But I want to see them. >> >> Then we can discuss whether that is simpler than what I suggested above. >> >> Thanks, >> Paul >> >> -Ekr >>> >>> >>> Thanks, >>> Paul >>> >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu >>> ] >>> Sent: 17 February 2017 18:51 >>> To: Taylor Brandstetter >> > >>> Cc: Christer Holmberg >> >; IETF MMUSIC WG >>> > >>> Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in >>> non-media m=3D sections >>> >>> On 2/16/17 9:27 PM, Taylor Brandstetter wrote: >>> >>> So, to make this work I think it will be necessary to >>> ammend the >>> definitions of the particular attributes to specify thi= s >>> usage. And >>> then future new attributes that pertain to RTP would >>> also need to >>> address this. >>> >>> >>> sdp-mux-attributes already amends the definitions of these >>> attributes, >>> such that a TRANSPORT attribute in m=3D section "A" can be >>> used for >>> media described by m=3D section "B". So, I don't see why it >>> couldn't go >>> a step further, and explicitly allow TRANSPORT and IDENTICA= L >>> category >>> attributes to appear in m=3D sections with proto values not >>> normally >>> used with those attributes. >>> >>> >>> I will reserve judgement until I see specific text. >>> >>> Thanks, >>> Paul >>> >>> On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat >>> >>> >> >>> >> wrote: >>> >>> On 2/16/17 12:10 PM, Christer Holmberg wrote: >>> >>> Hi Paul, >>> >>> I assume you have an opinion on this :) >>> >>> The suggestion is to allow RTP-specific parameters >>> (SDP rtcp-mux >>> attributes etc) in non-RTP m=3D lines (e.g., data >>> channel). >>> >>> >>> This is a nasty issue. >>> >>> The problem with allowing this is: what do these >>> parameters *mean* >>> when so attached? And where do I look to find out? >>> >>> I'm not certain if they are currently permitted or not. >>> AFAIK there >>> is no *general* mechanism for specifying with which >>> proto values a >>> particular attribute may be used. I haven't studied the >>> definitions >>> of the "RTP-related" attributes to see if they make a >>> specific >>> statement about this. My guess is that they don't, but >>> that they >>> only define the meaning in the context of an RTP sessio= n. >>> >>> If that is so, perhaps the rule that unknown attributes >>> are to be >>> ignored should apply to those attributes when used with >>> a non-RTP >>> media section. But if that rule were to apply, then we >>> would expect >>> that with O/A the rules for how these attributes in an >>> offer affect >>> what goes in the answer would not apply. I guess that >>> won't be >>> sufficient here. >>> >>> So, to make this work I think it will be necessary to >>> ammend the >>> definitions of the particular attributes to specify thi= s >>> usage. And >>> then future new attributes that pertain to RTP would >>> also need to >>> address this. >>> >>> IMO this is a can of worms. So my opinion is that these >>> should *not* >>> be used with non-RTP m-lines, with or without bundle. >>> >>> Note that data channel is a special case. While we have >>> agreed not >>> to consider it for now, it is possible, in principle, t= o >>> run RTP >>> over a data channel. If that were defined then these >>> attributes >>> would also be needed. But then they would not be used a= s >>> media-level >>> attributes. Instead, they would be dcsa attributes. >>> >>> Thanks, >>> Paul >>> >>> *From:*mmusic [mailto:mmusic-bounces@ietf.org >>> >>> >> >] *On Behalf Of *Christer >>> Holmberg >>> *Sent:* 16 February 2017 19:07 >>> *To:* Eric Rescorla >> >> >>; mmusic >>> WG >>> >> >>> >>> *Subject:* Re: [MMUSIC] Issue #27: Allow RTP >>> attributes in >>> non-media m=3D >>> sections >>> >>> >>> >>> Hi, >>> >>> * * >>> >>> *>*See: >>> >>> >>> https://github.com/cdh4u/draft-sdp-bundle/issues/27 >>> >>> >>> >> > >>> >>> >>> https://github.com/rtcweb-wg/jsep/issues/528 >>> >>> >> > >>> >>> >>> >>> >>> The basic issue is that it's possible to have a >>> situation >>> where you >>> >>> have both >>> >>> media and data m=3D sections but the BUNDLE tag= is >>> associated >>> with the data >>> >>> >>> m=3D section and now you need to put the TRANSP= ORT >>> and >>> IDENTICAL >>> >>> >>> attributes somewhere. The JSEP editors discusse= d >>> this and >>> came to the >>> >>> >>> conclusion that it should go with the BUNDLE ta= g >>> (i.e., in >>> the data m=3D >>> >>> section) >>> >>> and that BUNDLE should forbid this, but it >>> requires a change >>> to BUNDLE. >>> >>> >>> >>> >>> Did you mean to say that BUNDLE should NOT forbid >>> this? >>> >>> >>> >>> Based on your GitHub discussion, my understanding i= s >>> that you >>> want to >>> allow to include RTP-specific parameters >>> (=E2=80=98rtcp-mux=E2=80=99, =E2=80=98rtcp=E2=80=99, >>> =E2=80=98rtcp-mux-only=E2=80=99 attributes etc) in = the data m=3D >>> section. >>> >>> >>> >>> To repeat what I said on GitHub: >>> >>> >>> >>> This has been discussed in the past, and the outcom= e >>> has been to now >>> allow RTP-specific parameters in non-RTP m=3D secti= ons. >>> >>> >>> >>> A solution would be to simply change the bundle tag >>> when the RTP m=3D >>> sections are added. >>> >>> >>> >>> =E2=80=A6OR, we change the mux category for the RTP= -specific >>> parameters. >>> But, >>> that of course means they have to be added to every >>> RTP m=3D section. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >> > --94eb2c087358daec0a054983f683 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I think we do

On Mon, Feb 27, 2017 at 5:10 AM, Christer Holmberg = <christer.holmberg@ericsson.com> wrote:
Hi,

Do people think we need to discuss this face-to-face in Chicago? Note = that I have currently NOT requested agenda time for BUNDLE.

As far as document changes are concerned, we would AT LEAST need some = clarification text in BUNDLE and/or draft-mux-attributes.

Regards,

Christer




On Sat, Feb 18, 2017 at 1:38 PM, Paul Kyzivat <pkyzivat@alu= m.mit.edu> wrote:
On 2/18/17 1:45 PM, Eric Rescor= la wrote:


On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzivat@alum.mit.edu>= > wrote:

=C2=A0 =C2=A0 On 2/18/17 4:35 AM, Christer Holmberg wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I invite anyone who has a suggestion on text th= at needs to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 modified/added/removed to provide a pull reques= t (or send text
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to the list) to do so; in draft-bundle, draft-m= ux-attributes,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and/or any other specification...


=C2=A0 =C2=A0 IMO it doesn't make sense to put attributes on one bundle= d m-line
=C2=A0 =C2=A0 that only apply to some other bundled m-line - current or fut= ure.


Why? The whole principle is that they are supposed to span all the m=3D lin= es.

They are supposed to span all the m-lines in the bundle that it is meaningf= ul for them to be used with.

Yes, and so it doesn't matter which one they are attached to.


The closest thing we currently have to this situation is session-level attr= ibutes. Some of those are defined as valid at both session and media level,= and that the value at session level is a default for media level. These in= some sense need to be evaluated in the context of every m-line, even the ones where they aren't define= d.

But we have no standard rule for these. Every attribute needs to say if it = is defined at session level and if that should be treated as a default for = a value at media level. And in the process it is specifying (at least impli= citly) which m-lines it applies to.

In principle this could also be done for all the attributes that are to be = identical in bundles. But that means making all the changes to do that, and= maintain it in the future.

Huh? We already have a document that analyzes every single attribute a= nd tells you how it
tells you how to hoist stuff from one m=3D line to all of them. And we= 're already handling
it that way if the m=3D line associated with the bundle tag is a media= section. The only
difference is how it's handled if it's a data section.

-Ekr

=C2=A0 =C2=A0 As an alternative, how about picking the first tag in the bun= dle
=C2=A0 =C2=A0 attribute that identifies an m-line of an appropriate type to= carry
=C2=A0 =C2=A0 the attribute?

Seems much more complicated to implement and specify.

To conserve e-mails, responding to Christer as well here: I don't think=
we need to update any of the relevant RFCs (other than potentially
putting them in some
useless Updates: line at the top of the doc). The idea here is that
BUNDLE overrides them for cases where it applies.

Again, maybe it is possible to craft some words that clearly and pre= cisely state how this is to work, in a general way without taking it one at= tribute at a time. But I want to see them.

Then we can discuss whether that is simpler than what I suggested above.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

-Ekr


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


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Christer

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Original Message-----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:pkyzivat@alum.mit.edu>]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent: 17 February 2017 18:51
=C2=A0 =C2=A0 =C2=A0 =C2=A0 To: Taylor Brandstetter <deadbeef@google.com
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 <mailto:dea= dbeef@google.com>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cc: Christer Holmberg <christer.holmberg@ericsson.c= om
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &l= t;mailto:christer.holmberg@ericsson.com>>; IETF MMUSIC WG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mmusic@ietf.org <mailto:mmusic@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP = attributes in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 non-media m=3D sections

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 2/16/17 9:27 PM, Taylor Brandstetter wrote:<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 So, to make this wo= rk I think it will be necessary to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ammend the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definitions of the = particular attributes to specify this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 usage. And
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 then future new att= ributes that pertain to RTP would
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 also need to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address this.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sdp-mux-attributes already amends= the definitions of these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attributes,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such that a TRANSPORT attribute i= n m=3D section "A" can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 used for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 media described by m=3D section &= quot;B". So, I don't see why it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 couldn't go
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a step further, and explicitly al= low TRANSPORT and IDENTICAL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 category
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attributes to appear in m=3D sect= ions with proto values not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 normally
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 used with those attributes.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I will reserve judgement until I see specific t= ext.

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Feb 16, 2017 at 3:50 PM, = Paul Kyzivat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:pkyzivat@alum.mit.edu

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:pkyzivat@alum.mit.edu>>= > wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 2/16/17 12:10 PM= , Christer Holmberg wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Pa= ul,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I ass= ume you have an opinion on this :)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The s= uggestion is to allow RTP-specific parameters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (SDP rtcp-mux
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attri= butes etc) in non-RTP m=3D lines (e.g., data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 channel).


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is a nasty iss= ue.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The problem with al= lowing this is: what do these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 parameters *mean*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when so attached? A= nd where do I look to find out?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I'm not certain= if they are currently permitted or not.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AFAIK there
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is no *general* mec= hanism for specifying with which
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 proto values a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 particular attribut= e may be used. I haven't studied the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definitions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the "RTP-re= lated" attributes to see if they make a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specific
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 statement about thi= s. My guess is that they don't, but
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that they
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 only define the mea= ning in the context of an RTP session.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If that is so, perh= aps the rule that unknown attributes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 are to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ignored should appl= y to those attributes when used with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a non-RTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 media section. But = if that rule were to apply, then we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 would expect
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that with O/A the r= ules for how these attributes in an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 offer affect
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 what goes in the an= swer would not apply. I guess that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 won't be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sufficient here.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 So, to make this wo= rk I think it will be necessary to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ammend the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definitions of the = particular attributes to specify this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 usage. And
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 then future new att= ributes that pertain to RTP would
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 also need to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address this.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IMO this is a can o= f worms. So my opinion is that these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 should *not*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be used with non-RT= P m-lines, with or without bundle.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Note that data chan= nel is a special case. While we have
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 agreed not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to consider it for = now, it is possible, in principle, to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 run RTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 over a data channel= . If that were defined then these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attributes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 would also be neede= d. But then they would not be used as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 media-level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attributes. Instead= , they would be dcsa attributes.

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *From= :*mmusic [mailto:mmusic-bounces@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mmusic-bounces@ietf.org>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <m= ailto:mmusic-b= ounces@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mmusic-bounces@ietf.org>= >] *On Behalf Of *Christer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Holmb= erg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *Sent= :* 16 February 2017 19:07
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *To:*= Eric Rescorla <ekr@rt= fm.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ekr@rtfm.com> <mailto:ekr@rtfm.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ekr@rtfm.com>>>; mmusic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WG &l= t;mmusic@ietf.org = <mailto:mmusic@ietf= .org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>&= gt;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *Subj= ect:* Re: [MMUSIC] Issue #27: Allow RTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attributes in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 non-m= edia m=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 secti= ons



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *>= *See:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://github.com/cdh4u/draft-sdp-bundle/issues/27
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <htt= ps://github.com/cdh4u/draft-sdp-bundle/issues/27>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <htt= ps://github.com/cdh4u/draft-sdp-bundle/issues/27
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <htt= ps://github.com/cdh4u/draft-sdp-bundle/issues/27>>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 https://github.com/rtcweb-wg/jsep/issues/528
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://gi= thub.com/rtcweb-wg/jsep/issues/528>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <https://github.com/rtcweb-wg/jsep/is= sues/528
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://gi= thub.com/rtcweb-wg/jsep/issues/528>>




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 The basic issue is that it's possible to have a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 situation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 where you

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 have = both

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 media and data m=3D sections but the BUNDLE tag is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 associated
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 with the data


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 m=3D section and now you need to put the TRANSPORT and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IDENTICAL


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 attributes somewhere. The JSEP editors discussed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 came to the


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 conclusion that it should go with the BUNDLE tag
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (i.e., in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 the data m=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 secti= on)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 and that BUNDLE should forbid this, but it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 requires a change
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 to BUNDLE.




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Did y= ou mean to say that BUNDLE should NOT forbid this?



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Based= on your GitHub discussion, my understanding is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that you
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 want = to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 allow= to include RTP-specific parameters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (=E2=80=98rtcp-mux=E2=80=99, =E2= =80=98rtcp=E2=80=99,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2= =80=98rtcp-mux-only=E2=80=99 attributes etc) in the data m=3D section.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 To re= peat what I said on GitHub:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This = has been discussed in the past, and the outcome
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 has been to now
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 allow= RTP-specific parameters in non-RTP m=3D sections.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A sol= ution would be to simply change the bundle tag
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when the RTP m=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 secti= ons are added.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2= =80=A6OR, we change the mux category for the RTP-specific
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 parameters.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 But,<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that = of course means they have to be added to every
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RTP m=3D section.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Regar= ds,



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Chris= ter


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mmusic mailing list=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mmusic@ietf.org <mailto:mmusic@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/mmusic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://ww= w.ietf.org/mailman/listinfo/mmusic>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinfo/mmusic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://ww= w.ietf.org/mailman/listinfo/mmusic>>




=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 mmusic mailing list
=C2=A0 =C2=A0 mmusic@i= etf.org <mailto:mmusic@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/mmusic
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/list= info/mmusic>





--94eb2c087358daec0a054983f683-- From nobody Mon Feb 27 06:59:40 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A516C12A09A; Mon, 27 Feb 2017 06:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3QnQQi-oWdY; Mon, 27 Feb 2017 06:59:38 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206F91298A6; Mon, 27 Feb 2017 06:59:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1144; q=dns/txt; s=iport; t=1488207578; x=1489417178; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=pkXOBJW/9ASSoOqs8n0Ig2qNG25gFc1g9XNQR7Cub/s=; b=UOY09vjArer7uVHaL4jwGDhWlDYCwgse7Qxdl7liFHdxFOCptS+1NiJP i9Eo9JYGAkmuW87ZgxVqnVUuaXgLXiHHvudusy+NkBapXEHaJjKkbhp9w 8QblmW+5LauFeP8kfO1VaJC0SWuV+dcKawKNolgh61fxTkDh8TRulrK8q E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DlAgBiPbRY/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhAydfjWORYJU1gg0fC4UuSgKCGz8YAQIBAQEBAQEBYiiEcQE?= =?us-ascii?q?BBAEBNjYbCxguJzAGAQwGAgEBiWMNDrIUiz0BAQEBAQEBAQEBAQEBAQEBAQEbB?= =?us-ascii?q?YZMggWCaoo5AQSQUItOkieBe4UggzCFFIE5kzEfOIEBNR8VPoRPHYF/IjUBihk?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.35,215,1484006400"; d="scan'208";a="203215534" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2017 14:59:37 +0000 Received: from [10.98.149.202] (bxb-fandreas-8819.cisco.com [10.98.149.202]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v1RExaRA006231; Mon, 27 Feb 2017 14:59:37 GMT To: mmusic , draft-ietf-mmusic-sdp-simulcast@ietf.org References: <01a352cf-9adc-18bb-3cd0-ce82d39e5490@cisco.com> From: Flemming Andreasen Message-ID: Date: Mon, 27 Feb 2017 09:59:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <01a352cf-9adc-18bb-3cd0-ce82d39e5490@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 14:59:39 -0000 The WGLC on this draft has completed, however we did not receive a single comment on it, which makes it very difficult to move forward with the publication request. If you have reviewed the draft, please send a note to the list with your review disposition and any comments you may have (if you don't have any comments, that's fine too - just let us know you reviewed it). Thanks -- Flemming (as MMUSIC co-chair) On 2/8/17 6:09 PM, Flemming Andreasen wrote: > Greetings MMUSIC > > This is to announce a 2 week WGLC on the draft: > > https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-07.txt > > as Proposed Standard. Please review and provide any comments you may > have on the document by Wednesday, February 22, 2017. Comments should > be sent to the document authors and the MMUSIC WG list. If you review > the document but do not have any comments, please send a note to that > effect as well. > > Thanks > > -- Flemming (MMUSIC co-chair) > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From nobody Mon Feb 27 07:09:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078C112A0C2 for ; Mon, 27 Feb 2017 07:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC_lxRCfTnmn for ; Mon, 27 Feb 2017 07:09:44 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC4312A0BE for ; Mon, 27 Feb 2017 07:09:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4473; q=dns/txt; s=iport; t=1488208183; x=1489417783; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=Jb9ccZ9WQg6NINuzI9m0lM4Ip23lbA/aGwENRqzao44=; b=fXUoNgH29Pfs5ZrVVexQiyI2TUkM7J+gNGh6VU+FfTfZh9GbvmuUHJNo YiHP632EskpNV/PdFGAGCNDu7oNTAmHrq1TY9xp2IT4YIHZat9jw+msFV +LXcdKk2+Fuxnrp542Fi3jyDr9zi3APETrs1uxQ2pfZRrMC0+KKeGeWc6 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAwDsQLRY/5FdJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1BhAydfjWORYJAJhSyCDR8BCoUuSgKCGz8YAQIBAQEBAQEBYiiEcQE?= =?us-ascii?q?BBAEBbBsLBBQuJzAGDQYCAQGJYw0OshcrixIBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RkFhkyCBYJqijkFhmWIbH+LTo08hGuBe4UggzCGTZMxHziBATUfFT6GayI1iho?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.35,215,1484006400"; d="scan'208,217";a="211781131" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2017 15:09:42 +0000 Received: from [10.98.149.202] (bxb-fandreas-8819.cisco.com [10.98.149.202]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v1RF9fOc021750 for ; Mon, 27 Feb 2017 15:09:42 GMT To: mmusic References: <977409c0-d622-9f5d-30b5-aee54240e01e@cisco.com> From: Flemming Andreasen Message-ID: <49ac8434-2dfb-162b-29d2-12d5ae1da70e@cisco.com> Date: Mon, 27 Feb 2017 10:09:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <977409c0-d622-9f5d-30b5-aee54240e01e@cisco.com> Content-Type: multipart/alternative; boundary="------------7F588C8923F5D419AF9F3CD3" Archived-At: Subject: Re: [MMUSIC] MMUSIC Agenda Requests for IETF 98 (Chicago) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 15:09:45 -0000 This is a multi-part message in MIME format. --------------7F588C8923F5D419AF9F3CD3 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi again Just a reminder to please send us your agenda request (if you haven't done so already). Draft WG agendas are due on 3/15, so we will need your request by Monday 3/13. Thanks Bo & Flemming On 2/10/17 9:08 AM, Flemming Andreasen wrote: > Hi > > IETF98 in Chicago will be here before you know it, and the MMUSIC WG > has asked for a 2 hour meeting this time. Draft submissions and WG > agendas are both due in ~1 month, so now would be a good time to start > preparing and let the chairs know if you have anything you would like > to get on the agenda. > > As usual, we want to ensure we take advantage of our meeting time in a > productive manner. This means that we want presenters to come prepared > to discuss open issues that have already been raised on the mailing > list and ideally received some feedback. Priority will be given to > drafts that gather attention and discussion on the mailing list prior > to the meeting. We also aim to give adequate time for drafts holding > up progress elsewhere. To facilitate this, please specify in your > agenda request e-mail the following: > > - name of the draft and the presenter > - how much time you would like > - outline of major open issues; what needs to be discussed at the meeting > - dependencies to your draft (if any) > > Thanks > > Bo & Flemming (MMUSIC co-chairs) > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------7F588C8923F5D419AF9F3CD3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi again

Just a reminder to please send us your agenda request (if you haven't done so already). Draft WG agendas are due on 3/15, so we will need your request by Monday 3/13.

Thanks

    Bo & Flemming

On 2/10/17 9:08 AM, Flemming Andreasen wrote:
Hi

IETF98 in Chicago will be here before you know it, and the MMUSIC WG has asked for a 2 hour meeting this time. Draft submissions and WG agendas are both due in ~1 month, so now would be a good time to start preparing and let the chairs know if you have anything you would like to get on the agenda.

As usual, we want to ensure we take advantage of our meeting time in a productive manner. This means that we want presenters to come prepared to discuss open issues that have already been raised on the mailing list and ideally received some feedback. Priority will be given to drafts that gather attention and discussion on the mailing list prior to the meeting. We also aim to give adequate time for drafts holding up progress elsewhere. To facilitate this, please specify in your agenda request e-mail the following:

- name of the draft and the presenter
- how much time you would like
- outline of major open issues; what needs to be discussed at the meeting
- dependencies to your draft (if any)
 

Thanks

     Bo & Flemming (MMUSIC co-chairs)




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

--------------7F588C8923F5D419AF9F3CD3-- From nobody Mon Feb 27 07:33:25 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D84E112A137 for ; Mon, 27 Feb 2017 07:33:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148820960388.21072.6107852724941047456.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 07:33:23 -0800 From: IETF Secretariat Archived-At: Subject: [MMUSIC] Milestones changed for mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 15:33:24 -0000 Changed milestone "Submit Interactive Connectivity Establishment (ICE) with SDP offer/answer and SIP as Proposed Standard", set due date to April 2017 from December 2016. URL: https://datatracker.ietf.org/wg/mmusic/about/ From nobody Mon Feb 27 09:22:03 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E8712A274 for ; Mon, 27 Feb 2017 09:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLLNL950wllJ for ; Mon, 27 Feb 2017 09:21:58 -0800 (PST) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F374C12A272 for ; Mon, 27 Feb 2017 09:21:57 -0800 (PST) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-12v.sys.comcast.net with SMTP id iOzjclhGLCGpRiOzlc4LV4; Mon, 27 Feb 2017 17:21:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1488216117; bh=SPo9SW3ouNnuw0Yr/Cp8bfqRfzdo8ZXCjpV7z179sf0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=bO9QzCWndYr4nFb68Q8cbTRNwofPIsLyaj4IVKrmIC9GQ+rhwqAlYl+fCdoVA4YYU BGoPdCpvla9KQ37+ZapbM06NgTjRYVd399tij1vLRbSFo1M335Av+C5gNPvarHwjlv YPYqElafRNH0k7bba94UnaJ+X+/0wFf3L4Pxju64FwovzWQb1AYWftgxdpz2b7jElo 0krxasoY2INKw8B7e+pAn5xAEwI7Co0B/xy7WFqd0IQThzQozNeKsjKXi8X/bUMB5V LlgmFeSDoWUzS6NUIp3SN2pr9nJjk1nbLAGoQiFwm03nZB7WnBCBIPOOYK1xC7VUGx +sfLgh3NcI+LQ== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-10v.sys.comcast.net with SMTP id iOzkcyexeS4c1iOzkcAhrc; Mon, 27 Feb 2017 17:21:57 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0076FE@ESESSMB209.ericsson.se> <66341809-4c3e-2989-5039-a3369c0fa503@alum.mit.edu> <7df97f84-613d-2f5c-2290-aca82621f5ba@alum.mit.edu> From: Paul Kyzivat Message-ID: <84eaf25b-8ba9-d675-ef4f-ed351a318c19@comcast.net> Date: Mon, 27 Feb 2017 12:21:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfAimhKAuCLMWmFJUVn/oKMkzaeMe+Z56ywsCk3LIy9X9hCDfpkZtQIWhLKB2xpTsRzH3gAoyd9e/GbF0wrqzCskQuCDduIvZv6EYJGlTesiawKUwVn5q goVbD4NOQVwUMUxZd69Hr4DqVTe01jyejpt3hs6Xq5fwvk11TOpQVijDUrl9QNVa4RhJtVB6Wn+FYw== Archived-At: Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 17:22:00 -0000 I give up!!! If everybody else is happy with this then I will simply hold my nose and my tongue. The fundamental problem here is that SDP syntax is vastly inadequate for how it has been pushed. This was already true when O/A was first introduced, and it has gotten progressively more apparent as more things have been added. Unfortunately there seems to be zero chance that another crack at SDPng will ever be taken. Grumble, Paul On 2/18/17 5:28 PM, Eric Rescorla wrote: > > > On Sat, Feb 18, 2017 at 1:38 PM, Paul Kyzivat > wrote: > > On 2/18/17 1:45 PM, Eric Rescorla wrote: > > > > On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat > > >> > wrote: > > On 2/18/17 4:35 AM, Christer Holmberg wrote: > > Hi, > > I invite anyone who has a suggestion on text that needs > to be > modified/added/removed to provide a pull request (or > send text > to the list) to do so; in draft-bundle, > draft-mux-attributes, > and/or any other specification... > > > IMO it doesn't make sense to put attributes on one bundled > m-line > that only apply to some other bundled m-line - current or > future. > > > Why? The whole principle is that they are supposed to span all > the m= lines. > > > They are supposed to span all the m-lines in the bundle that it is > meaningful for them to be used with. > > > Yes, and so it doesn't matter which one they are attached to. > > > The closest thing we currently have to this situation is > session-level attributes. Some of those are defined as valid at both > session and media level, and that the value at session level is a > default for media level. These in some sense need to be evaluated in > the context of every m-line, even the ones where they aren't defined. > > But we have no standard rule for these. Every attribute needs to say > if it is defined at session level and if that should be treated as a > default for a value at media level. And in the process it is > specifying (at least implicitly) which m-lines it applies to. > > In principle this could also be done for all the attributes that are > to be identical in bundles. But that means making all the changes to > do that, and maintain it in the future. > > > Huh? We already have a document that analyzes every single attribute and > tells you how it > is to be handled > (https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-16) and > tells you how to hoist stuff from one m= line to all of them. And we're > already handling > it that way if the m= line associated with the bundle tag is a media > section. The only > difference is how it's handled if it's a data section. > > -Ekr > > As an alternative, how about picking the first tag in the bundle > attribute that identifies an m-line of an appropriate type > to carry > the attribute? > > Seems much more complicated to implement and specify. > > To conserve e-mails, responding to Christer as well here: I > don't think > we need to update any of the relevant RFCs (other than potentially > putting them in some > useless Updates: line at the top of the doc). The idea here is that > BUNDLE overrides them for cases where it applies. > > > Again, maybe it is possible to craft some words that clearly and > precisely state how this is to work, in a general way without taking > it one attribute at a time. But I want to see them. > > Then we can discuss whether that is simpler than what I suggested above. > > Thanks, > Paul > > -Ekr > > > Thanks, > Paul > > > Regards, > > Christer > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu > > >] > Sent: 17 February 2017 18:51 > To: Taylor Brandstetter > >> > Cc: Christer Holmberg > >>; IETF MMUSIC WG > > >> > Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in > non-media m= sections > > On 2/16/17 9:27 PM, Taylor Brandstetter wrote: > > So, to make this work I think it will be > necessary to > ammend the > definitions of the particular attributes to > specify this > usage. And > then future new attributes that pertain to RTP would > also need to > address this. > > > sdp-mux-attributes already amends the definitions of > these > attributes, > such that a TRANSPORT attribute in m= section "A" can be > used for > media described by m= section "B". So, I don't see > why it > couldn't go > a step further, and explicitly allow TRANSPORT and > IDENTICAL > category > attributes to appear in m= sections with proto > values not > normally > used with those attributes. > > > I will reserve judgement until I see specific text. > > Thanks, > Paul > > On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat > > > > > >>> wrote: > > On 2/16/17 12:10 PM, Christer Holmberg wrote: > > Hi Paul, > > I assume you have an opinion on this :) > > The suggestion is to allow RTP-specific > parameters > (SDP rtcp-mux > attributes etc) in non-RTP m= lines (e.g., data > channel). > > > This is a nasty issue. > > The problem with allowing this is: what do these > parameters *mean* > when so attached? And where do I look to find out? > > I'm not certain if they are currently permitted > or not. > AFAIK there > is no *general* mechanism for specifying with which > proto values a > particular attribute may be used. I haven't > studied the > definitions > of the "RTP-related" attributes to see if they > make a > specific > statement about this. My guess is that they > don't, but > that they > only define the meaning in the context of an RTP > session. > > If that is so, perhaps the rule that unknown > attributes > are to be > ignored should apply to those attributes when > used with > a non-RTP > media section. But if that rule were to apply, > then we > would expect > that with O/A the rules for how these attributes > in an > offer affect > what goes in the answer would not apply. I guess > that > won't be > sufficient here. > > So, to make this work I think it will be > necessary to > ammend the > definitions of the particular attributes to > specify this > usage. And > then future new attributes that pertain to RTP would > also need to > address this. > > IMO this is a can of worms. So my opinion is > that these > should *not* > be used with non-RTP m-lines, with or without > bundle. > > Note that data channel is a special case. While > we have > agreed not > to consider it for now, it is possible, in > principle, to > run RTP > over a data channel. If that were defined then these > attributes > would also be needed. But then they would not be > used as > media-level > attributes. Instead, they would be dcsa attributes. > > Thanks, > Paul > > *From:*mmusic > [mailto:mmusic-bounces@ietf.org > > > > >>] *On Behalf Of *Christer > Holmberg > *Sent:* 16 February 2017 19:07 > *To:* Eric Rescorla > > > > >>>; mmusic > WG > > > > >>> > > *Subject:* Re: [MMUSIC] Issue #27: Allow RTP > attributes in > non-media m= > sections > > > > Hi, > > * * > > *>*See: > > > https://github.com/cdh4u/draft-sdp-bundle/issues/27 > > > > > > >> > > > > https://github.com/rtcweb-wg/jsep/issues/528 > > > > > > >> > > > > > The basic issue is that it's possible to > have a > situation > where you > > have both > > media and data m= sections but the > BUNDLE tag is > associated > with the data > > > m= section and now you need to put the > TRANSPORT and > IDENTICAL > > > attributes somewhere. The JSEP editors > discussed > this and > came to the > > > conclusion that it should go with the > BUNDLE tag > (i.e., in > the data m= > > section) > > and that BUNDLE should forbid this, but it > requires a change > to BUNDLE. > > > > > Did you mean to say that BUNDLE should NOT > forbid this? > > > > Based on your GitHub discussion, my > understanding is > that you > want to > allow to include RTP-specific parameters > (‘rtcp-mux’, ‘rtcp’, > ‘rtcp-mux-only’ attributes etc) in the data > m= section. > > > > To repeat what I said on GitHub: > > > > This has been discussed in the past, and the > outcome > has been to now > allow RTP-specific parameters in non-RTP m= > sections. > > > > A solution would be to simply change the > bundle tag > when the RTP m= > sections are added. > > > > …OR, we change the mux category for the > RTP-specific > parameters. > But, > that of course means they have to be added > to every > RTP m= section. > > > > Regards, > > > > Christer > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > > > > >> > https://www.ietf.org/mailman/listinfo/mmusic > > > > > >> > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > > > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Feb 28 08:11:15 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8332129618 for ; Tue, 28 Feb 2017 08:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eay821gHpNM9 for ; Tue, 28 Feb 2017 08:11:11 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4742129616 for ; Tue, 28 Feb 2017 08:11:10 -0800 (PST) X-AuditID: c1b4fb30-a6b9198000001a00-c3-58b5a11cb8ec Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 1A.8A.06656.C11A5B85; Tue, 28 Feb 2017 17:11:08 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 28 Feb 2017 17:10:52 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tc3FmRTOrbEaeFrGyCdryv/Y/O05cOJthsq7ZoP8b58=; b=Qj8SYpaweUHkSZNv43WufepxbX4m7GW5afKbE6j6yuPVgBScjQ3NFrvX2f0I+K8ZXiz8KE7TdCWmIrKaqVgaGkIv9vLHRuCij37gUj8W7R24/ZkDwrDZ2pO7MLiPTDlk/NWBV8QPS4zsqIrPvi0AhmXXMZ9AgKIru3+IkeOZcgo= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2580.eurprd07.prod.outlook.com (10.173.92.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Tue, 28 Feb 2017 16:10:51 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.0947.011; Tue, 28 Feb 2017 16:10:51 +0000 From: Bo Burman To: "mmusic (mmusic@ietf.org)" Thread-Topic: Shepherd's review of draft-ietf-mmusic-data-channel-sdpneg-11 Thread-Index: AdKR1myZplopSuFrSp2L99aM0eEZvw== Date: Tue, 28 Feb 2017 16:10:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com; x-originating-ip: [192.176.1.81] x-ms-office365-filtering-correlation-id: e81fe9b1-ab01-4673-db37-08d45ff45dd6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2580; x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2580; 7:6YEN4Cvr8wuJUD/BIOHlBfKoErMQ7AUeCSJ9wOLwa9vCYFzWMVUFjgANx465QMH60u3evuMaOf20/Dgl/wJdII5E0bepe9j0pxSrwTHINmjitiYuym/6C40DHFFjo4eFeev4pbyoubQ1xR7kFXN5HjHKLNcgyA6MZ+Lcp0mslu2uohCDgims59DoR3eF4Rs/3biYj0TibSCO3c1c4Hchu8A+ojf12YeEYkHvc3JsuCaMspS+TtEleUHBXjrAnx5aTKQ33GUmUyxY+82DgB7Jkw65fiYSLDnrL6PT4Acq3Zw6j4mq3hVufdYDUCfQAQotznQ20yX8PdG1B7JRtLN1Kw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:AM5PR0701MB2580; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2580; x-forefront-prvs: 0232B30BBC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(189002)(86362001)(6306002)(54896002)(8936002)(77096006)(5660300001)(81156014)(8676002)(9686003)(38730400002)(25786008)(81166006)(99286003)(55016002)(450100001)(6916009)(7696004)(74316002)(6436002)(53936002)(6506006)(19609705001)(3846002)(7736002)(6116002)(102836003)(790700001)(50986999)(3280700002)(54356999)(92566002)(105586002)(110136004)(106356001)(2900100001)(122556002)(101416001)(3660700001)(68736007)(97736004)(66066001)(33656002)(2906002)(189998001)(230783001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2580; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB25775C47EFFE80EF866FE92F8D560AM5PR0701MB2577_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2017 16:10:51.6002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2580 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUyM2K7uq7Mwq0RBh+6dSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMv//rAWzJrMWLGw9T97A+PqBsYuRk4OCQETiYVru9i6GLk4 hATWMUosOTODBcI5wShx+Hs3E4jDItDLLHHq8AVWiMwMJokXLdeYEcq+PGUDGcYmoCExf8dd sMEiAgYSs1fOALOFBdwkLsw8wA4R95a48vMMK4StJ7FxwRUWEJtFQFXi+utNTCA2r0CCRN+2 BrAaRgExie+n1oDFmQXEJW49mc8EcbiAxJI955khbFGJl4//QdVHSkyeeJYdIq4gcWzGShYI 21dix+JuqLi/xLKFHxhBHpAQ6GOWmL/sClQiX2LhjvNsELaVRMfE46wQRfOYJDY8/A01SUbi 5vUnUIndrBJ/D1wA6xYSSJVYvrYV6mUpibtXOqFsGYkXd/ayQryQL7Gx+QQbxJuCEidnPmGZ wKg2C8l3s5CUzUJSBhHXkViw+xMbhK0N9MVrZhj7zIHHTMjiCxjZVzGKFqcWJ+WmGxnppRZl JhcX5+fp5aWWbGIEJp2DW34b7GB8+dzxEKMAB6MSD2/BhK0RQqyJZcWVuYcYJTiYlUR4dxQD hXhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamAMmVCacbwj aVZyfvDBHdt9bu+PO8TWOVWj6N6UBcfPvjOSS/fKEim2qUvK+L9AfW/HJH6pfT7TZh594T6v ZOmvRQrr3G3PTZd7O+uKnFRBhQVj9551Dyy2Tz2hc6jY4rtm5uIZCuerfTkX79qb4iy7KTSp /TiDldirC0dUvwR+uuZ5afLWyaFnlViKMxINtZiLihMBTQlDDTYDAAA= Archived-At: Subject: [MMUSIC] Shepherd's review of draft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 16:11:14 -0000 --_000_AM5PR0701MB25775C47EFFE80EF866FE92F8D560AM5PR0701MB2577_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, WG, I think this document is getting ready for publication request. As part of = making the shepherd's write-up, I have the following comments, to be addres= sed in an updated document: Issues: 1) In section 1: add that also BFCP (Binary Floor Control Protocol) i= s used in the same way as MSRP in examples. 2) In 5.1.1.1, dcmap-stream-id =3D 1*DIGIT allows infinite length of t= his identifier, which seems inappropriate. I suggest providing a maximum le= ngth, maybe matching this to the unsigned 16 bit integer in SCTP (RFC 4960)= , in which case 1*5DIGIT should be sufficient. 3) In 5.1.1.1, quoted-visible ABNF syntax is incorrect, missing "x" af= ter "%" when defining hex characters. Change to: quoted-visible =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or % 4) In 5.1.2.1, text below the example makes reference to MSRP subproto= col, but the example does not explicitly include any MSRP. The single examp= le line uses "accept-types", which is admittedly related to MSRP, but I thi= nk this should be clarified to avoid confusion for readers not familiar wit= h MSRP. 5) In 5.2.2: It is unclear why you differentiate handling of offers an= d answers that contain both "max-retr" and "max-time", mandating to reject = the offer but allowing it in the answer. I think allowing this asymmetry sh= ould either be motivated, or handling should be aligned between offer and a= nswer. 6) In section 6: several examples uses IP addresses that are not align= ed with RFC 6890 (10.10.10.x), which must be changed. Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),= or 203.0.113.0/24 (TEST-NET-3). 7) In Appendix A: same IP address issue as above, change from 79.97.21= 5.79 to an address in the allowed range. Nits: 1) The date line in the document header is one character too long (bey= ond column 72) 2) In section 1: s/In future data channels could/In the future, data c= hannels could/ 3) In section 3: s/sending and receive data/sending and receiving data= / 4) At the very end of section 5.1.2.1: s/in the same document, which r= egisters/in the same document that registers/ 5) In 5.2.4: s/other data channels which are now not included/other da= ta channels that are now not included/ 6) In 5.2.5: s/channels are expected be closed now/channels are expect= ed to be closed now/ 7) In 8.3: s/dcsa usage level only shall use/dcsa usage level only SHA= LL use/ 8) In Appendix A.1: s/either pass to the data channel stack the stream= identifier to assign/either pass the stream identifier to the data channel= stack to assign/ 9) In Appendix A.1: Why are two paragraphs starting with "For data cha= nnels negotiated" indented compared to other text? Is it supposed to be som= e kind of note? Comments from others that are not addressed in -11: 1) Christian Groves commented on Jan 20 that the example in Appendix A= should contain an "a=3Ddtls-id:..." attribute as per other examples in the= draft. 2) Paul Kyzivat commented on Jan 21 that a bullet in section 5.2.3 sho= uld be changed to: o For accepted data channels, the agent MUST create peer instances for the data channels using the SCTP stream identifiers and channel parameters contained in the SDP offer. Cheers, /Bo MMUSIC co-chair --_000_AM5PR0701MB25775C47EFFE80EF866FE92F8D560AM5PR0701MB2577_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authors, WG,

 

I think this document is getting ready for publicati= on request. As part of making the shepherd’s write-up, I have the fol= lowing comments, to be addressed in an updated document:

 

Issues:

1)      In section 1: add that also BFCP (Binary Floor Cont= rol Protocol)  is used in the same way as MSRP in examples.=

2)      In 5.1.1.1, dcmap-stream-id =3D 1*DIGIT allows infi= nite length of this identifier, which seems inappropriate. I suggest provid= ing a maximum length, maybe matching this to the unsigned 16 bit integer in= SCTP (RFC 4960), in which case 1*5DIGIT should be sufficient.

3)      In 5.1.1.1, quoted-visible ABNF syntax is incorrect= , missing “x” after “%” when defining hex character= s. Change to:
quoted-visible  =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or= %

4)      In 5.1.2.1, text below the example makes reference = to MSRP subprotocol, but the example does not explicitly include any MSRP. = The single example line uses “accept-types”, which is admittedl= y related to MSRP, but I think this should be clarified to avoid confusion for readers not familiar with MSRP.

5)      In 5.2.2: It is unclear why you differentiate handl= ing of offers and answers that contain both “max-retr” and R= 20;max-time”, mandating to reject the offer but allowing it in the an= swer. I think allowing this asymmetry should either be motivated, or handling should be aligned between offer and answer.

6)      In section 6: several examples uses IP addresses th= at are not aligned with RFC 6890 (10.10.10.x), which must be changed.
Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),= or 203.0.113.0/24 (TEST-NET-3).

7)      In Appendix A: same IP address issue as above, chan= ge from 79.97.215.79 to an address in the allowed range.

 

Nits:

1)      The date line in the document header is one charact= er too long (beyond column 72)

2)      In section 1: s/In future data channels could/In th= e future, data channels could/

3)      In section 3: s/sending and receive data/sending an= d receiving data/

4)      At the very end of section 5.1.2.1: s/in the same d= ocument, which registers/in the same document that registers/

5)      In 5.2.4: s/other data channels which are now not i= ncluded/other data channels that are now not included/

6)      In 5.2.5: s/channels are expected be closed now/cha= nnels are expected to be closed now/

7)      In 8.3: s/dcsa usage level only shall use/dcsa usag= e level only SHALL use/

8)      In Appendix A.1: s/either pass to the data channel = stack the stream identifier to assign/either pass the stream identifier to = the data channel stack to assign/

9)      In Appendix A.1: Why are two paragraphs starting wi= th “For data channels negotiated” indented compared to other te= xt? Is it supposed to be some kind of note?

 

Comments from others that are not addressed in -11:<= o:p>

1)      Christian Groves commented on Jan 20 that the examp= le in Appendix A should contain an “a=3Ddtls-id:…” attrib= ute as per other examples in the draft.

2)      Paul Kyzivat commented on Jan 21 that a bullet in s= ection 5.2.3 should be changed to:
o For accepted data channels, the agent MUST create peer instances
   for the data channels using the SCTP stream identifiers and    channel parameters contained in the SDP offer.=

 

Cheers,

/Bo

MMUSIC co-chair

 

--_000_AM5PR0701MB25775C47EFFE80EF866FE92F8D560AM5PR0701MB2577_-- From nobody Tue Feb 28 08:13:20 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBFC129519; Tue, 28 Feb 2017 08:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WUGBQ7Ju2zbd; Tue, 28 Feb 2017 08:13:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2910A129621; Tue, 28 Feb 2017 08:13:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBW30518; Tue, 28 Feb 2017 16:13:08 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 28 Feb 2017 16:13:08 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Wed, 1 Mar 2017 00:13:01 +0800 From: Roni Even To: Flemming Andreasen , mmusic , "draft-ietf-mmusic-sdp-simulcast@ietf.org" Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 Thread-Index: AQHSkQotFB71yuqqZ0eyEkM6/3qa4KF+mDSg Date: Tue, 28 Feb 2017 16:13:01 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD77711A@DGGEMM506-MBX.china.huawei.com> References: <01a352cf-9adc-18bb-3cd0-ce82d39e5490@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.205] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.58B5A195.005C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3835620abb3e485cf1d7d9f3352aecd6 Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 16:13:16 -0000 Hi Flemming Sorry for being unresponsive The 07 version addresses my comments and I am OK with this version Roni > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming > Andreasen > Sent: =E9=E5=ED=A0=E1 27 =F4=E1=F8=E5=E0=F8 2017 17:00 > To: mmusic; draft-ietf-mmusic-sdp-simulcast@ietf.org > Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 >=20 > The WGLC on this draft has completed, however we did not receive a single > comment on it, which makes it very difficult to move forward with the > publication request. If you have reviewed the draft, please send a note t= o > the list with your review disposition and any comments you may have (if y= ou > don't have any comments, that's fine too - just let us know you reviewed = it). >=20 > Thanks >=20 > -- Flemming (as MMUSIC co-chair) >=20 > On 2/8/17 6:09 PM, Flemming Andreasen wrote: > > Greetings MMUSIC > > > > This is to announce a 2 week WGLC on the draft: > > > > https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-07.txt > > > > as Proposed Standard. Please review and provide any comments you may > > have on the document by Wednesday, February 22, 2017. Comments > should > > be sent to the document authors and the MMUSIC WG list. If you review > > the document but do not have any comments, please send a note to that > > effect as well. > > > > Thanks > > > > -- Flemming (MMUSIC co-chair) > > > > _______________________________________________ > > 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