From eburger@standardstrack.com Mon Dec 3 09:26:41 2012 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7590021F889D for ; Mon, 3 Dec 2012 09:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwrxxVzeLbO4 for ; Mon, 3 Dec 2012 09:26:41 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id C753821F887D for ; Mon, 3 Dec 2012 09:26:40 -0800 (PST) Received: from [207.239.114.206] (port=5396 helo=[192.168.66.49]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TfZmu-0004h6-Ia for mediactrl@ietf.org; Mon, 03 Dec 2012 09:26:36 -0800 From: Eric Burger Content-Type: multipart/signed; boundary=Apple-Mail-20-429089623; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 3 Dec 2012 09:45:27 -0500 Message-Id: <32EF9DF1-B5EB-4AFE-9080-91BAC1E6559C@standardstrack.com> To: mediactrl@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [MEDIACTRL] WGLC: Call Flows X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:26:41 -0000 --Apple-Mail-20-429089623 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We are almost finished! One last document to go, the Media Control = Channel Framework (CFW) Call Flow Examples. You can pickup a copy here: https://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows Please review CLOSELY, as no matter how many times we tell implementors = to read the base specifications and that this document is simply a = non-normtive example, implementors will blindly copy from this document = and not read the base documents. It MUST be as accurate as possible. Because of the importance of getting this right, the Work Group Last = Call will run until 21 December 2012.= --Apple-Mail-20-429089623 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMjAzMTQ0NTI4WjAjBgkqhkiG9w0BCQQxFgQU FI2IrqAY9bHYtjHDOxRdEzCDRc8wgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAnVKtBSqwk8XcsKCZRUDQteSiNEvlLXIFek4J3CZZUtSvMEE2ny0V UJ/aXFb46wnP6xjlRR9srogDx3QCqFU4hGViBSfZ/IFzCZUP8cpwvKGD3SVPIASqrg/UlDTvbAD0 L02h9oWXk3EQ4aYuCiRSR7+X+L/pLjuwVLOcQLXv5xo/twPjvPMb5BcKzA9aXXp65xeuCtSKrNii Pk1LVkn+SQViD8H2Sdbxd+y/2LKmp0QAfqlllQRuaFjcCXKTxzCxzXSxA79LU7uoxAn1Vg0JPXdb 4Dt/c2lwLlzGhyD7pbrivILFXfx1NUgAFM4u2v8fs0ovrfcD3W8wHnI0M6eVkgAAAAAAAA== --Apple-Mail-20-429089623-- From rjsparks@nostrum.com Mon Dec 3 12:33:28 2012 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E1921F8651 for ; Mon, 3 Dec 2012 12:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.45 X-Spam-Level: X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TIME=2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRWAIKDBvAMh for ; Mon, 3 Dec 2012 12:33:27 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BED7221F863C for ; Mon, 3 Dec 2012 12:33:26 -0800 (PST) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qB3KXPdB046681 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 3 Dec 2012 14:33:25 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <50BD0C95.10401@nostrum.com> Date: Mon, 03 Dec 2012 14:33:25 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: mediactrl@ietf.org References: <32EF9DF1-B5EB-4AFE-9080-91BAC1E6559C@standardstrack.com> In-Reply-To: <32EF9DF1-B5EB-4AFE-9080-91BAC1E6559C@standardstrack.com> Content-Type: multipart/alternative; boundary="------------010008050307000908080709" Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: Re: [MEDIACTRL] WGLC: Call Flows X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 20:33:28 -0000 This is a multi-part message in MIME format. --------------010008050307000908080709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/3/12 8:45 AM, Eric Burger wrote: > We are almost finished! One last document to go, the Media Control Channel Framework (CFW) Call Flow Examples. You can pickup a copy here: > https://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows > > Please review CLOSELY, as no matter how many times we tell implementors to read the base specifications and that this document is simply a non-normtive example, implementors will blindly copy from this document and not read the base documents. It MUST be as accurate as possible. > > Because of the importance of getting this right, the Work Group Last Call will run until 21 December 2012. Yes, please. If you are going to dive deep on any one particular aspect of this review, please let the list know so we spread the effort around. There's a _lot_ to review here. Lorenzo - I really appreciate that the SIP was generated by real implementations - did you set things up where they were actually using example.com and example.net or did you edit the captured messages to say that after the fact? One question about some of the CFW examples. We have this section: 2. Conventions Note that due to RFC formatting conventions, this document often splits SIP/SDP and CFW across lines whose content would exceed 72 characters. A backslash character marks where this line folding has taken place. This backslash and its trailing CRLF and whitespace would not appear in the actual protocol contents. Besides, also note that the indentation of the XML content is only provided for readability: actual messages will follow strict XML syntax, which allows for, but does not require, indentation. Due to the same 72 characters limitation, this document also sometimes splits the content of XML elements across lines: please beware that, when this happens, no whitespace is actually meant to be neither at the beginning nor at the end of the element content. Should it go on to say that the Content-Lengths in the examples were calculated _before_ formatting the example for publication in the RFC? I can't, for example, make the content-length in this example make sense: D1. AS <- MS (CFW CONTROL event, dtmfnotify) -------------------------------------------- CFW 361840da0581 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 179 Even if I rip out _all_ the whitespace outside of the tags and assume a single LF instead of a CRLF, I get 180? 0000000 < m s c i v r v e r s i o n = 0000010 " 1 . 0 " x m l n s = " u r n 0000020 : i e t f : p a r a m s : x m l 0000030 : n s : m s c - i v r " > < e v 0000040 e n t d i a l o g i d = " 3 e 0000050 9 3 6 e 0 " > < d t m f n o t i 0000060 f y m a t c h m o d e = " c o 0000070 n t r o l " d t m f = " 6 " 0000080 t i m e s t a m p = " 2 0 0 8 - 0000090 1 2 - 1 6 T 1 2 : 5 8 : 3 6 Z " 00000a0 / > < / e v e n t > < / m s c i 00000b0 v r > \n RjS > > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl --------------010008050307000908080709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/3/12 8:45 AM, Eric Burger wrote:
We are almost finished! One last document to go, the Media Control Channel Framework (CFW) Call Flow Examples.  You can pickup a copy here:
https://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows

Please review CLOSELY, as no matter how many times we tell implementors to read the base specifications and that this document is simply a non-normtive example,  implementors will blindly copy from this document and not read the base documents. It MUST be as accurate as possible.

Because of the importance of getting this right, the Work Group Last Call will run until 21 December 2012.
Yes, please. If you are going to dive deep on any one particular aspect of this review, please let the list know so
we spread the effort around. There's a _lot_ to review here.

Lorenzo - I really appreciate that the SIP was generated by real implementations - did you set things up where they were actually using example.com and example.net or did you edit the captured messages to say that after the fact?

One question about some of the CFW examples. We have this section:

2.  Conventions

   Note that due to RFC formatting conventions, this document often
   splits SIP/SDP and CFW across lines whose content would exceed 72
   characters.  A backslash character marks where this line folding has
   taken place.  This backslash and its trailing CRLF and whitespace
   would not appear in the actual protocol contents.  Besides, also note
   that the indentation of the XML content is only provided for
   readability: actual messages will follow strict XML syntax, which
   allows for, but does not require, indentation.  Due to the same 72
   characters limitation, this document also sometimes splits the
   content of XML elements across lines: please beware that, when this
   happens, no whitespace is actually meant to be neither at the
   beginning nor at the end of the element content.

Should it go on to say that the Content-Lengths in the examples were
calculated _before_ formatting the example for publication in the RFC?
I can't, for example, make the content-length in this example make sense:

D1. AS <- MS (CFW CONTROL event, dtmfnotify)
--------------------------------------------
   CFW 361840da0581 CONTROL
   Control-Package: msc-ivr/1.0
   Content-Type: application/msc-ivr+xml
   Content-Length: 179

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
      <event dialogid="3e936e0">
         <dtmfnotify matchmode="control" dtmf="6"
                     timestamp="2008-12-16T12:58:36Z"/>
      </event>
   </mscivr>

Even if I rip out _all_ the whitespace outside of the tags and assume
a single LF instead of a CRLF, I get 180?

0000000   <   m   s   c   i   v   r       v   e   r   s   i   o   n   =
0000010   "   1   .   0   "       x   m   l   n   s   =   "   u   r   n
0000020   :   i   e   t   f   :   p   a   r   a   m   s   :   x   m   l
0000030   :   n   s   :   m   s   c   -   i   v   r   "   >   <   e   v
0000040   e   n   t       d   i   a   l   o   g   i   d   =   "   3   e
0000050   9   3   6   e   0   "   >   <   d   t   m   f   n   o   t   i
0000060   f   y       m   a   t   c   h   m   o   d   e   =   "   c   o
0000070   n   t   r   o   l   "       d   t   m   f   =   "   6   "   
0000080   t   i   m   e   s   t   a   m   p   =   "   2   0   0   8   -
0000090   1   2   -   1   6   T   1   2   :   5   8   :   3   6   Z   "
00000a0   /   >   <   /   e   v   e   n   t   >   <   /   m   s   c   i
00000b0   v   r   >  \n 

RjS




    

      

      

      
_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

    

    

  


--------------010008050307000908080709--

From lorenzo@meetecho.com  Mon Dec  3 15:00:41 2012
Return-Path: 
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DDA21F8977 for ; Mon,  3 Dec 2012 15:00:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.581
X-Spam-Level: *
X-Spam-Status: No, score=1.581 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_TIME=2.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqLOiL10vJDP for ; Mon,  3 Dec 2012 15:00:41 -0800 (PST)
Received: from smtpdg3.aruba.it (smtpdg221.aruba.it [62.149.158.221]) by ietfa.amsl.com (Postfix) with ESMTP id 86A1421F896E for ; Mon,  3 Dec 2012 15:00:40 -0800 (PST)
Received: from rainpc ([79.30.35.16]) by smtpcmd01.ad.aruba.it with bizsmtp id XB0c1k00S0LtQiv01B0cgR; Tue, 04 Dec 2012 00:00:38 +0100
Date: Tue, 4 Dec 2012 00:00:35 +0100
From: Lorenzo Miniero 
To: Robert Sparks 
Message-ID: <20121204000035.796e04b4@rainpc>
In-Reply-To: <50BD0C95.10401@nostrum.com>
References: <32EF9DF1-B5EB-4AFE-9080-91BAC1E6559C@standardstrack.com> <50BD0C95.10401@nostrum.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: mediactrl@ietf.org
Subject: Re: [MEDIACTRL] WGLC: Call Flows
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2012 23:00:41 -0000

On Mon, 03 Dec 2012 14:33:25 -0600
Robert Sparks  wrote:

> On 12/3/12 8:45 AM, Eric Burger wrote:
> > We are almost finished! One last document to go, the Media Control Channel Framework (CFW) Call Flow Examples.  You can pickup a copy here:
> > https://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows
> >
> > Please review CLOSELY, as no matter how many times we tell implementors to read the base specifications and that this document is simply a non-normtive example,  implementors will blindly copy from this document and not read the base documents. It MUST be as accurate as possible.
> >
> > Because of the importance of getting this right, the Work Group Last Call will run until 21 December 2012.
> Yes, please. If you are going to dive deep on any one particular aspect 
> of this review, please let the list know so
> we spread the effort around. There's a _lot_ to review here.
> 
> Lorenzo - I really appreciate that the SIP was generated by real 
> implementations - did you set things up where they were actually using 
> example.com and example.net or did you edit the captured messages to say 
> that after the fact?
> 


Those messages were edited, as they originally involved the local environment we deployed our testbed in. I tried to make sure the content lengths were properly adjusted where necessary, though.


> One question about some of the CFW examples. We have this section:
> 
> 2.  Conventions
> 
>     Note that due to RFC formatting conventions, this document often
>     splits SIP/SDP and CFW across lines whose content would exceed 72
>     characters.  A backslash character marks where this line folding has
>     taken place.  This backslash and its trailing CRLF and whitespace
>     would not appear in the actual protocol contents.  Besides, also note
>     that the indentation of the XML content is only provided for
>     readability: actual messages will follow strict XML syntax, which
>     allows for, but does not require, indentation.  Due to the same 72
>     characters limitation, this document also sometimes splits the
>     content of XML elements across lines: please beware that, when this
>     happens, no whitespace is actually meant to be neither at the
>     beginning nor at the end of the element content.
> 
> Should it go on to say that the Content-Lengths in the examples were
> calculated _before_ formatting the example for publication in the RFC?
> I can't, for example, make the content-length in this example make sense:
> 
> D1. AS <- MS (CFW CONTROL event, dtmfnotify)
> --------------------------------------------
>     CFW 361840da0581 CONTROL
>     Control-Package: msc-ivr/1.0
>     Content-Type: application/msc-ivr+xml
>     Content-Length: 179
> 
>     
>        
>                                  timestamp="2008-12-16T12:58:36Z"/>
>        
>     
> 
> Even if I rip out _all_ the whitespace outside of the tags and assume
> a single LF instead of a CRLF, I get 180?
> 
> 0000000   <   m   s   c   i   v   r       v   e   r   s   i   o n   =
> 0000010   "   1   .   0   "       x   m   l   n   s   =   "   u r   n
> 0000020   :   i   e   t   f   :   p   a   r   a   m   s   :   x m   l
> 0000030   :   n   s   :   m   s   c   -   i   v   r   "   > <   e   v
> 0000040   e   n   t       d   i   a   l   o   g   i   d   =   " 3   e
> 0000050   9   3   6   e   0   "   >   <   d   t   m   f   n o   t   i
> 0000060   f   y       m   a   t   c   h   m   o   d   e   =   " c   o
> 0000070   n   t   r   o   l   "       d   t   m   f   =   "   6 "
> 0000080   t   i   m   e   s   t   a   m   p   =   "   2   0   0 8   -
> 0000090   1   2   -   1   6   T   1   2   :   5   8   :   3   6 Z   "
> 00000a0   /   >   <   /   e   v   e   n   t   >   < /   m   s   c   i
> 00000b0   v   r   >  \n
> 


Just as with SIP, we tried to keep the content length consistent when the payload was edited (e.g., in small changes in the protocol that didn't really need a new dump). With respect to the example you reported, the payload in our prototype does not include the trailing LF either, but just the XML content, so I guess that's where the extra character in the count comes from.

Lorenzo


> RjS
> 
> 
> 
> >
> > _______________________________________________
> > MEDIACTRL mailing list
> > MEDIACTRL@ietf.org
> > https://www.ietf.org/mailman/listinfo/mediactrl
> > Supplemental Web Site:
> > http://www.standardstrack.com/ietf/mediactrl
> 


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

From rjsparks@nostrum.com  Mon Dec  3 15:04:10 2012
Return-Path: 
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7575821F897C for ; Mon,  3 Dec 2012 15:04:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.286
X-Spam-Level: 
X-Spam-Status: No, score=-101.286 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_00=-2.599, MANGLED_TIME=2.3, SPF_PASS=-0.001,  USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkhl78i--L8Q for ; Mon,  3 Dec 2012 15:04:09 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9199821F896E for ; Mon,  3 Dec 2012 15:04:09 -0800 (PST)
Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qB3N48E8063763 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 3 Dec 2012 17:04:09 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <50BD2FE8.2080907@nostrum.com>
Date: Mon, 03 Dec 2012 17:04:08 -0600
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Lorenzo Miniero 
References: <32EF9DF1-B5EB-4AFE-9080-91BAC1E6559C@standardstrack.com> <50BD0C95.10401@nostrum.com> <20121204000035.796e04b4@rainpc>
In-Reply-To: <20121204000035.796e04b4@rainpc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism)
Cc: mediactrl@ietf.org
Subject: Re: [MEDIACTRL] WGLC: Call Flows
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2012 23:04:10 -0000

inline -

On 12/3/12 5:00 PM, Lorenzo Miniero wrote:
> On Mon, 03 Dec 2012 14:33:25 -0600
> Robert Sparks  wrote:
>
>> On 12/3/12 8:45 AM, Eric Burger wrote:
>>> We are almost finished! One last document to go, the Media Control Channel Framework (CFW) Call Flow Examples.  You can pickup a copy here:
>>> https://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows
>>>
>>> Please review CLOSELY, as no matter how many times we tell implementors to read the base specifications and that this document is simply a non-normtive example,  implementors will blindly copy from this document and not read the base documents. It MUST be as accurate as possible.
>>>
>>> Because of the importance of getting this right, the Work Group Last Call will run until 21 December 2012.
>> Yes, please. If you are going to dive deep on any one particular aspect
>> of this review, please let the list know so
>> we spread the effort around. There's a _lot_ to review here.
>>
>> Lorenzo - I really appreciate that the SIP was generated by real
>> implementations - did you set things up where they were actually using
>> example.com and example.net or did you edit the captured messages to say
>> that after the fact?
>>
>
> Those messages were edited, as they originally involved the local environment we deployed our testbed in. I tried to make sure the content lengths were properly adjusted where necessary, though.
That helps, thanks. Reviews should look at the places those names occur 
and make sure the right ones landed in the right places.
>
>
>> One question about some of the CFW examples. We have this section:
>>
>> 2.  Conventions
>>
>>      Note that due to RFC formatting conventions, this document often
>>      splits SIP/SDP and CFW across lines whose content would exceed 72
>>      characters.  A backslash character marks where this line folding has
>>      taken place.  This backslash and its trailing CRLF and whitespace
>>      would not appear in the actual protocol contents.  Besides, also note
>>      that the indentation of the XML content is only provided for
>>      readability: actual messages will follow strict XML syntax, which
>>      allows for, but does not require, indentation.  Due to the same 72
>>      characters limitation, this document also sometimes splits the
>>      content of XML elements across lines: please beware that, when this
>>      happens, no whitespace is actually meant to be neither at the
>>      beginning nor at the end of the element content.
>>
>> Should it go on to say that the Content-Lengths in the examples were
>> calculated _before_ formatting the example for publication in the RFC?
>> I can't, for example, make the content-length in this example make sense:
>>
>> D1. AS <- MS (CFW CONTROL event, dtmfnotify)
>> --------------------------------------------
>>      CFW 361840da0581 CONTROL
>>      Control-Package: msc-ivr/1.0
>>      Content-Type: application/msc-ivr+xml
>>      Content-Length: 179
>>
>>      
>>         
>>            >                        timestamp="2008-12-16T12:58:36Z"/>
>>         
>>      
>>
>> Even if I rip out _all_ the whitespace outside of the tags and assume
>> a single LF instead of a CRLF, I get 180?
>>
>> 0000000   <   m   s   c   i   v   r       v   e   r   s   i   o n   =
>> 0000010   "   1   .   0   "       x   m   l   n   s   =   "   u r   n
>> 0000020   :   i   e   t   f   :   p   a   r   a   m   s   :   x m   l
>> 0000030   :   n   s   :   m   s   c   -   i   v   r   "   > <   e   v
>> 0000040   e   n   t       d   i   a   l   o   g   i   d   =   " 3   e
>> 0000050   9   3   6   e   0   "   >   <   d   t   m   f   n o   t   i
>> 0000060   f   y       m   a   t   c   h   m   o   d   e   =   " c   o
>> 0000070   n   t   r   o   l   "       d   t   m   f   =   "   6 "
>> 0000080   t   i   m   e   s   t   a   m   p   =   "   2   0   0 8   -
>> 0000090   1   2   -   1   6   T   1   2   :   5   8   :   3   6 Z   "
>> 00000a0   /   >   <   /   e   v   e   n   t   >   < /   m   s   c   i
>> 00000b0   v   r   >  \n
>>
>
> Just as with SIP, we tried to keep the content length consistent when the payload was edited (e.g., in small changes in the protocol that didn't really need a new dump). With respect to the example you reported, the payload in our prototype does not include the trailing LF either, but just the XML content, so I guess that's where the extra character in the count comes from.
That would be it. The type application/msc-ivr+xml doesn't require the 
trailing newline does it?
>
> Lorenzo
>
>
>> RjS
>>
>>
>>
>>> _______________________________________________
>>> MEDIACTRL mailing list
>>> MEDIACTRL@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mediactrl
>>> Supplemental Web Site:
>>> http://www.standardstrack.com/ietf/mediactrl
>


From lorenzo@meetecho.com  Mon Dec  3 15:13:48 2012
Return-Path: 
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8272B21F8968 for ; Mon,  3 Dec 2012 15:13:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.734
X-Spam-Level: *
X-Spam-Status: No, score=1.734 tagged_above=-999 required=5 tests=[AWL=-0.153,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IT=0.635, MANGLED_TIME=2.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxsjLKru24gK for ; Mon,  3 Dec 2012 15:13:47 -0800 (PST)
Received: from smtpdg7.aruba.it (unknown [62.149.158.225]) by ietfa.amsl.com (Postfix) with ESMTP id 20A0421F86F3 for ; Mon,  3 Dec 2012 15:13:42 -0800 (PST)
Received: from rainpc ([79.30.35.16]) by smtpcmd03.ad.aruba.it with bizsmtp id XBDg1k00V0LtQiv01BDgDq; Tue, 04 Dec 2012 00:13:41 +0100
Date: Tue, 4 Dec 2012 00:13:39 +0100
From: Lorenzo Miniero 
To: Robert Sparks 
Message-ID: <20121204001339.0beadeb7@rainpc>
In-Reply-To: <50BD2FE8.2080907@nostrum.com>
References: <32EF9DF1-B5EB-4AFE-9080-91BAC1E6559C@standardstrack.com> <50BD0C95.10401@nostrum.com> <20121204000035.796e04b4@rainpc> <50BD2FE8.2080907@nostrum.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: mediactrl@ietf.org
Subject: Re: [MEDIACTRL] WGLC: Call Flows
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2012 23:13:48 -0000

Replying inline,


On Mon, 03 Dec 2012 17:04:08 -0600
Robert Sparks  wrote:

> inline -
> 
> On 12/3/12 5:00 PM, Lorenzo Miniero wrote:
> > On Mon, 03 Dec 2012 14:33:25 -0600
> > Robert Sparks  wrote:
> >
> >> On 12/3/12 8:45 AM, Eric Burger wrote:
> >>> We are almost finished! One last document to go, the Media Control Channel Framework (CFW) Call Flow Examples.  You can pickup a copy here:
> >>> https://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows
> >>>
> >>> Please review CLOSELY, as no matter how many times we tell implementors to read the base specifications and that this document is simply a non-normtive example,  implementors will blindly copy from this document and not read the base documents. It MUST be as accurate as possible.
> >>>
> >>> Because of the importance of getting this right, the Work Group Last Call will run until 21 December 2012.
> >> Yes, please. If you are going to dive deep on any one particular aspect
> >> of this review, please let the list know so
> >> we spread the effort around. There's a _lot_ to review here.
> >>
> >> Lorenzo - I really appreciate that the SIP was generated by real
> >> implementations - did you set things up where they were actually using
> >> example.com and example.net or did you edit the captured messages to say
> >> that after the fact?
> >>
> >
> > Those messages were edited, as they originally involved the local environment we deployed our testbed in. I tried to make sure the content lengths were properly adjusted where necessary, though.
> That helps, thanks. Reviews should look at the places those names occur 
> and make sure the right ones landed in the right places.
> >
> >
> >> One question about some of the CFW examples. We have this section:
> >>
> >> 2.  Conventions
> >>
> >>      Note that due to RFC formatting conventions, this document often
> >>      splits SIP/SDP and CFW across lines whose content would exceed 72
> >>      characters.  A backslash character marks where this line folding has
> >>      taken place.  This backslash and its trailing CRLF and whitespace
> >>      would not appear in the actual protocol contents.  Besides, also note
> >>      that the indentation of the XML content is only provided for
> >>      readability: actual messages will follow strict XML syntax, which
> >>      allows for, but does not require, indentation.  Due to the same 72
> >>      characters limitation, this document also sometimes splits the
> >>      content of XML elements across lines: please beware that, when this
> >>      happens, no whitespace is actually meant to be neither at the
> >>      beginning nor at the end of the element content.
> >>
> >> Should it go on to say that the Content-Lengths in the examples were
> >> calculated _before_ formatting the example for publication in the RFC?
> >> I can't, for example, make the content-length in this example make sense:
> >>
> >> D1. AS <- MS (CFW CONTROL event, dtmfnotify)
> >> --------------------------------------------
> >>      CFW 361840da0581 CONTROL
> >>      Control-Package: msc-ivr/1.0
> >>      Content-Type: application/msc-ivr+xml
> >>      Content-Length: 179
> >>
> >>      
> >>         
> >>             >>                        timestamp="2008-12-16T12:58:36Z"/>
> >>         
> >>      
> >>
> >> Even if I rip out _all_ the whitespace outside of the tags and assume
> >> a single LF instead of a CRLF, I get 180?
> >>
> >> 0000000   <   m   s   c   i   v   r       v   e   r   s   i   o n   =
> >> 0000010   "   1   .   0   "       x   m   l   n   s   =   "   u r   n
> >> 0000020   :   i   e   t   f   :   p   a   r   a   m   s   :   x m   l
> >> 0000030   :   n   s   :   m   s   c   -   i   v   r   "   > <   e   v
> >> 0000040   e   n   t       d   i   a   l   o   g   i   d   =   " 3   e
> >> 0000050   9   3   6   e   0   "   >   <   d   t   m   f   n o   t   i
> >> 0000060   f   y       m   a   t   c   h   m   o   d   e   =   " c   o
> >> 0000070   n   t   r   o   l   "       d   t   m   f   =   "   6 "
> >> 0000080   t   i   m   e   s   t   a   m   p   =   "   2   0   0 8   -
> >> 0000090   1   2   -   1   6   T   1   2   :   5   8   :   3   6 Z   "
> >> 00000a0   /   >   <   /   e   v   e   n   t   >   < /   m   s   c   i
> >> 00000b0   v   r   >  \n
> >>
> >
> > Just as with SIP, we tried to keep the content length consistent when the payload was edited (e.g., in small changes in the protocol that didn't really need a new dump). With respect to the example you reported, the payload in our prototype does not include the trailing LF either, but just the XML content, so I guess that's where the extra character in the count comes from.
> That would be it. The type application/msc-ivr+xml doesn't require the 
> trailing newline does it?


I just checked and it looks like it doesn't, and I guess the same applies to the mixer spec as well.

Lorenzo


> >
> > Lorenzo
> >
> >
> >> RjS
> >>
> >>
> >>
> >>> _______________________________________________
> >>> MEDIACTRL mailing list
> >>> MEDIACTRL@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/mediactrl
> >>> Supplemental Web Site:
> >>> http://www.standardstrack.com/ietf/mediactrl
> >
> 


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

From eburger@standardstrack.com  Tue Dec  4 07:16:06 2012
Return-Path: 
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5130121F8BF3 for ; Tue,  4 Dec 2012 07:16:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.999
X-Spam-Level: 
X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31SRFD-a9DQN for ; Tue,  4 Dec 2012 07:16:05 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id D29E821F8BF2 for ; Tue,  4 Dec 2012 07:16:05 -0800 (PST)
Received: from dhcp63-140-165-138.hil-sjchshx.sjc.wayport.net ([63.140.165.138]:64997) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TfuE6-00061N-Fw for mediactrl@ietf.org; Tue, 04 Dec 2012 07:16:02 -0800
From: Eric Burger 
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/signed; boundary=Apple-Mail-109-517324212; protocol="application/pkcs7-signature"; micalg=sha1
Date: Tue, 4 Dec 2012 07:16:02 -0800
In-Reply-To: <20121204001339.0beadeb7@rainpc>
To: mediactrl@ietf.org
References: <32EF9DF1-B5EB-4AFE-9080-91BAC1E6559C@standardstrack.com> <50BD0C95.10401@nostrum.com> <20121204000035.796e04b4@rainpc> <50BD2FE8.2080907@nostrum.com> <20121204001339.0beadeb7@rainpc>
Message-Id: <6F92011F-C9AB-4A8F-9500-7346F6C49923@standardstrack.com>
X-Mailer: Apple Mail (2.1085)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: Re: [MEDIACTRL] WGLC: Call Flows
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 15:16:06 -0000

--Apple-Mail-109-517324212
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

This is why we need to look VERY closely at this document. It will =
uncover assumptions that were left unstated.  What we miss will be =
considered gospel, so please look long and hard!

On Dec 3, 2012, at 3:13 PM, Lorenzo Miniero wrote:

>>> Just as with SIP, we tried to keep the content length consistent =
when the payload was edited (e.g., in small changes in the protocol that =
didn't really need a new dump). With respect to the example you =
reported, the payload in our prototype does not include the trailing LF =
either, but just the XML content, so I guess that's where the extra =
character in the count comes from.
>> That would be it. The type application/msc-ivr+xml doesn't require =
the=20
>> trailing newline does it?
>=20
>=20
> I just checked and it looks like it doesn't, and I guess the same =
applies to the mixer spec as well.


--Apple-Mail-109-517324212
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w
ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR
Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w
NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx
FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx
ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz
dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx
B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8
om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG
TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl
yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j
BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59
MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j
b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu
Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw
DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8
NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s
APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK
N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU
TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD
AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG
A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU
IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO
LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw
MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD
VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9
VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD
jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS
TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy
fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B
AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU
ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw
EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0
LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG
AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy
dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN
BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu
PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i
kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq
szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L
SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC
AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E
TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT
ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI
hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST
2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV
SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup
hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7
nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud
IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot
2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB
BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw
KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK
oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k
U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny
dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB
LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi
dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo
u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG
61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo
ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm
Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT
xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM
aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMjA0MTUxNjAyWjAjBgkqhkiG9w0BCQQxFgQU
a5RemmyvbfjJafah0dtK1sYLSKcwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g
YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug
gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT
B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw
DQYJKoZIhvcNAQEBBQAEggEAWZ0IiQOg8fSDElawEkMJrk5ViMJ6w8sJJeI61yTiqRW2oEOP8oPT
2Lufqf8ZYAmjXQTDErhZVT80D4epYFaPiW+fwIDT0aZeIJKzLUOSpz2dZwgIyQ3eURZw+az00ikx
kDPUTYtHqOy75M8f9MV9tJ5Q/JjnCd2HGqiZjXeoFtCJFIF48OWGCFk6HRGBEdvX4JeVRlpMflGJ
qmYrCZcZDu7s59v5sOwfKo9yeKQuU5PnzAETmytC8DcDNhtmatxVyMGMw2Yg4WzpR2DkBa2cUMIl
kOtPmVgJ4eHtka/CPup9znRYs9VvoKIPvQWVBbA0KmZdmJwqz9X0iumqTJ3GmQAAAAAAAA==

--Apple-Mail-109-517324212--

From eburger@standardstrack.com  Thu Dec 13 13:55:16 2012
Return-Path: 
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391B021F8BE8 for ; Thu, 13 Dec 2012 13:55:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.949
X-Spam-Level: 
X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-dIkeEbOpCW for ; Thu, 13 Dec 2012 13:55:15 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id B8B7921F8BE7 for ; Thu, 13 Dec 2012 13:55:15 -0800 (PST)
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:63195 helo=[192.168.15.175]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TjGkL-00047D-Dq; Thu, 13 Dec 2012 13:55:14 -0800
From: Eric Burger 
Content-Type: multipart/signed; boundary=Apple-Mail-210--828608470; protocol="application/pkcs7-signature"; micalg=sha1
Date: Thu, 13 Dec 2012 16:55:13 -0500
To: mediactrl@ietf.org
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: [MEDIACTRL]  support
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Dec 2012 21:55:16 -0000

--Apple-Mail-210--828608470
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Section 5.1.5.21 of =
http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ describes an =
indicator, , as to whether or not a Media Server supports =
SRTP.

We were thinking there could be some opaque string that would describe =
the keying mechanism.  However, as numerous ADs have pointed out, there =
is no IANA registry for such mechanisms.

I would offer we be pragmatic, and I would like to hear from =
manufacturers principally but others with skin in the game. =
Specifically, what if we said there is one and only one official, =
supported keying mechanism, namely DTLS-SRTP?  While it is true that =
today most SIP SRTP implementations are SDES, the user community is =
demanding a move to DTLS-SRTP and DTLS-SRTP will also be the only keying =
mechanism for RTCWEB.

So, the proposed text would be:

5.1.5.21.  

   The  element allows a Media Server to declare support for
   encrypting RTP media streams using RFC 3711 [RFC3711].  The element
   MAY be present.  If the element is present, then the Media Server =
supports
   DTLS-SRTP [RFC 5763].

   The  element has no attributes.


Anyone want to see something different?=

--Apple-Mail-210--828608470
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w
ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR
Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w
NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx
FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx
ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz
dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx
B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8
om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG
TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl
yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j
BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59
MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j
b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu
Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw
DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8
NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s
APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK
N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU
TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD
AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG
A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU
IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO
LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw
MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD
VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9
VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD
jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS
TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy
fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B
AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU
ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw
EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0
LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG
AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy
dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN
BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu
PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i
kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq
szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L
SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC
AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E
TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT
ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI
hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST
2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV
SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup
hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7
nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud
IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot
2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB
BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw
KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK
oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k
U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny
dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB
LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi
dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo
u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG
61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo
ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm
Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT
xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM
aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMjEzMjE1NTEzWjAjBgkqhkiG9w0BCQQxFgQU
ks8z99wTY8REmt7wTy79VoLBxX0wgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g
YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug
gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT
B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw
DQYJKoZIhvcNAQEBBQAEggEAG18cuoaA4NCmx7Wb2O3Bfn25WBBlA1Q8Z0OsBGUqFU2p1NzebS94
z8qwKeLO05whthB0pJXdeM5OP/mLQdOQAg8YBl08M/vR1OR5QmysZGACsWn9/atjeYz855KrDJn+
fCcltLrD5W6ixIBXwdOVbqSGn+6o1c0U3stPB3j6YGiAzeAC96LxGGxBnm8jtLqy4T/TXFD+A0/e
t/wFEQDMUHWNTv0HiaYkS6LAQhnnjeo+QtcpWMR3oARr/fxOz30LKUb/OWYRfFBrOztFOg70KO+v
10arZyaleErV/cG1yIETKUX+ueeTnttLRiSNSTeMctI1S21djMtEPx5Jb1YuzgAAAAAAAA==

--Apple-Mail-210--828608470--

From chris-standards@ns-technologies.com  Fri Dec 14 04:06:16 2012
Return-Path: 
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2D021F85C6 for ; Fri, 14 Dec 2012 04:06:16 -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=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+y-KJbAXJZJ for ; Fri, 14 Dec 2012 04:06:16 -0800 (PST)
Received: from host.quksdns12.net (ns1.quksdns12.net [82.147.22.230]) by ietfa.amsl.com (Postfix) with ESMTP id A7DD421F85AE for ; Fri, 14 Dec 2012 04:06:15 -0800 (PST)
Received: from [195.171.3.120] (port=2755 helo=[192.168.2.5]) by host.quksdns12.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TjU1t-0020IR-V7 for mediactrl@ietf.org; Fri, 14 Dec 2012 12:06:14 +0000
Message-ID: <50CB15E6.9090609@ns-technologies.com>
Date: Fri, 14 Dec 2012 12:04:54 +0000
From: Chris Boulton 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: mediactrl@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070305080908040003060106"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.quksdns12.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ns-technologies.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: Re: [MEDIACTRL]  support
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 12:06:16 -0000

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

+1 from me.

On 13/12/2012 21:55, Eric Burger wrote:
> Section 5.1.5.21 of http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ describes an indicator, , as to whether or not a Media Server supports SRTP.
>
> We were thinking there could be some opaque string that would describe the keying mechanism.  However, as numerous ADs have pointed out, there is no IANA registry for such mechanisms.
>
> I would offer we be pragmatic, and I would like to hear from manufacturers principally but others with skin in the game. Specifically, what if we said there is one and only one official, supported keying mechanism, namely DTLS-SRTP?  While it is true that today most SIP SRTP implementations are SDES, the user community is demanding a move to DTLS-SRTP and DTLS-SRTP will also be the only keying mechanism for RTCWEB.
>
> So, the proposed text would be:
>
> 5.1.5.21.  
>
>     The  element allows a Media Server to declare support for
>     encrypting RTP media streams using RFC 3711 [RFC3711].  The element
>     MAY be present.  If the element is present, then the Media Server supports
>     DTLS-SRTP [RFC 5763].
>
>     The  element has no attributes.
>
>
> Anyone want to see something different?
>
>
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl


-- 
Chris Boulton
CTO & Co-founder
NS-Technologies 
m: +44.7876.476681

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


  
    
  
  
    
+1 from me.

      

      On 13/12/2012 21:55, Eric Burger wrote:

    

    

      
Section 5.1.5.21 of http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ describes an indicator, <encryption>, as to whether or not a Media Server supports SRTP.

We were thinking there could be some opaque string that would describe the keying mechanism.  However, as numerous ADs have pointed out, there is no IANA registry for such mechanisms.

I would offer we be pragmatic, and I would like to hear from manufacturers principally but others with skin in the game. Specifically, what if we said there is one and only one official, supported keying mechanism, namely DTLS-SRTP?  While it is true that today most SIP SRTP implementations are SDES, the user community is demanding a move to DTLS-SRTP and DTLS-SRTP will also be the only keying mechanism for RTCWEB.

So, the proposed text would be:

5.1.5.21.  <encryption>

   The <encryption> element allows a Media Server to declare support for
   encrypting RTP media streams using RFC 3711 [RFC3711].  The element
   MAY be present.  If the element is present, then the Media Server supports
   DTLS-SRTP [RFC 5763].

   The <encryption> element has no attributes.


Anyone want to see something different?

      

      

      

      
_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

    

    

    

    
-- 

      Chris Boulton

      CTO & Co-founder

      NS-Technologies

      m: +44.7876.476681

    

  


--------------070305080908040003060106--

From lorenzo@meetecho.com  Fri Dec 14 04:15:33 2012
Return-Path: 
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DFA21F8559 for ; Fri, 14 Dec 2012 04:15:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWzCS3dCj1Md for ; Fri, 14 Dec 2012 04:15:33 -0800 (PST)
Received: from smtpdg3.aruba.it (smtpdg221.aruba.it [62.149.158.221]) by ietfa.amsl.com (Postfix) with ESMTP id A74F321F8558 for ; Fri, 14 Dec 2012 04:15:32 -0800 (PST)
Received: from rainpc ([79.42.9.118]) by smtpcmd01.ad.aruba.it with bizsmtp id bQFS1k00S2Yo6iP01QFSzw; Fri, 14 Dec 2012 13:15:28 +0100
Date: Fri, 14 Dec 2012 13:15:26 +0100
From: Lorenzo Miniero 
To: Chris Boulton 
Message-ID: <20121214131526.6a3ef304@rainpc>
In-Reply-To: <50CB15E6.9090609@ns-technologies.com>
References:  <50CB15E6.9090609@ns-technologies.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: mediactrl@ietf.org
Subject: Re: [MEDIACTRL]  support
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 12:15:33 -0000

On Fri, 14 Dec 2012 12:04:54 +0000
Chris Boulton  wrote:

> +1 from me.
> 


+1 from me as well,

L.


> On 13/12/2012 21:55, Eric Burger wrote:
> > Section 5.1.5.21 of http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ describes an indicator, , as to whether or not a Media Server supports SRTP.
> >
> > We were thinking there could be some opaque string that would describe the keying mechanism.  However, as numerous ADs have pointed out, there is no IANA registry for such mechanisms.
> >
> > I would offer we be pragmatic, and I would like to hear from manufacturers principally but others with skin in the game. Specifically, what if we said there is one and only one official, supported keying mechanism, namely DTLS-SRTP?  While it is true that today most SIP SRTP implementations are SDES, the user community is demanding a move to DTLS-SRTP and DTLS-SRTP will also be the only keying mechanism for RTCWEB.
> >
> > So, the proposed text would be:
> >
> > 5.1.5.21.  
> >
> >     The  element allows a Media Server to declare support for
> >     encrypting RTP media streams using RFC 3711 [RFC3711].  The element
> >     MAY be present.  If the element is present, then the Media Server supports
> >     DTLS-SRTP [RFC 5763].
> >
> >     The  element has no attributes.
> >
> >
> > Anyone want to see something different?
> >
> >
> > _______________________________________________
> > MEDIACTRL mailing list
> > MEDIACTRL@ietf.org
> > https://www.ietf.org/mailman/listinfo/mediactrl
> > Supplemental Web Site:
> > http://www.standardstrack.com/ietf/mediactrl
> 
> 
> -- 
> Chris Boulton
> CTO & Co-founder
> NS-Technologies 
> m: +44.7876.476681


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

From chris@ns-technologies.com  Fri Dec 14 04:03:19 2012
Return-Path: 
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18E121F845A for ; Fri, 14 Dec 2012 04:03:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level: 
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buMRt060SmQn for ; Fri, 14 Dec 2012 04:03:15 -0800 (PST)
Received: from host.quksdns12.net (ns1.quksdns12.net [82.147.22.230]) by ietfa.amsl.com (Postfix) with ESMTP id BABFE21F85ED for ; Fri, 14 Dec 2012 04:03:14 -0800 (PST)
Received: from [195.171.3.120] (port=2728 helo=[192.168.2.5]) by host.quksdns12.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TjTyz-001zKD-Cf for mediactrl@ietf.org; Fri, 14 Dec 2012 12:03:13 +0000
Message-ID: <50CB1530.7040702@ns-technologies.com>
Date: Fri, 14 Dec 2012 12:01:52 +0000
From: Chris Boulton 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: mediactrl@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040406070607040903030809"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.quksdns12.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ns-technologies.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Mailman-Approved-At: Fri, 14 Dec 2012 08:17:22 -0800
Subject: Re: [MEDIACTRL]  support
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 12:03:19 -0000

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

+1 from me.

On 13/12/2012 21:55, Eric Burger wrote:
> Section 5.1.5.21 of http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ describes an indicator, , as to whether or not a Media Server supports SRTP.
>
> We were thinking there could be some opaque string that would describe the keying mechanism.  However, as numerous ADs have pointed out, there is no IANA registry for such mechanisms.
>
> I would offer we be pragmatic, and I would like to hear from manufacturers principally but others with skin in the game. Specifically, what if we said there is one and only one official, supported keying mechanism, namely DTLS-SRTP?  While it is true that today most SIP SRTP implementations are SDES, the user community is demanding a move to DTLS-SRTP and DTLS-SRTP will also be the only keying mechanism for RTCWEB.
>
> So, the proposed text would be:
>
> 5.1.5.21.  
>
>     The  element allows a Media Server to declare support for
>     encrypting RTP media streams using RFC 3711 [RFC3711].  The element
>     MAY be present.  If the element is present, then the Media Server supports
>     DTLS-SRTP [RFC 5763].
>
>     The  element has no attributes.
>
>
> Anyone want to see something different?
>
>
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl


-- 
Chris Boulton
CTO & Co-founder
NS-Technologies 
m: +44.7876.476681

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


  
    
  
  
    
+1 from me.

      

      On 13/12/2012 21:55, Eric Burger wrote:

    

    

      
Section 5.1.5.21 of http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ describes an indicator, <encryption>, as to whether or not a Media Server supports SRTP.

We were thinking there could be some opaque string that would describe the keying mechanism.  However, as numerous ADs have pointed out, there is no IANA registry for such mechanisms.

I would offer we be pragmatic, and I would like to hear from manufacturers principally but others with skin in the game. Specifically, what if we said there is one and only one official, supported keying mechanism, namely DTLS-SRTP?  While it is true that today most SIP SRTP implementations are SDES, the user community is demanding a move to DTLS-SRTP and DTLS-SRTP will also be the only keying mechanism for RTCWEB.

So, the proposed text would be:

5.1.5.21.  <encryption>

   The <encryption> element allows a Media Server to declare support for
   encrypting RTP media streams using RFC 3711 [RFC3711].  The element
   MAY be present.  If the element is present, then the Media Server supports
   DTLS-SRTP [RFC 5763].

   The <encryption> element has no attributes.


Anyone want to see something different?

      

      

      

      
_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

    

    

    

    
-- 

      Chris Boulton

      CTO & Co-founder

      NS-Technologies

      m: +44.7876.476681

    

  


--------------040406070607040903030809--

From tobia.castaldi@unina.it  Fri Dec 14 08:25:21 2012
Return-Path: 
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EE021F899D for ; Fri, 14 Dec 2012 08:25:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0D-KbbCx29jE for ; Fri, 14 Dec 2012 08:25:16 -0800 (PST)
Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id C8EAC21F8962 for ; Fri, 14 Dec 2012 08:25:15 -0800 (PST)
Received: from [143.225.229.175] ([143.225.229.175]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id qBEGPCtO025647 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 14 Dec 2012 17:25:12 +0100
Message-ID: <50CB52E3.3080604@unina.it>
Date: Fri, 14 Dec 2012 17:25:07 +0100
From: Tobia Castaldi UniNa 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: mediactrl@ietf.org
References:  <50CB15E6.9090609@ns-technologies.com> <20121214131526.6a3ef304@rainpc>
In-Reply-To: <20121214131526.6a3ef304@rainpc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MEDIACTRL]  support
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 16:25:21 -0000

Il 14/12/2012 13.15, Lorenzo Miniero ha scritto:
> On Fri, 14 Dec 2012 12:04:54 +0000
> Chris Boulton  wrote:
>
>> +1 from me.
>>
>
> +1 from me as well,
>
> L.

+1
from me too

T.


>
>> On 13/12/2012 21:55, Eric Burger wrote:
>>> Section 5.1.5.21 of http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ describes an indicator, , as to whether or not a Media Server supports SRTP.
>>>
>>> We were thinking there could be some opaque string that would describe the keying mechanism.  However, as numerous ADs have pointed out, there is no IANA registry for such mechanisms.
>>>
>>> I would offer we be pragmatic, and I would like to hear from manufacturers principally but others with skin in the game. Specifically, what if we said there is one and only one official, supported keying mechanism, namely DTLS-SRTP?  While it is true that today most SIP SRTP implementations are SDES, the user community is demanding a move to DTLS-SRTP and DTLS-SRTP will also be the only keying mechanism for RTCWEB.
>>>
>>> So, the proposed text would be:
>>>
>>> 5.1.5.21.  
>>>
>>>      The  element allows a Media Server to declare support for
>>>      encrypting RTP media streams using RFC 3711 [RFC3711].  The element
>>>      MAY be present.  If the element is present, then the Media Server supports
>>>      DTLS-SRTP [RFC 5763].
>>>
>>>      The  element has no attributes.
>>>
>>>
>>> Anyone want to see something different?
>>>
>>>
>>> _______________________________________________
>>> MEDIACTRL mailing list
>>> MEDIACTRL@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mediactrl
>>> Supplemental Web Site:
>>> http://www.standardstrack.com/ietf/mediactrl
>>
>> -- 
>> Chris Boulton
>> CTO & Co-founder
>> NS-Technologies 
>> m: +44.7876.476681
>


From spromano@unina.it  Fri Dec 14 08:34:09 2012
Return-Path: 
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3033B21F85EF for ; Fri, 14 Dec 2012 08:34:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.718
X-Spam-Level: 
X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4AWUFK4iOxs for ; Fri, 14 Dec 2012 08:34:08 -0800 (PST)
Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id D65D021F85EE for ; Fri, 14 Dec 2012 08:34:07 -0800 (PST)
Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id qBEGY5Jq019544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 17:34:05 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_1B6226AB-013F-4347-B0F8-64A542F3EFCF"
From: Simon Pietro Romano 
In-Reply-To: <20121214131526.6a3ef304@rainpc>
Date: Fri, 14 Dec 2012 17:34:08 +0100
Message-Id: 
References:  <50CB15E6.9090609@ns-technologies.com> <20121214131526.6a3ef304@rainpc>
To: Lorenzo Miniero 
X-Mailer: Apple Mail (2.1283)
Cc: mediactrl@ietf.org
Subject: Re: [MEDIACTRL]  support
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 16:34:09 -0000

--Apple-Mail=_1B6226AB-013F-4347-B0F8-64A542F3EFCF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

One more from my side.

Simon

Il giorno 14/dic/2012, alle ore 13:15, Lorenzo Miniero ha scritto:

> On Fri, 14 Dec 2012 12:04:54 +0000
> Chris Boulton  wrote:
>=20
>> +1 from me.
>>=20
>=20
>=20
> +1 from me as well,
>=20
> L.
>=20
>=20
>> On 13/12/2012 21:55, Eric Burger wrote:
>>> Section 5.1.5.21 of =
http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ describes an =
indicator, , as to whether or not a Media Server supports =
SRTP.
>>>=20
>>> We were thinking there could be some opaque string that would =
describe the keying mechanism.  However, as numerous ADs have pointed =
out, there is no IANA registry for such mechanisms.
>>>=20
>>> I would offer we be pragmatic, and I would like to hear from =
manufacturers principally but others with skin in the game. =
Specifically, what if we said there is one and only one official, =
supported keying mechanism, namely DTLS-SRTP?  While it is true that =
today most SIP SRTP implementations are SDES, the user community is =
demanding a move to DTLS-SRTP and DTLS-SRTP will also be the only keying =
mechanism for RTCWEB.
>>>=20
>>> So, the proposed text would be:
>>>=20
>>> 5.1.5.21.  
>>>=20
>>>    The  element allows a Media Server to declare support =
for
>>>    encrypting RTP media streams using RFC 3711 [RFC3711].  The =
element
>>>    MAY be present.  If the element is present, then the Media Server =
supports
>>>    DTLS-SRTP [RFC 5763].
>>>=20
>>>    The  element has no attributes.
>>>=20
>>>=20
>>> Anyone want to see something different?
>>>=20
>>>=20
>>> _______________________________________________
>>> MEDIACTRL mailing list
>>> MEDIACTRL@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mediactrl
>>> Supplemental Web Site:
>>> http://www.standardstrack.com/ietf/mediactrl
>>=20
>>=20
>> --=20
>> Chris Boulton
>> CTO & Co-founder
>> NS-Technologies 
>> m: +44.7876.476681
>=20
>=20
> --=20
> Lorenzo Miniero, COB
>=20
> Meetecho s.r.l.
> Web Conferencing and Collaboration Tools
> http://www.meetecho.com
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
>=20

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico =
II
                		     Computer Engineering Department=20
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: spromano@unina.it

		    <>. =
Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            =
(   )
			                                  \_)          ) =
/
                                                                       =
(_/






--Apple-Mail=_1B6226AB-013F-4347-B0F8-64A542F3EFCF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

One =
more from my side.

Simon

Il =
giorno 14/dic/2012, alle ore 13:15, Lorenzo Miniero ha scritto:

On =
Fri, 14 Dec 2012 12:04:54 +0000
Chris Boulton <chris-standards@ns-tec=
hnologies.com> wrote:

+1 from =
me.



+1 =
from me as well,

L.


On =
13/12/2012 21:55, Eric Burger wrote:
Section 5.1.5.21 of http://=
datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ describes an =
indicator, <encryption>, as to whether or not a Media Server =
supports SRTP.

We were thinking there could be =
some opaque string that would describe the keying mechanism. =
 However, as numerous ADs have pointed out, there is no IANA =
registry for such mechanisms.

I would offer we be pragmatic, =
and I would like to hear from manufacturers principally but others with =
skin in the game. Specifically, what if we said there is one and only =
one official, supported keying mechanism, namely DTLS-SRTP?  While =
it is true that today most SIP SRTP implementations are SDES, the user =
community is demanding a move to DTLS-SRTP and DTLS-SRTP will also be =
the only keying mechanism for =
RTCWEB.

So, the proposed text would =
be:

5.1.5.21. =
 <encryption>

    The =
<encryption> element allows a Media Server to declare support =
for
    encrypting RTP media streams using RFC =
3711 [RFC3711].  The =
element
    MAY be present.  If the element =
is present, then the Media Server =
supports
    DTLS-SRTP =
[RFC 5763].

    The =
<encryption> element has no =
attributes.


Anyone want to see something =
different?


_______________________________________________
MEDIACTRL mailing =
list
MEDIACTRL@ietf.org
=

https://www.ietf.=
org/mailman/listinfo/mediactrl
Supplemental Web =
Site:
http://www.standards=
track.com/ietf/mediactrl


-- =

Chris =
Boulton
CTO & =
Co-founder
NS-Technologies =
<http://www.ns-technologies.com=
>
m: =
+44.7876.476681


-- 
Lorenzo Miniero, =
COB

Meetecho s.r.l.
Web Conferencing and Collaboration =
Tools
http://www.meetecho.com
__________=
_____________________________________
MEDIACTRL mailing =
list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediac=
trl
Supplemental Web =
Site:
http://www.standardstrack.com/ietf/mediactrl




      =
               				=
	   =
    _\\|//_
          =
                 				=
      ( O-O )
  =
 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =
  				=
Simon Pietro Romano
          =
    Universita' di Napoli =
Federico II
              =
  	=
	     Computer Engineering =
Department 
	         =
    Phone: +39 081 7683823 -- Fax: +39 081 =
7683816
              =
                    =
         e-mail: spromano@unina.it

		=
    <<Molti mi dicono che lo scoraggiamento =CB =
l'alibi degli 
		   =
 idioti. Ci rifletto un istante; e mi scoraggio>>. =
Magritte.
             =
  			=
                  =
   oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   =
)~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
				=
	                =
 \ (            (   =
)
	=
		              =
                    =
\_)          ) /
      =
                    =
                    =
                    =
     (_/








=

--Apple-Mail=_1B6226AB-013F-4347-B0F8-64A542F3EFCF--

From smcg.stds01@mcglashan.org  Tue Dec 18 02:28:03 2012
Return-Path: 
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAB321F8840 for ; Tue, 18 Dec 2012 02:28:03 -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=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x1DxvAMTJiq for ; Tue, 18 Dec 2012 02:28:01 -0800 (PST)
Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by ietfa.amsl.com (Postfix) with ESMTP id 852EF21F855C for ; Tue, 18 Dec 2012 02:28:01 -0800 (PST)
Received: from [192.168.0.8] (host31-51-224-115.range31-51.btcentralplus.com [31.51.224.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by csmtp2.one.com (Postfix) with ESMTPSA id 476AC303CC55; Tue, 18 Dec 2012 10:27:59 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D87BCDD5-D450-437B-B6C4-BC2C89F0A061"
From: Scott McGlashan 
In-Reply-To: <50CB15E6.9090609@ns-technologies.com>
Date: Tue, 18 Dec 2012 10:27:58 +0000
Message-Id: 
References:  <50CB15E6.9090609@ns-technologies.com>
To: Chris Boulton 
X-Mailer: Apple Mail (2.1283)
Cc: mediactrl@ietf.org
Subject: Re: [MEDIACTRL]  support
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Dec 2012 10:28:03 -0000

--Apple-Mail=_D87BCDD5-D450-437B-B6C4-BC2C89F0A061
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

+1 from me too.

Scott

On 14 Dec 2012, at 12:04, Chris Boulton wrote:

> +1 from me.
>=20
> On 13/12/2012 21:55, Eric Burger wrote:
>> Section 5.1.5.21 of =
http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ describes an =
indicator, , as to whether or not a Media Server supports =
SRTP.
>>=20
>> We were thinking there could be some opaque string that would =
describe the keying mechanism.  However, as numerous ADs have pointed =
out, there is no IANA registry for such mechanisms.
>>=20
>> I would offer we be pragmatic, and I would like to hear from =
manufacturers principally but others with skin in the game. =
Specifically, what if we said there is one and only one official, =
supported keying mechanism, namely DTLS-SRTP?  While it is true that =
today most SIP SRTP implementations are SDES, the user community is =
demanding a move to DTLS-SRTP and DTLS-SRTP will also be the only keying =
mechanism for RTCWEB.
>>=20
>> So, the proposed text would be:
>>=20
>> 5.1.5.21.  
>>=20
>>    The  element allows a Media Server to declare support =
for
>>    encrypting RTP media streams using RFC 3711 [RFC3711].  The =
element
>>    MAY be present.  If the element is present, then the Media Server =
supports
>>    DTLS-SRTP [RFC 5763].
>>=20
>>    The  element has no attributes.
>>=20
>>=20
>> Anyone want to see something different?
>>=20
>>=20
>> _______________________________________________
>> MEDIACTRL mailing list
>> MEDIACTRL@ietf.org
>> https://www.ietf.org/mailman/listinfo/mediactrl
>> Supplemental Web Site:
>> http://www.standardstrack.com/ietf/mediactrl
>=20
>=20
> --=20
> Chris Boulton
> CTO & Co-founder
> NS-Technologies
> m: +44.7876.476681
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl


--Apple-Mail=_D87BCDD5-D450-437B-B6C4-BC2C89F0A061
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=iso-8859-1

+1 from me too.

Scott

On 14 Dec 2012, at 12:04, Chris Boulton wrote:


  
    
  
  

    
+1 from me.

      

      On 13/12/2012 21:55, Eric Burger wrote:

    

    

      
Section 5.1.5.21 of http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ describes an indicator, <encryption>, as to whether or not a Media Server supports SRTP.

We were thinking there could be some opaque string that would describe the keying mechanism.  However, as numerous ADs have pointed out, there is no IANA registry for such mechanisms.

I would offer we be pragmatic, and I would like to hear from manufacturers principally but others with skin in the game. Specifically, what if we said there is one and only one official, supported keying mechanism, namely DTLS-SRTP?  While it is true that today most SIP SRTP implementations are SDES, the user community is demanding a move to DTLS-SRTP and DTLS-SRTP will also be the only keying mechanism for RTCWEB.

So, the proposed text would be:

5.1.5.21.  <encryption>

   The <encryption> element allows a Media Server to declare support for
   encrypting RTP media streams using RFC 3711 [RFC3711].  The element
   MAY be present.  If the element is present, then the Media Server supports
   DTLS-SRTP [RFC 5763].

   The <encryption> element has no attributes.


Anyone want to see something different?

      

      

      

      
_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

    

    

    

    
-- 

      Chris Boulton

      CTO & Co-founder

      NS-Technologies

      m: +44.7876.476681

    

  


_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl


--Apple-Mail=_D87BCDD5-D450-437B-B6C4-BC2C89F0A061--

From ron.even.tlv@gmail.com  Wed Dec 19 05:08:31 2012
Return-Path: 
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A5421F86F0 for ; Wed, 19 Dec 2012 05:08:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwWWT5xRtARN for ; Wed, 19 Dec 2012 05:08:30 -0800 (PST)
Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 744F221F8696 for ; Wed, 19 Dec 2012 05:08:30 -0800 (PST)
Received: by mail-ee0-f45.google.com with SMTP id d49so1040294eek.32 for ; Wed, 19 Dec 2012 05:08:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=uv/ecAp3LiTHc2iZBBU7hfVWLWLXiKu0Zoaygln871k=; b=z3ireD4hYlEmQMy8+a6yzChgGpXn72RstI6viEPSCEBzCRYG4kKCjfAPJ7XcgYzfRh ELom+lXKmGr++SJ90zo4hE53Lej1wvaIadEO7AH6cn6teCRLZz8VBgAsQ0V/5YeZgxpU mjfv7ZR8IUw9aR88pISWXXSTAnZKAOD9MVgJTtb8fcx8o3tMnzBQfxBOCPy2qlEJI77Y 1Ip8D5BQBl36S0X+cTAXKbOw11SbTWyiEahpdlo3noZauW350QVm2u8M9hqnbb1Yp/OV M7nhZ7f9llCeggOtNm/pHIHXqhny6cvwz/RUr7vbp9jZ01qnntKtTLCPUpltyUqjMWv0 umuw==
X-Received: by 10.14.1.195 with SMTP id 43mr14194802eed.31.1355922509509; Wed, 19 Dec 2012 05:08:29 -0800 (PST)
Received: from RoniE (bzq-79-176-185-176.red.bezeqint.net. [79.176.185.176]) by mx.google.com with ESMTPS id v46sm9166025eep.1.2012.12.19.05.08.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 05:08:26 -0800 (PST)
From: "Roni Even" 
To: "'Eric Burger'" , 
References: 
In-Reply-To: 
Date: Wed, 19 Dec 2012 15:05:39 +0200
Message-ID: <03ec01cddde9$8ddf6a00$a99e3e00$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLd1kKwiExmI4d6sQqJgvzoitKCu5YAJG8A
Content-Language: en-us
Subject: Re: [MEDIACTRL]  support
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2012 13:08:31 -0000

Hi,
I am not happy and would have liked to see also SDES maybe define two values
for the  element. Note that encryption is specified also in
other sections for the client and mixer so the definition should be
consistent.
The IMTC defined a security profile for video conference end points with
both SDES (used by current systems) and DTLS for new systems.
I will not object  to just having DTLS.
Roni

-----Original Message-----
From: mediactrl-bounces@ietf.org [mailto:mediactrl-bounces@ietf.org] On
Behalf Of Eric Burger
Sent: 13 December, 2012 11:55 PM
To: mediactrl@ietf.org
Subject: [MEDIACTRL]  support

Section 5.1.5.21 of
http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ describes an
indicator, , as to whether or not a Media Server supports SRTP.

We were thinking there could be some opaque string that would describe the
keying mechanism.  However, as numerous ADs have pointed out, there is no
IANA registry for such mechanisms.

I would offer we be pragmatic, and I would like to hear from manufacturers
principally but others with skin in the game. Specifically, what if we said
there is one and only one official, supported keying mechanism, namely
DTLS-SRTP?  While it is true that today most SIP SRTP implementations are
SDES, the user community is demanding a move to DTLS-SRTP and DTLS-SRTP will
also be the only keying mechanism for RTCWEB.

So, the proposed text would be:

5.1.5.21.  

   The  element allows a Media Server to declare support for
   encrypting RTP media streams using RFC 3711 [RFC3711].  The element
   MAY be present.  If the element is present, then the Media Server
supports
   DTLS-SRTP [RFC 5763].

   The  element has no attributes.


Anyone want to see something different?


From worley@shell01.TheWorld.com  Wed Dec 19 11:59:59 2012
Return-Path: 
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F6A21F84D0 for ; Wed, 19 Dec 2012 11:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level: 
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=0.182,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeKQC5duk2rh for ; Wed, 19 Dec 2012 11:59:59 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2688421F84C7 for ; Wed, 19 Dec 2012 11:59:58 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qBJJxrsw001968 for ; Wed, 19 Dec 2012 14:59:55 -0500
Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qBJJxqCd3341472 for ; Wed, 19 Dec 2012 14:59:53 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qBJJxqan3352983; Wed, 19 Dec 2012 14:59:52 -0500 (EST)
Date: Wed, 19 Dec 2012 14:59:52 -0500 (EST)
Message-Id: <201212191959.qBJJxqan3352983@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: mediactrl@ietf.org
Subject: [MEDIACTRL] Review of draft-ietf-mediactrl-call-flows-10: technical question
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2012 19:59:59 -0000

While reviewing draft-ietf-mediactrl-call-flows-10, one of the few
technical issues I found is this item.  I've extracted it from my
review, and I quote it below for your reference.  But it seems to be
an issue that is more general than that particular section of the
draft.

The problem is that if an AS establishes a CFW connection with an MS,
how can it route a call (SIP INVITE for media) to that same MS?  The
problem is that the URI that the AS has to locate the MS may resolve
to multiple MS instances.  So there's no guarantee that the the media
INVITE will be routed to the same MS that the CFW INVITE was routed
to.

What bothers me about this is that this problem is discussed in RFC
6230 section 3, but I can't find the specification of a solution to
this problem.  The text tells only how to ensure that once the CFW
INVITE and its response have been exchanged, the AS can reliably send
a TCP SYN to the MS that generated the CFW 200.  (It does that by
sending the SYN to the c= address in the 200.)  It doesn't tell how a
subsequent media INVITE is sent to that same MS.  But clearly the
authors worried about that problem, and presumably solved it, so I
must be missing something.

On the other hand, in section 7.3.2 of this draft, there is a
discussion of a very similar problem when an MRB is operating in
"inline-unaware" mode:  The AS sends a CFW INVITE to the MRB (thinking
the MRB is an MS), and the MRB forwards the CFW INVITE to a MS.
Apparently, there is no certain way for the MRB to forward a
subsequent media INVITE from the same AS to the chosen MS.  ...  And
yet, a solution to the problem in the paragraph above would seemingly
solve the problem in section 7.3.2.

Can anyone fill me in on what I'm missing?

Dale

    item 53) section 7.3.2

       While apparently not a problem, this raises an issue when the same
       unaware AS has several sessions with different MS: the AS would only
       see one "virtual" MS (the MRB) and so it would relay all calls there,
       making it hard for the MRB to understand where these media dialogs
       should belong: specifically, whether the UAC calling belongs to the
       AS application logic leading to MS1 or MS2, or wherever else.

    This seems to be a deficiency in the CFW protocol:  If the AS
    establishes a CFW channel with the MS (via a SIP URI to an MRB), and
    then later the AS wants to addresses a SIP INVITE to the MS, it has no
    choice but to use the same SIP URI (which routes to the MRB).  This
    makes it impossible for the MRB to associate the SIP INVITE with the
    CFW connection, and thus it is difficult for the MRB to route the
    INVITE to the same MS.

    What seems to be needed is for either the COMEDIA response
    (application/cfw) or CFW connection to provide a SIP URI that is the
    "real" SIP URI of the far-end of the CFW channel.

    Actually, this seems to be a problem even if an AS is addressing an MS
    URI, but the URI resolves to a redundant set of MSs:  There seems to
    be no way to ensure that when a CFW channel is established that a
    subsequent SIP INVITE can be sent to the same MS.  This issue seems to
    be discussed in RFC 6230 section 3, but I can't find any solution
    there.

From worley@shell01.TheWorld.com  Wed Dec 19 12:10:13 2012
Return-Path: 
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B034321F859C for ; Wed, 19 Dec 2012 12:10:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.81
X-Spam-Level: 
X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=0.170,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9rc6zhgJkVS for ; Wed, 19 Dec 2012 12:10:11 -0800 (PST)
Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id B576D21F8530 for ; Wed, 19 Dec 2012 12:10:10 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qBJK9j4E004735 for ; Wed, 19 Dec 2012 15:09:47 -0500
Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qBJK9jur3324527 for ; Wed, 19 Dec 2012 15:09:45 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qBJK9j8a3356324; Wed, 19 Dec 2012 15:09:45 -0500 (EST)
Date: Wed, 19 Dec 2012 15:09:45 -0500 (EST)
Message-Id: <201212192009.qBJK9j8a3356324@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: mediactrl@ietf.org
Subject: [MEDIACTRL] Review of draft-ietf-mediactrl-call-flows-10
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2012 20:10:13 -0000

Review of draft-ietf-mediactrl-call-flows-10

The first thing that comes to mind is that this is a massive body of
work, and tremendously useful for the implementer!

I've listed the items in the order they appear in the draft.  Almost
all of them are editorial rather than technical.  The technical
questions are:

item 15 (is the listing of control packages in the SDP important or not)
item 17 (the negotiation of the timeout value is vague)
item 35 (mixing of playback of two recordings)
item 38 (semantics of setgain)
item 53 (how does AS send media INVITE to the correct MS)
item 55 (how does the MS know which AS sent each request)

item 1) various

The indentation of the header lines identifying various messages is
inconsistent.  I can find the following lines in various places:

1. AS -> MS (SIP INVITE)
 A1. AS -> MS (CFW CONTROL, createconference)
  A1. AS1 -> MS (CFW CONTROL, audit IVR)
   1. AS -> MS (CFW SYNC)

However, it may be easiest to have the RFC Editor fix that by giving
them an appropriate instruction, as they are likely to manually adjust
the indentation of the examples anyway.

item 2) various

There are a lot of places where an arrow seems to go from a network
entity to itself, such as "create conf and its ID" below:

                    AS                                 MS
                    |                                  |
                    | 1. CONTROL (create conference)   |
                    |++++++++++++++++++++++++++++++++>>|
                    |                                  |--+ create
                    |                                  |  | conf and
                    |       2. 200 OK (conferenceid=Y) |<-+ its ID
                    |<<++++++++++++++++++++++++++++++++|

However, the event described on the label, "create conf and its ID",
is not the transmission of a message, and so it doesn't seem like it
should be represented by an arrow.  A more accurate alternative would
be:

                    AS                                 MS
                    |                                  |
                    | 1. CONTROL (create conference)   |
                    |++++++++++++++++++++++++++++++++>>|
                    |                                  | create
                    |                                  | conf and
                    |       2. 200 OK (conferenceid=Y) | its ID
                    |<<++++++++++++++++++++++++++++++++|

item 3) section 1

"self-sustained" should be "self-contained".

item 4) section 2

   Note that due to RFC formatting conventions, this document often
   splits SIP/SDP and CFW across lines whose content would exceed 72
   characters.

"whose content ..." is applied to the wrong referent, a "lines", but
those lines are the post-split lines, not the pre-split lines.
Perhaps:

   Note that due to RFC formatting conventions, SIP/SDP and CFW lines
   whose content exceeds 72 characters are split across lines.  This
   line folding is marked by a backslash at the end of the first line.
   This backslash, the preceding whitespace, the following CRLF, and
   the whitespace beginning the next line would not appear in the
   actual protocol contents.

item 5) section 2

   Due to the same 72 characters limitation, this document also
   sometimes splits the content of XML elements across lines: please
   beware that, when this happens, no whitespace is actually meant to
   be neither at the beginning nor at the end of the element content.

This seems to be incorrect, as in many places, an XML *element*, that
is, everything from the start tag to the end tag (see XML spec, rule
"element"), is quite long and is necessarily split across lines, but
is also valid.  (However, that interpretation depends on entities
respecting the common convention that whitespace character content is
to be ignored if it appears immediately within an element that does
not admit immediate character content.)

I believe you meant "start tag" instead of "element".  But in that
case, line breaks between the attributes of a start tag are valid in
XML (see XML spec, rule "STag").  If this is correct, the above
sentence can be omitted.

However, the message B1 in section 7.1 may be an exception.  See the
appropriate item.

item 6) section 3

   This document makes use of the same terminology as the one that can
   be found in the referenced documents.

This is awkward.  Perhaps:

   This document makes use of the same terminology as the referenced
   documents [RFC6230] [RFC6231] [RFC6505] [I-D.ietf-mediactrl-mrb].

item 7) section 4

This section starts with a paragraph over one page long.  Could it be
broken into multiple paragraphs?

item 8) section 4

It seems overly complicated to explicitly describe "categories" to
contain only four things.  Also, the text needs to mention that Figure
3 contains *two* diagrams, otherwise the accounting seems to be
incorrect.  Perhaps:

   Four diagrams are provided.  Two of them (Figure 1 and Figure 2)
   describe normal operation of the framework.  Figure 3 contains two
   diagrams describing asynchronous event notifications.  Figure 1
   embraces the MS perspective, whereas Figure 2 is on on the AS side.
   The upper part of Figure 3 shows how events are generated, on the
   MS side, by issuing a CONTROL message addressed to the AS; events
   are acknowledged by the AS through standard 200 responses.  Hence,
   the behavior of the AS, which mirrors that of the MS, is depicted
   in the lower part of the figure.

item 9) section 4 figure 1

I think the state machine could be clarified:

- Replace the event "API 200" in "API 200/200" with "API terminate",
  which is how the API termination is described on other arcs.

- Replace the event "API 202" in "API 202/202" with "API update",
  which is how the API non-termination is described on other arcs.

- Further, change "API update" to "timer" or something like that, to
  indicate that the MS CFW state machine must generate a 202 *based on
  the passage of time*, not based on the API providing some sort of
  "update".  If these time intervals are globally fixed for the CFW
  protocol, their fixed values could be written in.

- The states "'202' sent" and "'update' sent" have the same outgoing
  transitions, so they should probably be merged.

- Is there truly an "Error" message that is comparable to the "200"
  and "202" messages?  Or is sending "Error" a shorthand for a cluster
  of numeric response codes?  If the latter, it would help to make
  that clearer here in the introductory material.

- What happens if the API detects an error after 202 has been sent?
  There is no "API Error" arc from "'202' sent"/"'update' confirmed".

item 10) section 4 figure 2

Clarifications of the state machine:

- There is no "Error" arc from the "202 received" and "'update'"
  states.  Are errors impossible here?

- The states "202 received" and "'update'" have the same outward arcs
  and so could be merged.

- The two figures are inconsistent regarding whether response numbers
  (200, 202) are within quotes '...'.

- The two figures are inconsistent regarding whether report categories
  (update, terminate) are within quotes '...'.

- The two figures are inconsistent regarding whether the sending of a
  request or response in an arc's label is indicated using "send" or
  not.

item 11) section 4 figure 3

There are similar inconsistencies between figure 3 and figures 1 and 2.

item 12) section 5

The term "COMEDIA" is used, and a reference is given to RFC 4145.  But
that RFC does not use the term "COMEDIA" at all.  The framework I-D
also uses "COMEDIA" without explicitly defining it.  It would be
helpful to insert here a definition of "COMEDIA", which seems to be
synonymous with "media of type application/cfw".

item 13) section 5.1

   If the request is fine, the MS answers with its own offer,

shouldn't this be:

   If the request is fine, the MS answers with its answer,

item 14) section 5.1

   The MS replies with the list of packages it supports, by
   adding a dummy example package to the list provided by the AS.

The "by" should be removed, as the replying is not done "by adding";
instead, the MS replies and also adds.

item 15) section 5.1

   It is worth noting that this exchange of information is not meant
   as a strict or formal negotiation of packages: in case the AS
   realizes that one or more packages it needs are not supported
   according to the indications sent by the MS, it may, or may not,
   choose not to open a control channel with the MS at all, if its
   application logic leads to such a decision.  The actual negotiation
   of control packages is done subsequently through the use of the
   framework SYNC transaction.

This confuses me:  Either the list of packages in the SDP offer/answer
is significant or it is not.  If it is not, why is it provided?

In particular, if the MS may support packages that it does not admit
to in the answer, then when the AS sees an answer that does not
contain the needed packages, it will have to continue with the control
channel connection in order to determine if the MS *actually* supports
the needed packages or not.  Thus, the MS could omit all ctrl-package
attributes in its answers all the time.

Also, it's not clear whether the AS is required to provide the list of
packages it will need.  If it is required, then the SDP can be used to
choose the correct MS based on MS capabilities.  If it is not
required, a different architectural mechanism is needed.

item 16) section 5.3

Whether "keep alive" is hyphenated is not consistent.

item 17) section 5.3

   In the previous section it has been described how a timeout value for
   the keep alive mechanism is negotiated.  Specifically, in the example
   the AS and the MS agreed on a value of 100 seconds.  

In fact, that section does not describe how the value is negotiated
(since it is not clear what happens if the MS dislikes the value
proposed by the AS).  However, this is correct:

   In example in the previous section, the AS and the MS agreed on a
   value of 100 seconds.


item 18) section 6

   Besides, unless stated otherwise, the same UAC session is referenced
   in all the above mentioned examples.

Is "above mentioned" the correct modifier?  The previous paragraph
refers to "the following scenarios".

item 19) section 6 figure 10

It would be useful at this point to make it clear that the two INVITEs
are different SIP dialogs (as these scenarios are constructed).  (Or,
if the AS may be inline and acting as a proxy, describe that there may
be two dialogs or only one.)  Including, replace the second "INVITE
(X)" with "INVITE (Y)" to show that the URIs need not be the same.

Also, why not include the establishment of the Control Channel in the
figure, as that will not need to be duplicated in any further figure.

item 20) section 6 figure 11

Figure 11 appears to be only a caption.  Or is it the SIP signaling?
Expositions of protocol messages are rarely considered to be figures.

item 21) section 6

The phrase "These three identifiers" is confusing because the text has
just introduced four identifiers.

I assume that if the SDP from AS to MS also contains label attributes,
the Mediactrl framework specifies how they will be used (or ignored),
so that the "addressing" of media streams is not made ambiguous.

item 22) section 6.1.2

   The 202+REPORT(s) mechanism is used whenever the MS wants to tell
   the AS that the requested operation might take some more time than
   expected.

This is probably incorrect.  What you mean is, "the requested
operation might take more than *** seconds".  The fixed or variable
time limit should be specified here.

   In this example, the preparation ends before the
   timeout, and so the transaction is concluded with a 'REPORT
   terminate', which acts as the 200 message in the previous example.

The last clause is rather confusing, as 'REPORT terminate' is a
request, not a response, and thus doesn't "act like" a 200 message.
Perhaps: "which reports the end of the transaction (as did the 200
message in the previous example)".

item 23) section 6.2 figure 18

It might be useful to distinguish the four(?) SIP dialogs involved.

item 24) section 6.2.2

Three hours is 10,800 seconds, not 1,800 seconds.  I think the easiest
fix is to replace "3 hours" with "30 minutes".

RFC 6230 section 6.2

   An entity acting as a Control Server, on receiving a request, MUST
   generate a response [...].  The response MUST conform to the ABNF
   Responses MUST NOT include the 'Status' or 'Timeout' message
   headers, [...]

RFC 6230 section 6.3.2.1

   A Control Server issuing a 202 response MUST ensure the message
   contains a 'Timeout' message header.

item 25) section 6.2.3

This section is rather difficult to follow.  I'm not sure why, but
partly it's because the text doesn't rigorously make clear what events
are "before", that is, when the two audio channels of the original
conference are being recorded, and "after", when the two recordings
are being played back.  For instance, in the second paragraph, the last
sentence is "after", but the first two sentences are "before".
Instead, there should be a paragraph break there, and starting "Later,
when we desire to play the whole conversation to UAC, the AS may
take...".

It would help if the UAC which is listening to the playback was called
"UAC3" or something like that, as "UAC" is also a generic term, and
it's not immediately clear that it is unrelated to UAC1 and UAC2.

It would also help if the two *recordings* had names different from
the UACs during the recording.  In particular "play UAC1 on confY" is
hard for the naive reader to understand until he realizes that "UAC1"
means the recording file of the audio generated by UAC1.

item 26) section 6.3

   o  The AS invokes the creation of a new conference instance by means
      of a CONTROL request (1); this request is addressed to the
      conferencing package (msc-mixer/1.0) and contains in the body the
      directive (createconference) with all the desired settings for it;

The antecedent of "it" is not particularly clear.  The antecedent is
"a new conference", which is the 6th preceding noun phrase, which is
only determined because it is the first preceding noun phrase which
has settings.  Better to say "... the desired settings for the new
conference instance".

item 27) section 6.3.1 figure 30

This figure uses "UAC1" and "UAC2", but the other figures in 6.3 use
"UAC A", "UAC B", and "UAC C".  Ditto for figure 31 and some of the
text.

item 28) section 6.3.4 figure 38

The notation "D+[a+c]" is clever, but "D+(A+C)/2" would be more
accurate.  (And see the following item regarding the volume level.)

item 29) section 6.3.4

The volume level at which the main conference is heard in the sidebar
is not stated consistently:

   the main conference.  The mix of the conference, instead, must be
   attached to the sidebar, but with a lower volume (50%), being just a
   background to the actual conversation.  This would allow both B and D

   2.  then, the main conference mix is attached to it as 'sendonly' and
       with a -5dB gain to limit the volume of its own contribution to
       30% (so that B and D can hear each other louder, while still
       listening to what's happening in the main conference in
       background);

  |         |         | B1. CONTROL (join confX-->confY) |
  |         |         |++++++++++++++++++++++++++++++++>>|
  |         |         |                                  |--+ join confX
  |         |         |                                  |  | & confY
  |         |         |                       B2. 200 OK |<-+ sendonly
  |         |         |<<++++++++++++++++++++++++++++++++|    (50% vol)

      
         
            
               
            
         
      

Of these, two references say 50% (-3dB) and two references say 30% or
-5dB.

item 30) section 6.3.5 figure 43

Is it intended that UAC (FCC) does not have any RTP going to the MS?
(Indeed, is it necessarily a UAC?  But perhaps SIP is needed to set up
BFCP.)

item 31) section 6.3.5

The participant UAC is labeled inconsistently as "UAC", "UAC (FCP)",
and "UAC1".  ("UAC" may be correct, as the context for that term my be
describing a generic or abstract UAC.)  Similarly, "UAC (FCC)" and
"UAC2" are used for the chair UAC.

item 32) section 6.3.5

It might be desirable to mention that the previous speaker should be
muted before UAC1 can be un-muted.  Usually, this muting will happen
between the Accepted and Granted BFCP messages, so it probably should
be illustrated in the sequence of events.

item 33) section 6.4

It might be helpful to expand "VCR" the first time it is used.
(Apparently it does not mean "video cassette recorder", and I see no
suitable meaning on the Wikipedia "disambiguation" page for "VCR".)

item 34) section 6.4.2

   In fact,
   rather than having the AS build different framework messages
   according to the current time to build an announcement, 

This is difficult to read.  Perhaps

   In fact, rather than having the AS build an announcement according
   to the current time using different framework messages,

item 35) section 6.4

The discussion of mixing in the background music should be contrasted
with the mixing of the two recordings during playback in section
6.2.3.  Naively, it would seem that the same mixing techniques could
be used in both cases, but the two sections implement mixing in
entirely different ways.

item 36) section 6.4.3

An example contains XML elements that seem to be unnecessarily
complex:

       
         
           *
           
         
       

As far as I can tell from the SRGS specification,  functions
more-or-less as a type of parenthesis, and is needed only when (1) a
"weight" or "repeat" attribute needs to be applied to the group, (2)
delimiting one alternative of a  element, or (3) constructing
the "null" regular expression (that consumes no input and always
matches).  Thus, these examples can be simplified to:

       
         *
         
       

Then again, if the example is taken from a real interaction, perhaps
it is best to leave it as it really happened.

item 37) section 6.4.3

      to implement is a , and we are only interested in two-
      digits DTMF strings (maxdigits); the AS is not interested in a

"two-digits" should be "two-digit".  (Because this phrase is used as a
modifier of "DTMF strings", the "digit" is not plural.)

      instructs the MS into modifying the volume of the UAC-->conference

"into modifying" would better be "to modify".

      audio flow (setgain=-5dB sendonly); notice how the request also

This is probably intended to be "-3dB", as all other uses of setgain
in this section (including the displayed messages) use a 3 dB
increment.

item 38) section 6.4.3

This section leads to a question about the semantics of the  operation:  Clearly, initially the stream
is output at the same volume as the input media.  But when "" is applied, does that cause the
stream's output volume to be set to +1 dB *relative to the input
media* or to +1 dB *relative to the previous volume setting*?

E.g., if I apply that operation twice, does the second application
leave the amplification at +1 dB or raise it to +2 dB?

The examples in section 6.4.3 suggest the second interpretation.

The text in draft-ietf-mediactrl-mixer-control-package-14 is not clear
on this point: "setgain" is only discussed in section 4.2.2.5.1, and
it says "use the value of the "value" attribute as a specific gain
measured in dB to apply".  That would be most likely to mean "as a
specific gain measured in dB to apply to the input", which suggests
the first interpretation.

In any case, the semantics of this need to be clarified and the
example adjusted accordingly.

item 39) section 7.1

   Each MS makes use of the publishing interface to provide an MRB with
   relevant information.

In the relationship between the MRB and MS, the MRB initiates the
relationship.  Thus, it would be clearer to express this:

   An MRB makes use of the MS's publishing interface to acquire
   relevant information.

   It is
   enough to point out that, in this case, the MRB adds a new voice to
   the 'Packages' it needs support for (mrb-publish/1.0).

"voice" should be "item".

   All
   this messages flow through the control channel as all the messages in
---^^^^
should be "these"
----------------------------------------------------^
insert "do"
   this document.

item 40) section 7.1 message B1

This seems to be the only place in the draft where whitespace has been
introduced where character content is valid, and so there is a
question whether the draft needs to indicate that the whitespace would
not be present on the wire.  The relevant elements are:

        
            
                
                     nbest
                
            
            
                
                     single-view
                
                
                     dual-view
                
                
                     dual-view-crop
                
                
                     dual-view-2x1
                
                
                     dual-view-2x1-crop
                
                
                     quad-view
                
                
                     multiple-5x1
                
                
                     multiple-3x3
                
                
                     multiple-4x4
                
            
        

I'm not sure if the schema defining urn:ietf:params:xml:ns:mrb-publish
indicates that the whitespace before and after the mixing mode names
is to be ignored.  But this might be a place to use the
backslash-line-folding convention specified in section 2:

        
            
                 \
                     nbest \
                
            
            
                 \
                     single-view \
                
                 \
                     dual-view \
                
                 \
                     dual-view-crop \
                
                 \
                     dual-view-2x1 \
                
                 \
                     dual-view-2x1-crop \
                
                 \
                     quad-view \
                
                 \
                     multiple-5x1 \
                
                 \
                     multiple-3x3 \
                
                 \
                     multiple-4x4 \
                
            
        

item 41) section 7.1, section 7.2, section 7.2.1

   In the Inline mode, instead, the MRB is in the
   path between the AS and the pool of MSs it is handling.

   Anyway, the MRB is also
   conceived to work with ASs that are unaware of its functionality,

   and the SIP addresses of the chosen MSs.

Generally, "AS" and "MS" are used as the plurals of "AS" and "MS", but
in these instances, "ASs" and "MSs" are used.

item 42) section 7.1

   request itself and an SDP related to related to either the creation
-----------------------------^^^^^^^^^^^^^^^^^^^^^
"related to" is duplicated.

item 43) section 7.2.1

   MS the MRB has deemed better capable to fulfill the AS requirements),
-------------------------^^^^^^
This should be "best".
-------------------------------------------------------^^
This should be "AS's" or "AS'" (depending on which spelling convention
we are using).

      targeting the request, and as a consequence picks up two MS which
--------------------------------------------------^^^^^^^^
I think you want "picks" here.

   after the Query the AS<->interaction becomes 1:1, UAC media dialogs
----------------------------^
Something appears to be missing here.

item 44) section 7.2.2.1, section 7.2.2.2, section 7.2.3

I think it would make the diagrams a little easier for the naive
reader to follow if the media types specified in the SDP of the
message bodies were given.  E.g., if an INVITE or 200 carries an
application/sdp body for audio media, that is shown on the diagram.
This would be particularly helpful in 7.2.3, where it takes the reader
more consideration to deduce what the media types must be.  Updated in
this way, the diagrams are as follows.  (But this has removed the
comments noting where the SDP has been copied from one message to
another.  That may need to be improved.)

7.2.2.1.  Inline-aware Mode: CFW-based approach

   AS                      MRB                          MS
    |                       |                           |
    | 1. INVITE             |                           |
    | (multipart/mixed:     |                           |
    |  audio,               |                           |
    |  application/mrb-consumer+xml)                    |
    |---------------------->|                           |
    |       2. 100 (Trying) |                           |
    |<----------------------|                           |
    |                       |--+ Extract SDP and        |
    |                       |  | MRB payloads; handle   |
    |                       |<-+ Consumer request to    |
    |                       |    pick MS                |
    |                       |                           |
    |                       | 3. INVITE                 |
    |                       | (audio)                   |
    |                       |-------------------------->|
    |                       |           4. 100 (Trying) |
    |                       |<--------------------------|
    |                       |                           |--+ Negotiate
    |                       |                           |  | CFW Control
    |                       |                           |<-+ Channel
    |                       |                 5. 200 OK |
    |                       |                   (audio) |
    |                       |<--------------------------|
    |                       | 6. ACK                    |
    |                       |-------------------------->|
    |        Prepare new +--|                           |
    |       payload with |  |                           |
    |    SDP from MS and +->|                           |
    |     Consumer reply    |                           |
    |                       |                           |
    |             7. 200 OK |                           |
    |     (multipart/mixed: |                           |
    |      audio,           |                           |
    |      application/mrb-consumer+xml)                |
    |<----------------------|                           |
    | 8. ACK                |                           |
    |---------------------->|                           |
    |                       |                           |
    |--+ Read Cons. reply   |                           |
    |  | and use SDP to     |                           |
    |<-+ create CFW Chn.    |                           |
    |                       |                           |
    |                                                   |
    |<<############## TCP CONNECTION #################>>|
    |                                                   |
    | CFW SYNC                                          |
    |++++++++++++++++++++++++++++++++++++++++++++++++++>|
    |                                                   |

7.2.2.2.  Inline-aware Mode: Media dialog-based approach

   UAC              AS                     MRB                        MS
    |               |                       |                          |
    | 1. INVITE     |                       |                          |
    | (audio)       |                       |                          |
    |-------------->|                       |                          |
    | 2. 100 Trying |                       |                          |
    |<--------------|                       |                          |
    |               | 3. INVITE             |                          |
    |               | (multipart/mixed:     |                          |
    |               |  audio,               |                          |
    |               |  application/mrb-consumer_xml)                   |
    |               |---------------------->|                          |
    |               |       4. 100 (Trying) |                          |
    |               |<----------------------|                          |
    |               |                       |--+ Extract SDP and       |
    |               |                       |  | MRB payloads; handle  |
    |               |                       |<-+ Consumer request to   |
    |               |                       |    pick Media Servers    |
    |               |                       |                          |
    |               |                       | 5. INVITE                |
    |               |                       | (audio)                  |
    |               |                       |------------------------->|
    |               |                       |          6. 100 (Trying) |
    |               |                       |<-------------------------|
    |               |                       |                       +--|
    |               |                       |   Handle media dialog |  |
    |               |                       |       (connection-id) +->|
    |               |                       |                          |
    |               |                       |                7. 200 OK |       
    |               |                       |                  (audio) |
    |               |                       |<-------------------------|
    |               |                       | 8. ACK                   |
    |               |                       |------------------------->|
    |               |        Prepare new +--|                          |
    |               |       payload with |  |                          |
    |               |    SDP from MS and +->|                          |
    |               |     Consumer reply    |                          |
    |               |                       |                          |
    |               |             9. 200 OK |                          |
    |               |     (multipart/mixed: |                          |
    |               |      audio,           |                          |
    |               |      application/mrb-consumer+xml)               |
    |               |<----------------------|                          |
    |               | 10. ACK               |                          |
    |               |---------------------->|                          |
    |               |                       |                          |
    |               |--+ Read Cons. reply   |                          |
    |               |  | and send SDP       |                          |
    |               |<-+ back to UAC        |                          |
    |    11. 200 OK |                       |                          |
    |       (audio) |                       |                          |
    |<--------------|                       |                          |
    | 12. ACK       |                       |                          |
    |-------------->|                       |                          |
    |               |                       |                          |
    |<<*************************** RTP ******************************>>|
    |               |                       |                          |
    |               |--+ Negotiate          |                          |
    |               |  | CFW channel        |                          |
    |               |<-+ towards MS         |                          |
    |               |    (if needed)        |                          |
    |               |                       |                          |
    |               |<<############## TCP CONNECTION ################>>|
    |               |                                                  |
    |               | CFW SYNC                                         |
    |               |+++++++++++++++++++++++++++++++++++++++++++++++++>|
    |               |                                                  |

7.2.3.  Inline-unaware Mode

   AS                      MRB                          MS
    |                       |                           |
    | 1. INVITE             |                           |
    | (application/cfw)     |                           |
    |---------------------->|                           |
    |       2. 100 (Trying) |                           |
    |<----------------------|                           |
    |                       |--+ Pick a MS              |
    |                       |  | and redirect           |
    |                       |<-+ INVITE there           |
    |                       |                           |
    |                       | 3. INVITE                 |
    |                       | (application/cfw)         |
    |                       |-------------------------->|
    |                       |           4. 100 (Trying) |
    |                       |<--------------------------|
    |                       |                           |--+ Negotiate
    |                       |                           |  | CFW Control
    |                       |                           |<-+ Channel
    |                       |                 5. 200 OK |
    |                       |         (application/cfw) |
    |                       |<--------------------------|
    |                       | 6. ACK                    |
    |                       |-------------------------->|
    |                       |                           |
    |             7. 200 OK |                           |
    |     (application/cfw) |                           |
    |<----------------------|                           |
    | 8. ACK                |                           |
    |---------------------->|                           |
    |                       |                           |
    |                                                   |
    |<<############## TCP CONNECTION #################>>|
    |                                                   |
    | CFW SYNC                                          |
    |++++++++++++++++++++++++++++++++++++++++++++++++++>|
    |                                                   |

item 45) section 7.2.2

   An AS willing to issue a Concumer request by means of SIP, has to do
----------------------------^
This should be "Consumer".

   envisages two kind of SIP dialogs a Consumer request may be sent
-----------------^
This should be "kinds".

   setup a control channel) or a UAC media dialog (a SIP dialog the AS
---^
This should be "set up".  ("set up" functions like a verb; "setup"
functions like a noun.)

   The behaviour in the two cases, which are called respectively CFW-
-------^
Probably better to say "behaviours" here.
   based and Media dialog-based approach, is only slightly different,
------------------------------------------^
Use "are", to go with "behaviors".

item 46) section 7.2.2.1, section 7.2.2.2

   Please note that, to ease the reading of the protocol contents, a
   simple '=_Part' is used whenever a boundary for a 'multipart/mixed'
   payload is provided, instead of the actual boundary that would be
   inserted in the SIP messages.

This seems like a poor strategy, as the resulting figures are not
strictly correct.  Perhaps use "Part" as the boundary value, which
would result in figures that look like the following, which strictly
correct and are just as easy to read:

   [..]
   Content-Type: multipart/mixed;boundary="Part"

   --Part
   Content-Type: application/sdp

   v=0
   o=- 2890844526 2890842807 IN IP4 as.example.com
   [...]

   --Part
   Content-Type: application/mrb-consumer+xml

   
   
      [...]
   

   --Part--

In both of these sections, just before the message listings, there is
a line containing only:

   o

In the following message titles, "SDP" appears in lower case:

section 7.2.2.1:
    3. MRB -> MS (INVITE sdp only)
    5. MRB <- MS (200 OK sdp)
section 7.2.2.2:
    5. MRB -> MS (INVITE sdp only)
    7. MRB <- MS (200 OK sdp)
    11. UAC <- AS (200 OK sdp)

item 47) section 7.2.3

   pick a MS rather than another.
--------^
Probably should be "one", to contrast with "another".

item 48) section 7.2.3

This example does not give the content of the messages, unlike the
previous two examples.

item 49) section 7.3.1

This section is titled "Query/IAMM".  The call flow does mesh with the
call flow in section 7.2.1, "Query Mode", but it does not mesh with
the call flow in section 7.2.2.1, "Inline-aware Mode: CFW-based
approach" nor with the call flow in section 7.2.2.2, "Inline-aware
Mode: Media dialog-based approach".

It would probably be best to change the title of the section to
"Query".  If necessary, an additional section should be added giving
examples relevant to inline-aware mode.

item 50) section 7.3.1, section 7.3.2

The use of "IAMM" and "IUMM" is a bit opaque here, as those acronyms
are not explicitly expanded anywhere in this document.  They seem to
mean what is called "inline-aware mode" and "inline-unaware mode", but
the acronyms of those phrases aren't the same as the acronyms used.

Perhaps these section titles could be changed to resemble those of
7.2.*, "7.3.1. Query and Inline-aware Mode" and "7.3.2. Inline-unaware
Mode".  That doesn't fix the problem with the acronyms per se but does
make the titles clearer.

item 51) section 7.3.1

We might want to mention that in this scenario, the AS obtains
assignment of an MS *before* any UAC makes a request, in order to have
facilities to satisfy future SIP requests.  That is probably how AS's
operate in practice, but a naive reader might expect that the AS will
make the consumer request only after the AS receives a demand for its
services.

   Nevertheless, there are cases when having an MRB in the signalling
   path ...

You might want to say "the SIP signalling path" here.  By my count,
there are *three* different signalling paths:  the COMEDIA negotiation
(INVITE with application/cfw SDP), the CFW connection, and the SIP
signalling (INVITE with audio/etc. SDP).

item 52) section 7.3.2

   As mentioned previously, in such a case the AS would interact with
What case is "in such a case"?  (This is the first sentence of a
section.)  It seems that this paragraph is trying to contrast "such a
case" with "IUMM", but it's not clear what is going on.

   That said, the IUMM case is also very interesting with respect to the
   media dialogs management.  In fact, in the MRB-unaware mode there
---------^
This should be "dialog".
   would be no Consumer request and an AS would actually see the MRB as
   an MS.  This means that, unlike the previous scenarios, there is
   actually no choice, meaning the MRB would likely be in the signaling
------------^
What is there "no choice" of?  The obvious choice is that of a MS, but
the MRB clearly can choose which MS to sent the request to.
   path anyway.  The MRB could either redirect the AS to a MS directly
   or transparently act a proxy/B2BUA and contact a MS (according to
   implementation-specific policies) on behalf of the unaware AS.

   To overcome the scalability limitations of such an approach, the MR
--------------------------------------------------------------^
You should add here "at least in regard to the MRB being in the SIP
signalling path for all calls" -- as far as I can tell, this is the
only scaling problem this approach removes.  (The major one is that
all calls handled by the AS have to be handled by only one MS.)

   Rather than recurring to explicit redirection, or always
---------------^
This isn't the right word.  Perhaps "resorting" was intended?

item 53) section 7.3.2

   While apparently not a problem, this raises an issue when the same
   unaware AS has several sessions with different MS: the AS would only
   see one "virtual" MS (the MRB) and so it would relay all calls there,
   making it hard for the MRB to understand where these media dialogs
   should belong: specifically, whether the UAC calling belongs to the
   AS application logic leading to MS1 or MS2, or wherever else.

This seems to be a deficiency in the CFW protocol:  If the AS
establishes a CFW channel with the MS (via a SIP URI to an MRB), and
then later the AS wants to addresses a SIP INVITE to the MS, it has no
choice but to use the same SIP URI (which routes to the MRB).  This
makes it impossible for the MRB to associate the SIP INVITE with the
CFW connection, and thus it is difficult for the MRB to route the
INVITE to the same MS.

What seems to be needed is for either the COMEDIA response
(application/cfw) or CFW connection to provide a SIP URI that is the
"real" SIP URI of the far-end of the CFW channel.

Actually, this seems to be a problem even if an AS is addressing an MS
URI, but the URI resolves to a redundant set of MSs:  There seems to
be no way to ensure that when a CFW channel is established that a
subsequent SIP INVITE can be sent to the same MS.  This issue seems to
be discussed in RFC 6230 section 3, but I can't find any solution
there.

item 54) section 8

   receiving requests that may cross the bounds each AS is constrained
   into.
---^
Probably better as "within".

item 55) section 8

The detailed discussion of how the MS enforces security against the
ASs is helpful, but it does not mention how the MS discerns which
requests come from AS1 and which come from AS2.

Dale

From lorenzo@meetecho.com  Wed Dec 26 04:12:06 2012
Return-Path: 
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C176721F8CA6 for ; Wed, 26 Dec 2012 04:12:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.481
X-Spam-Level: ***
X-Spam-Status: No, score=3.481 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_BACKHAIR_23=1, J_CHICKENPOX_22=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vq0KGmNDYCE6 for ; Wed, 26 Dec 2012 04:12:03 -0800 (PST)
Received: from smtpdg12.aruba.it (smtpdg230.aruba.it [62.149.158.230]) by ietfa.amsl.com (Postfix) with ESMTP id 669CD21F8CA5 for ; Wed, 26 Dec 2012 04:12:01 -0800 (PST)
Received: from rainpc ([87.10.35.74]) by smtpcmd04.ad.aruba.it with bizsmtp id gCBt1k00Q1byNtB01CBuHh; Wed, 26 Dec 2012 13:11:58 +0100
Date: Wed, 26 Dec 2012 13:11:52 +0100
From: Lorenzo Miniero 
To: worley@ariadne.com (Dale R. Worley)
Message-ID: <20121226131152.4660538e@rainpc>
In-Reply-To: <201212192009.qBJK9j8a3356324@shell01.TheWorld.com>
References: <201212192009.qBJK9j8a3356324@shell01.TheWorld.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: mediactrl@ietf.org
Subject: Re: [MEDIACTRL] Review of draft-ietf-mediactrl-call-flows-10
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Dec 2012 12:12:06 -0000

Hello Dale,

first of all, thanks for your detailed review! I'm answering to this
mail first, leaving the extracted issue of the previous issue to later,
since, as you pointed out, that's a more general issue.

I've added my replies inline prefixed by a [LM].


On Wed, 19 Dec 2012 15:09:45 -0500 (EST)
worley@ariadne.com (Dale R. Worley) wrote:

> Review of draft-ietf-mediactrl-call-flows-10
> 
> The first thing that comes to mind is that this is a massive body of
> work, and tremendously useful for the implementer!
> 


[LM] Thanks! That's exactly what we wanted to achieve.


> I've listed the items in the order they appear in the draft.  Almost
> all of them are editorial rather than technical.  The technical
> questions are:
> 
> item 15 (is the listing of control packages in the SDP important or not)
> item 17 (the negotiation of the timeout value is vague)
> item 35 (mixing of playback of two recordings)
> item 38 (semantics of setgain)
> item 53 (how does AS send media INVITE to the correct MS)
> item 55 (how does the MS know which AS sent each request)
> 
> item 1) various
> 
> The indentation of the header lines identifying various messages is
> inconsistent.  I can find the following lines in various places:
> 
> 1. AS -> MS (SIP INVITE)
>  A1. AS -> MS (CFW CONTROL, createconference)
>   A1. AS1 -> MS (CFW CONTROL, audit IVR)
>    1. AS -> MS (CFW SYNC)
> 
> However, it may be easiest to have the RFC Editor fix that by giving
> them an appropriate instruction, as they are likely to manually adjust
> the indentation of the examples anyway.
> 


[LM] You're right, the indentation often varies, and the logic behind
this currently is according to whether or not the example fits the page.
Instructions about this would be welcome!


> item 2) various
> 
> There are a lot of places where an arrow seems to go from a network
> entity to itself, such as "create conf and its ID" below:
> 
>                     AS                                 MS
>                     |                                  |
>                     | 1. CONTROL (create conference)   |
>                     |++++++++++++++++++++++++++++++++>>|
>                     |                                  |--+ create
>                     |                                  |  | conf and
>                     |       2. 200 OK (conferenceid=Y) |<-+ its ID
>                     |<<++++++++++++++++++++++++++++++++|
> 
> However, the event described on the label, "create conf and its ID",
> is not the transmission of a message, and so it doesn't seem like it
> should be represented by an arrow.  A more accurate alternative would
> be:
> 
>                     AS                                 MS
>                     |                                  |
>                     | 1. CONTROL (create conference)   |
>                     |++++++++++++++++++++++++++++++++>>|
>                     |                                  | create
>                     |                                  | conf and
>                     |       2. 200 OK (conferenceid=Y) | its ID
>                     |<<++++++++++++++++++++++++++++++++|
> 


[LM] Yes, in that case the arrow was not meant as a network connection,
but as a further step in the sequence diagram, that is what that
CONTROL message triggers in the MS application logic. The same applies
to all the examples where this happens. If you think the arrowless
diagram is clearer to the reader we might remove them: the problem with
this is that, without arrows, some diagrams might be harder to read,
i.e., in terms of who does what in diagrams with several components
interacting with each other. As an alternative, we might clarify what
those arrows are and what they are not. What do you think about this?



> item 3) section 1
> 
> "self-sustained" should be "self-contained".
> 


[LM] Ok.


> item 4) section 2
> 
>    Note that due to RFC formatting conventions, this document often
>    splits SIP/SDP and CFW across lines whose content would exceed 72
>    characters.
> 
> "whose content ..." is applied to the wrong referent, a "lines", but
> those lines are the post-split lines, not the pre-split lines.
> Perhaps:
> 
>    Note that due to RFC formatting conventions, SIP/SDP and CFW lines
>    whose content exceeds 72 characters are split across lines.  This
>    line folding is marked by a backslash at the end of the first line.
>    This backslash, the preceding whitespace, the following CRLF, and
>    the whitespace beginning the next line would not appear in the
>    actual protocol contents.
> 


[LM] Thanks, we'll change the sentence.


> item 5) section 2
> 
>    Due to the same 72 characters limitation, this document also
>    sometimes splits the content of XML elements across lines: please
>    beware that, when this happens, no whitespace is actually meant to
>    be neither at the beginning nor at the end of the element content.
> 
> This seems to be incorrect, as in many places, an XML *element*, that
> is, everything from the start tag to the end tag (see XML spec, rule
> "element"), is quite long and is necessarily split across lines, but
> is also valid.  (However, that interpretation depends on entities
> respecting the common convention that whitespace character content is
> to be ignored if it appears immediately within an element that does
> not admit immediate character content.)
> 
> I believe you meant "start tag" instead of "element".  But in that
> case, line breaks between the attributes of a start tag are valid in
> XML (see XML spec, rule "STag").  If this is correct, the above
> sentence can be omitted.
> 
> However, the message B1 in section 7.1 may be an exception.  See the
> appropriate item.
> 


[LM] We actually added this line after a comment of yours on the MRB
document examples, which exhibited a similar behaviour. Since we wanted
to clarify that the examples didn't include pre and post whitespaces,
we added the text to make this clearer. If that's unneeded we can
remove the sentence again.


> item 6) section 3
> 
>    This document makes use of the same terminology as the one that can
>    be found in the referenced documents.
> 
> This is awkward.  Perhaps:
> 
>    This document makes use of the same terminology as the referenced
>    documents [RFC6230] [RFC6231] [RFC6505] [I-D.ietf-mediactrl-mrb].
> 


[LM] Ok.


> item 7) section 4
> 
> This section starts with a paragraph over one page long.  Could it be
> broken into multiple paragraphs?
> 


[LM] Did you mean section 4.1? Section 4 starts with just a few lines.


> item 8) section 4
> 
> It seems overly complicated to explicitly describe "categories" to
> contain only four things.  Also, the text needs to mention that Figure
> 3 contains *two* diagrams, otherwise the accounting seems to be
> incorrect.  Perhaps:
> 
>    Four diagrams are provided.  Two of them (Figure 1 and Figure 2)
>    describe normal operation of the framework.  Figure 3 contains two
>    diagrams describing asynchronous event notifications.  Figure 1
>    embraces the MS perspective, whereas Figure 2 is on on the AS side.
>    The upper part of Figure 3 shows how events are generated, on the
>    MS side, by issuing a CONTROL message addressed to the AS; events
>    are acknowledged by the AS through standard 200 responses.  Hence,
>    the behavior of the AS, which mirrors that of the MS, is depicted
>    in the lower part of the figure.
> 


[LM] Good point, we'll fix this.


> item 9) section 4 figure 1
> 
> I think the state machine could be clarified:
> 
> - Replace the event "API 200" in "API 200/200" with "API terminate",
>   which is how the API termination is described on other arcs.
> 
> - Replace the event "API 202" in "API 202/202" with "API update",
>   which is how the API non-termination is described on other arcs.
> 
> - Further, change "API update" to "timer" or something like that, to
>   indicate that the MS CFW state machine must generate a 202 *based on
>   the passage of time*, not based on the API providing some sort of
>   "update".  If these time intervals are globally fixed for the CFW
>   protocol, their fixed values could be written in.
> 


[LM] Ok, we'll make this clearer.


> - The states "'202' sent" and "'update' sent" have the same outgoing
>   transitions, so they should probably be merged.
> 


[LM] I'm not sure about this: 202 is only sent after the first CONTROL
message to tell the AS it may take a while to process the request, after
which you can either have further 202 messages should the processing
take even more time, or one or more UPDATE messages related to that
CONTROL request after that. They're two different messages in the
protocol semantics. Nevertheless, it's also true that, according to
RFC6230, a 202 is basically a pre-REPORT message... any feedback on
this?


> - Is there truly an "Error" message that is comparable to the "200"
>   and "202" messages?  Or is sending "Error" a shorthand for a cluster
>   of numeric response codes?  If the latter, it would help to make
>   that clearer here in the introductory material.
> 


[LM] Yes, errors are numeric codes (Section 7. in RFC6230). We'll fix
the text.


> - What happens if the API detects an error after 202 has been sent?
>   There is no "API Error" arc from "'202' sent"/"'update' confirmed".
> 


[LM] Good point. The idea is that, once the MS sends a 202, the request
has been correctly processed, and so is supposed to be fine as far as
the protocol is concerned. I guess there could be circumstances when an
errors occurs after that, e.g., in retrieving an audio file to be played
to a UAC: in that case, the AS would be informed of the termination of
the dialog/request in a REPORT terminate, including details on the issue
which are Control Package specific. Do you think explaining this in the
text may help readers?


> item 10) section 4 figure 2
> 
> Clarifications of the state machine:
> 
> - There is no "Error" arc from the "202 received" and "'update'"
>   states.  Are errors impossible here?
> 
> - The states "202 received" and "'update'" have the same outward arcs
>   and so could be merged.
> 
> - The two figures are inconsistent regarding whether response numbers
>   (200, 202) are within quotes '...'.
> 
> - The two figures are inconsistent regarding whether report categories
>   (update, terminate) are within quotes '...'.
> 
> - The two figures are inconsistent regarding whether the sending of a
>   request or response in an arc's label is indicated using "send" or
>   not.
> 
> item 11) section 4 figure 3
> 
> There are similar inconsistencies between figure 3 and figures 1 and 2.
> 
> item 12) section 5
> 
> The term "COMEDIA" is used, and a reference is given to RFC 4145.  But
> that RFC does not use the term "COMEDIA" at all.  The framework I-D
> also uses "COMEDIA" without explicitly defining it.  It would be
> helpful to insert here a definition of "COMEDIA", which seems to be
> synonymous with "media of type application/cfw".
> 


[LM] I thought COMEDIA actually came from RFC4145, standing for
"connection-oriented media". Even the MSRP RFC refers to it that way. If
that's incorrect or incomplete we'll fix this in the next version.


> item 13) section 5.1
> 
>    If the request is fine, the MS answers with its own offer,
> 
> shouldn't this be:
> 
>    If the request is fine, the MS answers with its answer,
> 


[LM] Ok.


> item 14) section 5.1
> 
>    The MS replies with the list of packages it supports, by
>    adding a dummy example package to the list provided by the AS.
> 
> The "by" should be removed, as the replying is not done "by adding";
> instead, the MS replies and also adds.
> 


[LM] OK.


> item 15) section 5.1
> 
>    It is worth noting that this exchange of information is not meant
>    as a strict or formal negotiation of packages: in case the AS
>    realizes that one or more packages it needs are not supported
>    according to the indications sent by the MS, it may, or may not,
>    choose not to open a control channel with the MS at all, if its
>    application logic leads to such a decision.  The actual negotiation
>    of control packages is done subsequently through the use of the
>    framework SYNC transaction.
> 
> This confuses me:  Either the list of packages in the SDP offer/answer
> is significant or it is not.  If it is not, why is it provided?
> 
> In particular, if the MS may support packages that it does not admit
> to in the answer, then when the AS sees an answer that does not
> contain the needed packages, it will have to continue with the control
> channel connection in order to determine if the MS *actually* supports
> the needed packages or not.  Thus, the MS could omit all ctrl-package
> attributes in its answers all the time.
> 
> Also, it's not clear whether the AS is required to provide the list of
> packages it will need.  If it is required, then the SDP can be used to
> choose the correct MS based on MS capabilities.  If it is not
> required, a different architectural mechanism is needed.
> 


[LM] That section refers to a draft Chris submitted to the MMUSIC WG
some time ago:

http://tools.ietf.org/html/draft-boulton-mmusic-sdp-control-package-attribute-07

so any clarification about the purpose and constraints of such a
mechanism should be addressed in the specification. Chris, do you think
this behaviour could be clarified in the draft, in order to have it
reflected in the Call Flows as a consequence?


> item 16) section 5.3
> 
> Whether "keep alive" is hyphenated is not consistent.
> 


[LM] The right word is "keep-alive", we'll make this consistent.


> item 17) section 5.3
> 
>    In the previous section it has been described how a timeout value for
>    the keep alive mechanism is negotiated.  Specifically, in the example
>    the AS and the MS agreed on a value of 100 seconds.  
> 
> In fact, that section does not describe how the value is negotiated
> (since it is not clear what happens if the MS dislikes the value
> proposed by the AS).  However, this is correct:
> 
>    In example in the previous section, the AS and the MS agreed on a
>    value of 100 seconds.
> 


[LM] According to RFC6230, the 200 to the SYNC MUST have the same
keep-alive value proposed in the original SYNC. Who sends the SYNC can
change according to the COMEDIA negotiation. Specifically, "The previous
steps ensure that the entity initiating the Control Channel connection
is always the one specifying the keep-alive timeout period.". So, to
answer your question, I guess that if a MS dislikes the value, it can
just pick the active role and send a new SYNC with a new keep-alive
value.


> 
> item 18) section 6
> 
>    Besides, unless stated otherwise, the same UAC session is referenced
>    in all the above mentioned examples.
> 
> Is "above mentioned" the correct modifier?  The previous paragraph
> refers to "the following scenarios".
> 


[LM] You're right, it's a bit unclear, we'll fix this.


> item 19) section 6 figure 10
> 
> It would be useful at this point to make it clear that the two INVITEs
> are different SIP dialogs (as these scenarios are constructed).  (Or,
> if the AS may be inline and acting as a proxy, describe that there may
> be two dialogs or only one.)  Including, replace the second "INVITE
> (X)" with "INVITE (Y)" to show that the URIs need not be the same.
> 


[LM] OK.


> Also, why not include the establishment of the Control Channel in the
> figure, as that will not need to be duplicated in any further figure.
> 


[LM] It's not there as the Control Channel may already have been
negotiated and synced in advance. That is, the AS may be redirecting
calls to a MS it has already been already "talking with" for a while.
We explained this at the beginning of the section, "All the examples
assume that a Control Channel has already been correctly established
and SYNCed between the reference AS and MS", as that was already
addressed in the previous section.


> item 20) section 6 figure 11
> 
> Figure 11 appears to be only a caption.  Or is it the SIP signaling?
> Expositions of protocol messages are rarely considered to be figures.
> 


[LM] You're right, we made use of figures to simplify the formatting
of the messages, we'll remove te caption.


> item 21) section 6
> 
> The phrase "These three identifiers" is confusing because the text has
> just introduced four identifiers.
> 


[LM] Oops, right.


> I assume that if the SDP from AS to MS also contains label attributes,
> the Mediactrl framework specifies how they will be used (or ignored),
> so that the "addressing" of media streams is not made ambiguous.
> 
> item 22) section 6.1.2
> 
>    The 202+REPORT(s) mechanism is used whenever the MS wants to tell
>    the AS that the requested operation might take some more time than
>    expected.
> 
> This is probably incorrect.  What you mean is, "the requested
> operation might take more than *** seconds".  The fixed or variable
> time limit should be specified here.
> 


[LM] Actually, the time is Control Package dependent. Different packages
may have different timeouts. Quoting the framework, "A Control Package
MUST explicitly define the circumstances under which the server sends
200 and 202 messages."


>    In this example, the preparation ends before the
>    timeout, and so the transaction is concluded with a 'REPORT
>    terminate', which acts as the 200 message in the previous example.
> 
> The last clause is rather confusing, as 'REPORT terminate' is a
> request, not a response, and thus doesn't "act like" a 200 message.
> Perhaps: "which reports the end of the transaction (as did the 200
> message in the previous example)".
> 


[LM] OK.


> item 23) section 6.2 figure 18
> 
> It might be useful to distinguish the four(?) SIP dialogs involved.
> 


[LM] Do you mean as in different figures? or clearer text?


> item 24) section 6.2.2
> 
> Three hours is 10,800 seconds, not 1,800 seconds.  I think the easiest
> fix is to replace "3 hours" with "30 minutes".
> 


[LM] Oops, ugly typo, will fix this (and good thing my math teacher is
not reading this :-) )


> RFC 6230 section 6.2
> 
>    An entity acting as a Control Server, on receiving a request, MUST
>    generate a response [...].  The response MUST conform to the ABNF
>    Responses MUST NOT include the 'Status' or 'Timeout' message
>    headers, [...]
> 
> RFC 6230 section 6.3.2.1
> 
>    A Control Server issuing a 202 response MUST ensure the message
>    contains a 'Timeout' message header.
> 
> item 25) section 6.2.3
> 
> This section is rather difficult to follow.  I'm not sure why, but
> partly it's because the text doesn't rigorously make clear what events
> are "before", that is, when the two audio channels of the original
> conference are being recorded, and "after", when the two recordings
> are being played back.  For instance, in the second paragraph, the last
> sentence is "after", but the first two sentences are "before".
> Instead, there should be a paragraph break there, and starting "Later,
> when we desire to play the whole conversation to UAC, the AS may
> take...".
> 


[LM] You're right, we'll try to make this clearer.


> It would help if the UAC which is listening to the playback was called
> "UAC3" or something like that, as "UAC" is also a generic term, and
> it's not immediately clear that it is unrelated to UAC1 and UAC2.
> 
> It would also help if the two *recordings* had names different from
> the UACs during the recording.  In particular "play UAC1 on confY" is
> hard for the naive reader to understand until he realizes that "UAC1"
> means the recording file of the audio generated by UAC1.
> 


[LM] Good points.


> item 26) section 6.3
> 
>    o  The AS invokes the creation of a new conference instance by means
>       of a CONTROL request (1); this request is addressed to the
>       conferencing package (msc-mixer/1.0) and contains in the body the
>       directive (createconference) with all the desired settings for it;
> 
> The antecedent of "it" is not particularly clear.  The antecedent is
> "a new conference", which is the 6th preceding noun phrase, which is
> only determined because it is the first preceding noun phrase which
> has settings.  Better to say "... the desired settings for the new
> conference instance".
> 


[LM] Ok.


> item 27) section 6.3.1 figure 30
> 
> This figure uses "UAC1" and "UAC2", but the other figures in 6.3 use
> "UAC A", "UAC B", and "UAC C".  Ditto for figure 31 and some of the
> text.
> 


[LM] Nice catch, we'll fix this.


> item 28) section 6.3.4 figure 38
> 
> The notation "D+[a+c]" is clever, but "D+(A+C)/2" would be more
> accurate.  (And see the following item regarding the volume level.)
> 


[LM] Ok.


> item 29) section 6.3.4
> 
> The volume level at which the main conference is heard in the sidebar
> is not stated consistently:
> 
>    the main conference.  The mix of the conference, instead, must be
>    attached to the sidebar, but with a lower volume (50%), being just a
>    background to the actual conversation.  This would allow both B and D
> 
>    2.  then, the main conference mix is attached to it as 'sendonly' and
>        with a -5dB gain to limit the volume of its own contribution to
>        30% (so that B and D can hear each other louder, while still
>        listening to what's happening in the main conference in
>        background);
> 
>   |         |         | B1. CONTROL (join confX-->confY) |
>   |         |         |++++++++++++++++++++++++++++++++>>|
>   |         |         |                                  |--+ join confX
>   |         |         |                                  |  | & confY
>   |         |         |                       B2. 200 OK |<-+ sendonly
>   |         |         |<<++++++++++++++++++++++++++++++++|    (50% vol)
> 
>       
>          
>             
>                
>             
>          
>       
> 
> Of these, two references say 50% (-3dB) and two references say 30% or
> -5dB.
> 


[LM] You're right, we'll make this consistent.


> item 30) section 6.3.5 figure 43
> 
> Is it intended that UAC (FCC) does not have any RTP going to the MS?
> (Indeed, is it necessarily a UAC?  But perhaps SIP is needed to set up
> BFCP.)
> 


[LM] Yes, to clarify the distinction between a simple participant and a
chair we chose to only display RTP for the participant, with the chair
moderating what happens on it. Whether or not the FCC has any RTP
flowing is not relevant to the example and that's why we omitted it.
That said, the chair does not need to be a UAC, you're right, and SIP is
not mandated to set up BFCP (RFC4583 is only a way to do so, BFCP just
talks of out of band mechanisms generally). We will remove the UAC for
the FCC in the figure to make this clearer.


> item 31) section 6.3.5
> 
> The participant UAC is labeled inconsistently as "UAC", "UAC (FCP)",
> and "UAC1".  ("UAC" may be correct, as the context for that term my be
> describing a generic or abstract UAC.)  Similarly, "UAC (FCC)" and
> "UAC2" are used for the chair UAC.
> 


[LM] We'll fix the diagrams accordingly.


> item 32) section 6.3.5
> 
> It might be desirable to mention that the previous speaker should be
> muted before UAC1 can be un-muted.  Usually, this muting will happen
> between the Accepted and Granted BFCP messages, so it probably should
> be illustrated in the sequence of events.
> 


[LM] That's actually not needed, as BFCP does not force an exclusive
access to the resources it moderates. According to the policy in use,
several participants may be granted the same resource (e.g., ability to
talk) at the same time (e.g., in a conference bridge).


> item 33) section 6.4
> 
> It might be helpful to expand "VCR" the first time it is used.
> (Apparently it does not mean "video cassette recorder", and I see no
> suitable meaning on the Wikipedia "disambiguation" page for "VCR".)
> 


[LM] We borrowed this terminology from RFC6231, the IVR Control Package.
The idea is to have "video cassette recorder"-lie controls, right, like
the ability to play, pause, stop, rewind, etc. We'll expand this.


> item 34) section 6.4.2
> 
>    In fact,
>    rather than having the AS build different framework messages
>    according to the current time to build an announcement, 
> 
> This is difficult to read.  Perhaps
> 
>    In fact, rather than having the AS build an announcement according
>    to the current time using different framework messages,
> 


[LM] Ok.


> item 35) section 6.4
> 
> The discussion of mixing in the background music should be contrasted
> with the mixing of the two recordings during playback in section
> 6.2.3.  Naively, it would seem that the same mixing techniques could
> be used in both cases, but the two sections implement mixing in
> entirely different ways.
> 


[LM] Are you talking of 6.4.2 (current time example)? If so, this was
done on purpose, to exploit two different scenarios to showcase the use
of two different techniques. You're right in saying that the same could
be applied to both cases, nothing naive in this :-)


> item 36) section 6.4.3
> 
> An example contains XML elements that seem to be unnecessarily
> complex:
> 
>        
>          
>            *
>            
>          
>        
> 
> As far as I can tell from the SRGS specification,  functions
> more-or-less as a type of parenthesis, and is needed only when (1) a
> "weight" or "repeat" attribute needs to be applied to the group, (2)
> delimiting one alternative of a  element, or (3) constructing
> the "null" regular expression (that consumes no input and always
> matches).  Thus, these examples can be simplified to:
> 
>        
>          *
>          
>        
> 
> Then again, if the example is taken from a real interaction, perhaps
> it is best to leave it as it really happened.
> 


[LM] I'm not an expert of SRGS, so I'm not sure about this. This is how
we implemented it in our Media Server, and it works this way, but it
would be nice to hear from other implementers to see if they usually
realize similar scenarios in a different way!


> item 37) section 6.4.3
> 
>       to implement is a , and we are only interested in two-
>       digits DTMF strings (maxdigits); the AS is not interested in a
> 
> "two-digits" should be "two-digit".  (Because this phrase is used as a
> modifier of "DTMF strings", the "digit" is not plural.)
> 


[LM] Ok.


>       instructs the MS into modifying the volume of the UAC-->conference
> 
> "into modifying" would better be "to modify".
> 


[LM] Ok.


>       audio flow (setgain=-5dB sendonly); notice how the request also
> 
> This is probably intended to be "-3dB", as all other uses of setgain
> in this section (including the displayed messages) use a 3 dB
> increment.
> 


[LM] Right, we0ll make this consistent.


> item 38) section 6.4.3
> 
> This section leads to a question about the semantics of the  controltype="setgain" ...> operation:  Clearly, initially the stream
> is output at the same volume as the input media.  But when " controltype='setgain' value='+1'>" is applied, does that cause the
> stream's output volume to be set to +1 dB *relative to the input
> media* or to +1 dB *relative to the previous volume setting*?
> 
> E.g., if I apply that operation twice, does the second application
> leave the amplification at +1 dB or raise it to +2 dB?
> 
> The examples in section 6.4.3 suggest the second interpretation.
> 
> The text in draft-ietf-mediactrl-mixer-control-package-14 is not clear
> on this point: "setgain" is only discussed in section 4.2.2.5.1, and
> it says "use the value of the "value" attribute as a specific gain
> measured in dB to apply".  That would be most likely to mean "as a
> specific gain measured in dB to apply to the input", which suggests
> the first interpretation.
> 
> In any case, the semantics of this need to be clarified and the
> example adjusted accordingly.
> 


[LM] If I recall correctly, when we first implemented this we discussed
it with the IVR authors during a meeting. If I'm not wrong the
conclusion was that setgain *sets* the gain, and does not modify the
previous value. I don't have the MS code in front of me right now,
though, I'll have to double check how we implemented this and let you
know.

IVR authors, any insight on this from a specification point of view?


> item 39) section 7.1
> 
>    Each MS makes use of the publishing interface to provide an MRB with
>    relevant information.
> 
> In the relationship between the MRB and MS, the MRB initiates the
> relationship.  Thus, it would be clearer to express this:
> 
>    An MRB makes use of the MS's publishing interface to acquire
>    relevant information.
> 
>    It is
>    enough to point out that, in this case, the MRB adds a new voice to
>    the 'Packages' it needs support for (mrb-publish/1.0).
> 
> "voice" should be "item".
> 
>    All
>    this messages flow through the control channel as all the messages in
> ---^^^^
> should be "these"
> ----------------------------------------------------^
> insert "do"
>    this document.
> 


[LM] Ok.


> item 40) section 7.1 message B1
> 
> This seems to be the only place in the draft where whitespace has been
> introduced where character content is valid, and so there is a
> question whether the draft needs to indicate that the whitespace would
> not be present on the wire.  The relevant elements are:
> 
>         
>             
>                 
>                      nbest
>                 
>             
>             
>                 
>                      single-view
>                 
>                 
>                      dual-view
>                 
>                 
>                      dual-view-crop
>                 
>                 
>                      dual-view-2x1
>                 
>                 
>                      dual-view-2x1-crop
>                 
>                 
>                      quad-view
>                 
>                 
>                      multiple-5x1
>                 
>                 
>                      multiple-3x3
>                 
>                 
>                      multiple-4x4
>                 
>             
>         
> 
> I'm not sure if the schema defining urn:ietf:params:xml:ns:mrb-publish
> indicates that the whitespace before and after the mixing mode names
> is to be ignored.  But this might be a place to use the
> backslash-line-folding convention specified in section 2:
> 
>         
>             
>                  \
>                      nbest \
>                 
>             
>             
>                  \
>                      single-view \
>                 
>                  \
>                      dual-view \
>                 
>                  \
>                      dual-view-crop \
>                 
>                  \
>                      dual-view-2x1 \
>                 
>                  \
>                      dual-view-2x1-crop \
>                 
>                  \
>                      quad-view \
>                 
>                  \
>                      multiple-5x1 \
>                 
>                  \
>                      multiple-3x3 \
>                 
>                  \
>                      multiple-4x4 \
>                 
>             
>         
> 


[LM] Yes, as I anticipated, we added that text to reflect a similar
comment you made when reviewing the MRB draft. This fix you suggest
makes sense, so we'll add it to the draft.


> item 41) section 7.1, section 7.2, section 7.2.1
> 
>    In the Inline mode, instead, the MRB is in the
>    path between the AS and the pool of MSs it is handling.
> 
>    Anyway, the MRB is also
>    conceived to work with ASs that are unaware of its functionality,
> 
>    and the SIP addresses of the chosen MSs.
> 
> Generally, "AS" and "MS" are used as the plurals of "AS" and "MS", but
> in these instances, "ASs" and "MSs" are used.
> 


[LM] You're right, I fixed this in the MRB and not here, sorry. Besides,
ASs sounds really bad... :-)


> item 42) section 7.1
> 
>    request itself and an SDP related to related to either the creation
> -----------------------------^^^^^^^^^^^^^^^^^^^^^
> "related to" is duplicated.
> 
> item 43) section 7.2.1
> 
>    MS the MRB has deemed better capable to fulfill the AS requirements),
> -------------------------^^^^^^
> This should be "best".
> -------------------------------------------------------^^
> This should be "AS's" or "AS'" (depending on which spelling convention
> we are using).
> 
>       targeting the request, and as a consequence picks up two MS which
> --------------------------------------------------^^^^^^^^
> I think you want "picks" here.
> 
>    after the Query the AS<->interaction becomes 1:1, UAC media dialogs
> ----------------------------^
> Something appears to be missing here.
> 


[LM] We'll fix them all.


> item 44) section 7.2.2.1, section 7.2.2.2, section 7.2.3
> 
> I think it would make the diagrams a little easier for the naive
> reader to follow if the media types specified in the SDP of the
> message bodies were given.  E.g., if an INVITE or 200 carries an
> application/sdp body for audio media, that is shown on the diagram.
> This would be particularly helpful in 7.2.3, where it takes the reader
> more consideration to deduce what the media types must be.  Updated in
> this way, the diagrams are as follows.  (But this has removed the
> comments noting where the SDP has been copied from one message to
> another.  That may need to be improved.)


[LM] Ok, we'll try and improve this to make it clearer.


> 
> 7.2.2.1.  Inline-aware Mode: CFW-based approach
> 
>    AS                      MRB                          MS
>     |                       |                           |
>     | 1. INVITE             |                           |
>     | (multipart/mixed:     |                           |
>     |  audio,               |                           |
>     |  application/mrb-consumer+xml)                    |
>     |---------------------->|                           |
>     |       2. 100 (Trying) |                           |
>     |<----------------------|                           |
>     |                       |--+ Extract SDP and        |
>     |                       |  | MRB payloads; handle   |
>     |                       |<-+ Consumer request to    |
>     |                       |    pick MS                |
>     |                       |                           |
>     |                       | 3. INVITE                 |
>     |                       | (audio)                   |
>     |                       |-------------------------->|
>     |                       |           4. 100 (Trying) |
>     |                       |<--------------------------|
>     |                       |                           |--+ Negotiate
>     |                       |                           |  | CFW Control
>     |                       |                           |<-+ Channel
>     |                       |                 5. 200 OK |
>     |                       |                   (audio) |
>     |                       |<--------------------------|
>     |                       | 6. ACK                    |
>     |                       |-------------------------->|
>     |        Prepare new +--|                           |
>     |       payload with |  |                           |
>     |    SDP from MS and +->|                           |
>     |     Consumer reply    |                           |
>     |                       |                           |
>     |             7. 200 OK |                           |
>     |     (multipart/mixed: |                           |
>     |      audio,           |                           |
>     |      application/mrb-consumer+xml)                |
>     |<----------------------|                           |
>     | 8. ACK                |                           |
>     |---------------------->|                           |
>     |                       |                           |
>     |--+ Read Cons. reply   |                           |
>     |  | and use SDP to     |                           |
>     |<-+ create CFW Chn.    |                           |
>     |                       |                           |
>     |                                                   |
>     |<<############## TCP CONNECTION #################>>|
>     |                                                   |
>     | CFW SYNC                                          |
>     |++++++++++++++++++++++++++++++++++++++++++++++++++>|
>     |                                                   |
> 
> 7.2.2.2.  Inline-aware Mode: Media dialog-based approach
> 
>    UAC              AS                     MRB                        MS
>     |               |                       |                          |
>     | 1. INVITE     |                       |                          |
>     | (audio)       |                       |                          |
>     |-------------->|                       |                          |
>     | 2. 100 Trying |                       |                          |
>     |<--------------|                       |                          |
>     |               | 3. INVITE             |                          |
>     |               | (multipart/mixed:     |                          |
>     |               |  audio,               |                          |
>     |               |  application/mrb-consumer_xml)                   |
>     |               |---------------------->|                          |
>     |               |       4. 100 (Trying) |                          |
>     |               |<----------------------|                          |
>     |               |                       |--+ Extract SDP and       |
>     |               |                       |  | MRB payloads; handle  |
>     |               |                       |<-+ Consumer request to   |
>     |               |                       |    pick Media Servers    |
>     |               |                       |                          |
>     |               |                       | 5. INVITE                |
>     |               |                       | (audio)                  |
>     |               |                       |------------------------->|
>     |               |                       |          6. 100 (Trying) |
>     |               |                       |<-------------------------|
>     |               |                       |                       +--|
>     |               |                       |   Handle media dialog |  |
>     |               |                       |       (connection-id) +->|
>     |               |                       |                          |
>     |               |                       |                7. 200 OK |       
>     |               |                       |                  (audio) |
>     |               |                       |<-------------------------|
>     |               |                       | 8. ACK                   |
>     |               |                       |------------------------->|
>     |               |        Prepare new +--|                          |
>     |               |       payload with |  |                          |
>     |               |    SDP from MS and +->|                          |
>     |               |     Consumer reply    |                          |
>     |               |                       |                          |
>     |               |             9. 200 OK |                          |
>     |               |     (multipart/mixed: |                          |
>     |               |      audio,           |                          |
>     |               |      application/mrb-consumer+xml)               |
>     |               |<----------------------|                          |
>     |               | 10. ACK               |                          |
>     |               |---------------------->|                          |
>     |               |                       |                          |
>     |               |--+ Read Cons. reply   |                          |
>     |               |  | and send SDP       |                          |
>     |               |<-+ back to UAC        |                          |
>     |    11. 200 OK |                       |                          |
>     |       (audio) |                       |                          |
>     |<--------------|                       |                          |
>     | 12. ACK       |                       |                          |
>     |-------------->|                       |                          |
>     |               |                       |                          |
>     |<<*************************** RTP ******************************>>|
>     |               |                       |                          |
>     |               |--+ Negotiate          |                          |
>     |               |  | CFW channel        |                          |
>     |               |<-+ towards MS         |                          |
>     |               |    (if needed)        |                          |
>     |               |                       |                          |
>     |               |<<############## TCP CONNECTION ################>>|
>     |               |                                                  |
>     |               | CFW SYNC                                         |
>     |               |+++++++++++++++++++++++++++++++++++++++++++++++++>|
>     |               |                                                  |
> 
> 7.2.3.  Inline-unaware Mode
> 
>    AS                      MRB                          MS
>     |                       |                           |
>     | 1. INVITE             |                           |
>     | (application/cfw)     |                           |
>     |---------------------->|                           |
>     |       2. 100 (Trying) |                           |
>     |<----------------------|                           |
>     |                       |--+ Pick a MS              |
>     |                       |  | and redirect           |
>     |                       |<-+ INVITE there           |
>     |                       |                           |
>     |                       | 3. INVITE                 |
>     |                       | (application/cfw)         |
>     |                       |-------------------------->|
>     |                       |           4. 100 (Trying) |
>     |                       |<--------------------------|
>     |                       |                           |--+ Negotiate
>     |                       |                           |  | CFW Control
>     |                       |                           |<-+ Channel
>     |                       |                 5. 200 OK |
>     |                       |         (application/cfw) |
>     |                       |<--------------------------|
>     |                       | 6. ACK                    |
>     |                       |-------------------------->|
>     |                       |                           |
>     |             7. 200 OK |                           |
>     |     (application/cfw) |                           |
>     |<----------------------|                           |
>     | 8. ACK                |                           |
>     |---------------------->|                           |
>     |                       |                           |
>     |                                                   |
>     |<<############## TCP CONNECTION #################>>|
>     |                                                   |
>     | CFW SYNC                                          |
>     |++++++++++++++++++++++++++++++++++++++++++++++++++>|
>     |                                                   |
> 
> item 45) section 7.2.2
> 
>    An AS willing to issue a Concumer request by means of SIP, has to do
> ----------------------------^
> This should be "Consumer".
> 
>    envisages two kind of SIP dialogs a Consumer request may be sent
> -----------------^
> This should be "kinds".
> 
>    setup a control channel) or a UAC media dialog (a SIP dialog the AS
> ---^
> This should be "set up".  ("set up" functions like a verb; "setup"
> functions like a noun.)
> 
>    The behaviour in the two cases, which are called respectively CFW-
> -------^
> Probably better to say "behaviours" here.
>    based and Media dialog-based approach, is only slightly different,
> ------------------------------------------^
> Use "are", to go with "behaviors".
> 


[LM] OK.


> item 46) section 7.2.2.1, section 7.2.2.2
> 
>    Please note that, to ease the reading of the protocol contents, a
>    simple '=_Part' is used whenever a boundary for a 'multipart/mixed'
>    payload is provided, instead of the actual boundary that would be
>    inserted in the SIP messages.
> 
> This seems like a poor strategy, as the resulting figures are not
> strictly correct.  Perhaps use "Part" as the boundary value, which
> would result in figures that look like the following, which strictly
> correct and are just as easy to read:
> 
>    [..]
>    Content-Type: multipart/mixed;boundary="Part"
> 
>    --Part
>    Content-Type: application/sdp
> 
>    v=0
>    o=- 2890844526 2890842807 IN IP4 as.example.com
>    [...]
> 
>    --Part
>    Content-Type: application/mrb-consumer+xml
> 
>    
>                     xmlns="urn:ietf:params:xml:ns:mrb-consumer">
>       [...]
>    
> 
>    --Part--
> 


[LM] I think we did it this way after a comment received on the list:
Chris and I did the same for the examples in the MRB draft, for instance.
If you think it might improve the readibility of the document we'll
change this.


> In both of these sections, just before the message listings, there is
> a line containing only:
> 
>    o
> 


[LM] Probably a leftover, we'll remove it.


> In the following message titles, "SDP" appears in lower case:
> 
> section 7.2.2.1:
>     3. MRB -> MS (INVITE sdp only)
>     5. MRB <- MS (200 OK sdp)
> section 7.2.2.2:
>     5. MRB -> MS (INVITE sdp only)
>     7. MRB <- MS (200 OK sdp)
>     11. UAC <- AS (200 OK sdp)
> 
> item 47) section 7.2.3
> 
>    pick a MS rather than another.
> --------^
> Probably should be "one", to contrast with "another".
> 


[LM] OK.


> item 48) section 7.2.3
> 
> This example does not give the content of the messages, unlike the
> previous two examples.
> 


[LM] It's because in the IUMM mode no Consumer transaction is involved.
It's a normal RFC6230 Control Channel negotiation where the MRB acts
as an intermediary, that is, picking a MS for the AS according to some
logic. In this case, in fact, the AS does not support the MRB
specification, and so just tries to set up a control channel the way
it knows.


> item 49) section 7.3.1
> 
> This section is titled "Query/IAMM".  The call flow does mesh with the
> call flow in section 7.2.1, "Query Mode", but it does not mesh with
> the call flow in section 7.2.2.1, "Inline-aware Mode: CFW-based
> approach" nor with the call flow in section 7.2.2.2, "Inline-aware
> Mode: Media dialog-based approach".
> 
> It would probably be best to change the title of the section to
> "Query".  If necessary, an additional section should be added giving
> examples relevant to inline-aware mode.
> 
> item 50) section 7.3.1, section 7.3.2
> 
> The use of "IAMM" and "IUMM" is a bit opaque here, as those acronyms
> are not explicitly expanded anywhere in this document.  They seem to
> mean what is called "inline-aware mode" and "inline-unaware mode", but
> the acronyms of those phrases aren't the same as the acronyms used.
> 
> Perhaps these section titles could be changed to resemble those of
> 7.2.*, "7.3.1. Query and Inline-aware Mode" and "7.3.2. Inline-unaware
> Mode".  That doesn't fix the problem with the acronyms per se but does
> make the titles clearer.
> 


[LM] You're right about both comments, we'll try to make this clearer
and more consistent across the document.


> item 51) section 7.3.1
> 
> We might want to mention that in this scenario, the AS obtains
> assignment of an MS *before* any UAC makes a request, in order to have
> facilities to satisfy future SIP requests.  That is probably how AS's
> operate in practice, but a naive reader might expect that the AS will
> make the consumer request only after the AS receives a demand for its
> services.


[LM] Actually both Fig.53 and 54 show the AS creating a control channel
before receiving an INVITE from the UAC. Or was your point about a
different aspect?


> 
>    Nevertheless, there are cases when having an MRB in the signalling
>    path ...
> 
> You might want to say "the SIP signalling path" here.  By my count,
> there are *three* different signalling paths:  the COMEDIA negotiation
> (INVITE with application/cfw SDP), the CFW connection, and the SIP
> signalling (INVITE with audio/etc. SDP).
> 


[LM] OK.


> item 52) section 7.3.2
> 
>    As mentioned previously, in such a case the AS would interact with
> What case is "in such a case"?  (This is the first sentence of a
> section.)  It seems that this paragraph is trying to contrast "such a
> case" with "IUMM", but it's not clear what is going on.
> 


[LM] It's referring to the case described by the section title, which is
a poor editing choice. We'll make this more explicit.


>    That said, the IUMM case is also very interesting with respect to the
>    media dialogs management.  In fact, in the MRB-unaware mode there
> ---------^
> This should be "dialog".


[LM] OK.


>    would be no Consumer request and an AS would actually see the MRB as
>    an MS.  This means that, unlike the previous scenarios, there is
>    actually no choice, meaning the MRB would likely be in the signaling
> ------------^
> What is there "no choice" of?  The obvious choice is that of a MS, but
> the MRB clearly can choose which MS to sent the request to.


[LM] Probably a poorly translated sentence, as this makes more sense in
Italian. The sentence is trying to say that there is no active selection
process driven by an AS<->MRB interaction so yes, something eventually
leading to choosing a specific MS according to that. That's why the
document then explains a potential approach to take care of this.


>    path anyway.  The MRB could either redirect the AS to a MS directly
>    or transparently act a proxy/B2BUA and contact a MS (according to
>    implementation-specific policies) on behalf of the unaware AS.
> 
>    To overcome the scalability limitations of such an approach, the MR
> --------------------------------------------------------------^
> You should add here "at least in regard to the MRB being in the SIP
> signalling path for all calls" -- as far as I can tell, this is the
> only scaling problem this approach removes.  (The major one is that
> all calls handled by the AS have to be handled by only one MS.)
> 


[LM] OK.


>    Rather than recurring to explicit redirection, or always
> ---------------^
> This isn't the right word.  Perhaps "resorting" was intended?
> 


[LM] Yes, we'll fix this.


> item 53) section 7.3.2
> 
>    While apparently not a problem, this raises an issue when the same
>    unaware AS has several sessions with different MS: the AS would only
>    see one "virtual" MS (the MRB) and so it would relay all calls there,
>    making it hard for the MRB to understand where these media dialogs
>    should belong: specifically, whether the UAC calling belongs to the
>    AS application logic leading to MS1 or MS2, or wherever else.
> 
> This seems to be a deficiency in the CFW protocol:  If the AS
> establishes a CFW channel with the MS (via a SIP URI to an MRB), and
> then later the AS wants to addresses a SIP INVITE to the MS, it has no
> choice but to use the same SIP URI (which routes to the MRB).  This
> makes it impossible for the MRB to associate the SIP INVITE with the
> CFW connection, and thus it is difficult for the MRB to route the
> INVITE to the same MS.
> 
> What seems to be needed is for either the COMEDIA response
> (application/cfw) or CFW connection to provide a SIP URI that is the
> "real" SIP URI of the far-end of the CFW channel.
> 
> Actually, this seems to be a problem even if an AS is addressing an MS
> URI, but the URI resolves to a redundant set of MSs:  There seems to
> be no way to ensure that when a CFW channel is established that a
> subsequent SIP INVITE can be sent to the same MS.  This issue seems to
> be discussed in RFC 6230 section 3, but I can't find any solution
> there.
> 


[LM] The way it works now is that, for a specific MS, the same SIP URI
is used for both negotiating a control channel and attaching media
dialogs, yes. A way to overcome this may having the MS redirect media
dialogs to a different SIP URI when it receives them (that is, treat
control and media dialogs differently) but I realize how this sounds
like an implementation hack rather than a real solution.


> item 54) section 8
> 
>    receiving requests that may cross the bounds each AS is constrained
>    into.
> ---^
> Probably better as "within".
> 


[LM] OK.


> item 55) section 8
> 
> The detailed discussion of how the MS enforces security against the
> ASs is helpful, but it does not mention how the MS discerns which
> requests come from AS1 and which come from AS2.
> 
> Dale


[LM] Thanks again for your detailed review: this is exactly the kind of
thorough feedback we were looking for, as so far we had to rely on our
own, a bit biased and probably not very objective review process :-)

Lorenzo


> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com