From eburger@standardstrack.com Fri Jul 6 08:22:20 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 4AE5D21F8766 for ; Fri, 6 Jul 2012 08:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx4-Vyh2LCkx for ; Fri, 6 Jul 2012 08:22:19 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 0B76421F8773 for ; Fri, 6 Jul 2012 08:22:19 -0700 (PDT) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:60750 helo=[192.168.15.158]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SnAMc-0003Y4-4S for mediactrl@ietf.org; Fri, 06 Jul 2012 08:22:34 -0700 From: Eric Burger Content-Type: multipart/signed; boundary=Apple-Mail-46-356214858; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 6 Jul 2012 11:22:31 -0400 Message-Id: To: mediactrl@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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] Draft MRB -13 Shepherd Writeup 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, 06 Jul 2012 15:22:20 -0000 --Apple-Mail-46-356214858 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is what will accompany the -13, and hopefully final, draft of the = MRB document. Thoughts welcome. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? =20 Proposed Standard, as indicated on the title page. =20 =20 ----- (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: =20 Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. =20 Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? =20 Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? =20 Personnel Who is the Document Shepherd? Who is the Responsible Area Director? =20 ----- Technical Summary =20 The MediaCtrl work group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signaling protocol which provides many inherent capabilities for message routing. A need exists for intelligent, application level media service selection based on non-static signaling properties, especially in deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. =20 Working Group Summary =20 The working group consensus on this document is solid. Two WGLCs were held, one after the initial consensus on the document, and one after extensive review and implementation experience dictated a number of small improvements to the protocol and its description. =20 Personnel Dale Worley is the document shepherd. Robert Sparks is the responsible AD. ----- =20 =20 (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. =20 Line by line reading as a relative newcomer to the work group. =20 =20 (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?=20 =20 I [Dale] have no such concerns. The only plausible concern is that the protocol seems to be overly complex, in that it allows several different modes of operation for broadly similar actions. But the people involved in the draft are involved in practical deployments, and they have found the various alternatives in the protocol are necessary in various practical situations. =20 =20 (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. =20 See (4) above. =20 =20 (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. =20 I [Eric] have the concern that we do not properly use the xml:lang tag. Review from W3C folks have highlighted the incorrect use of the tag. There is a risk that a network element may take a snippet of a MRB protocol data unit, put it into an XML document, and inadvertently change the language of that XML document to the snippets' language. However, we do not today see any circumstance where this is likely to happen. =20 To fix this would mean changing all of the MEDIACTRL protocol suite, not only the MRB protocol described by this document. Because of this, the work group felt that keeping things consistent was much more important than fixing this minor issue. Moreover, most of the MEDIACTRL protocols have many years of deployment experience in live networks. =20 It is our estimation that changing all of the protocols to change only the xml:lang tag. would not see widespread deployment. Thus, it would not help interoperability, as any new implementations would be unaware that the industry was not following such a changed specification. =20 The plan to remedy this error is to finish the work we have now. This MRB document is the last protocol document in the MEDIACTRL suite. This will enable us to close this work group. Then we can charter a new work group with the task of reviewing the deployment experience, potentially brining the specifications to Internet Standard, and fix this outstanding xml:lang issue. =20 =20 (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. =20 Yes. =20 =20 (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. =20 AT&T has filed 3 IPR disclosures regarding the predecessor draft, draft-boulton-mediactrl-mrb: ID # 897, ID # 898, and ID # 899. AT&T is listed as offering RAND licensing terms. =20 The IPR disclosures were submitted in 2007. The chairs solicited feedback from the WG twice, in 2007 and 2008. There seems to have been no response to the solicitation and no further discussion of the IPR issues on any IETF mailing list, suggesting that no controversy ensued. I would expect that any implementers who worried that the IPR would be burdensome would have spoken up. =20 Neither of the chairs at the time (Eric Burger and Spencer Dawkins), nor two of the three authors (Chris Boulton and Lorenzo Miniero) work for AT&T, so there seems to be no reason to suspect undue influence of AT&T to promote its commercial interests. (The third author, Gary Munson, does work for AT&T.) =20 The WGLC of 7 Feb 2012 specifically mentioned the IPR disclosures, to provide a last opportunity for implementers to express any concerns over the IPR situation. No objections were raised regarding IPR. =20 =20 (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? =20= =20 A WGLC was given on the -02 version on 15 Dec 2009. It received no responses. A final WGLC on the -12 version was given on 7 Feb 2012. It received no responses either. =20 =20 =20 (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) =20 None. =20 =20 (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. =20 None (on -12). =20 =20 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. =20 "Registration of application/mrb-publish+xml and application/mrb-consumer+xml" was sent to ietf-types on 19 Jan 2012. Two responses were received from one person. The comments were minor editorial matters which I [Dale] believe do not require changes to the draft. =20 =20 (13) Have all references within this document been identified as either normative or informative? =20 Yes. =20 =20 (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? =20 None. =20 =20 (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in = the Last Call procedure. =20 None. =20 =20 (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. =20 None. =20 =20 (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). =20 Confirmed. =20 =20 (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. =20 There are new IANA registrations, but no new IANA registries. =20 =20 (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. =20 One author (Lorenzo Miniero) checked the schemas using Eclipse and XML Spy, and validated the examples using a JAXB-based tool. =20 --Apple-Mail-46-356214858 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 AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNzA2MTUyMjMxWjAjBgkqhkiG9w0BCQQxFgQU OnC+SxxZDIaP6Oxug+5IWmPYHrswgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEACVZwKbOQdcinTWRzYi6oddMx1FkSV54v6WcGN98Vxm4MhWcaZmAt T8851C30iavKS6mqGiC9QfQNBBG64/YrO5JYgrQEXEgXoaViZHh2RQGw0pv3RtzhavwPtnl4gUZF Mrp/UUzn4eiSikD+Wo8/RIemnb1eyqpyGX/09SBAVNybEvodJmUxTItjvzEr/1HMjZuYpRNqV0p5 3Pe2WKFMsQR0kWYpjgkco+TOphqx/mNopWJKOqTg7nvkXNwATvGVT6zjxg7t2JqxH4XGQffHKtco 4iU+OHqsmIBvmBt4vNZFDk8ogLVatfOVini6zIF3Gl8XVw/judPZpRMl2R2UDgAAAAAAAA== --Apple-Mail-46-356214858-- From internet-drafts@ietf.org Tue Jul 10 06:25:12 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 9211821F86F5; Tue, 10 Jul 2012 06:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDby+1Q3vwM5; Tue, 10 Jul 2012 06:25:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A886621F8691; Tue, 10 Jul 2012 06:25:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120710132511.15850.68823.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2012 06:25:11 -0700 Cc: mediactrl@ietf.org Subject: [MEDIACTRL] I-D Action: draft-ietf-mediactrl-mrb-13.txt 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, 10 Jul 2012 13:25:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Media Server Control Working Group of the= IETF. Title : Media Resource Brokering Author(s) : Chris Boulton Lorenzo Miniero Gary Munson Filename : draft-ietf-mediactrl-mrb-13.txt Pages : 142 Date : 2012-07-10 Abstract: The MediaCtrl work group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mediactrl-mrb-13 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mediactrl-mrb-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lorenzo@meetecho.com Tue Jul 10 06:46: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 77E5A21F8714 for ; Tue, 10 Jul 2012 06:46:28 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDUKgCDvy57q for ; Tue, 10 Jul 2012 06:46:27 -0700 (PDT) Received: from smtplq01.aruba.it (smtpweb23.aruba.it [62.149.158.23]) by ietfa.amsl.com (Postfix) with SMTP id 359AE21F870E for ; Tue, 10 Jul 2012 06:46:26 -0700 (PDT) Received: (qmail 24432 invoked by uid 89); 10 Jul 2012 13:46:52 -0000 Received: from unknown (HELO smtp1.aruba.it) (62.149.158.221) by smtplq01.aruba.it with SMTP; 10 Jul 2012 13:46:52 -0000 Received: (qmail 7204 invoked by uid 89); 10 Jul 2012 13:46:52 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.200) by smtp1.ad.aruba.it with SMTP; 10 Jul 2012 13:46:52 -0000 Date: Tue, 10 Jul 2012 15:46:42 +0200 From: Lorenzo Miniero To: mediactrl@ietf.org Message-ID: <20120710154642.43be1860@lminiero-acer> Organization: Meetecho X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Cc: Chris Boulton Subject: [MEDIACTRL] Fw: New Version Notification for draft-ietf-mediactrl-mrb-13.txt 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, 10 Jul 2012 13:46:28 -0000 Dear all, during his AD review of the MRB draft, Robert provided us with a lot of excellent feedback, which greatly helped improving the document. The result so far is this new version I've just submitted, which will hopefully need just some editorial refinement to be considered complete. There's still a pending issue, though, that Robert asked us to bring to the list. In order to help you understand what the issue is about, I'll paste here the exact point Robert raised: The 4th bullet of section 5.2.2.1's third list of bullets inspires the question of whether MRBs in IAMM support offerless invites. Please make it clear in the document what an MRB should do with an INVITE that contains no SDP. The problem in giving a simple aswer to this point is that, considering the different scenarios that may occur in the IAMM mode, an offerless INVITE could confuse the MRB. Specifically, as you'll know if you read the draft, an INVITE reaching the MRB in IAMM mode can be any of the following: 1) an INVITE an AS sends to request a new session, or update an existing one, to the MRB, and negotiate a control channel with one of the chosen MS (in this case, the payload is multipart, containing both the Consumer request as XML and the SDP to negotiate the control channel); 2) an INVITE an AS sends to request a new session, or update an existing one, to the MRB, and attach a media session to a MS (in this case too, the payload is multipart, containing both the Consumer request as XML and the SDP to negotiate the media streams); 3) an INVITE an AS sends to just attach a media session to a MS (in this case, the payload only contains the SDP to negotiate the media streams). All of the above scenario are documented in the Examples sections, for an easier understanding of how they're conceived. The problem with offerless INVITEs is that the MRB might (WILL) be confused about what the AS is asking for. The easy way out might be just saying "the MRB doesn't support offerless INVITEs", but this could look overly restrictive. An alternative might be adding some text that explains that, whenever an MRB receives an offerless INVITE, it must assume it is related to the 3) case, that is, an AS will only originate such INVITEs when trying to attach a media dialog to a MS. Of course these are just a few alternatives that have come to my mind: if you have any feedback or suggestion on how to best proceed on this matter and close this final issue, please let us know. Thanks, Lorenzo Inizio messsaggio inviato: Data: Tue, 10 Jul 2012 06:25:12 -0700 Da: internet-drafts@ietf.org A: lorenzo@meetecho.com Cc: gamunson@att.com, chris@ns-technologies.com Oggetto: New Version Notification for draft-ietf-mediactrl-mrb-13.txt A new version of I-D, draft-ietf-mediactrl-mrb-13.txt has been successfully submitted by Lorenzo Miniero and posted to the IETF repository. Filename: draft-ietf-mediactrl-mrb Revision: 13 Title: Media Resource Brokering Creation date: 2012-07-10 WG ID: mediactrl Number of pages: 142 URL: http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-mrb-13.txt Status: http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb Htmlized: http://tools.ietf.org/html/draft-ietf-mediactrl-mrb-13 Diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-mediactrl-mrb-13 Abstract: The MediaCtrl work group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. The IETF Secretariat -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From keith.drage@alcatel-lucent.com Tue Jul 10 07:19:43 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 1456C21F8709 for ; Tue, 10 Jul 2012 07:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.035 X-Spam-Level: X-Spam-Status: No, score=-110.035 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1hy-94nZdBQ for ; Tue, 10 Jul 2012 07:19:42 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id E4C5921F8724 for ; Tue, 10 Jul 2012 07:19:41 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6AECoFO006086 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Jul 2012 16:20:02 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 10 Jul 2012 16:19:19 +0200 From: "DRAGE, Keith (Keith)" To: Lorenzo Miniero , "mediactrl@ietf.org" Date: Tue, 10 Jul 2012 16:19:17 +0200 Thread-Topic: [MEDIACTRL] Fw: New Version Notification for draft-ietf-mediactrl-mrb-13.txt Thread-Index: Ac1eooxMm5jyoA5PSVG73n1ZVEhqQAAAD9UA Message-ID: References: <20120710154642.43be1860@lminiero-acer> In-Reply-To: <20120710154642.43be1860@lminiero-acer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: Chris Boulton Subject: Re: [MEDIACTRL] Fw: New Version Notification for draft-ietf-mediactrl-mrb-13.txt 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, 10 Jul 2012 14:19:43 -0000 I guess my opinion would be that the offerless INVITE is a valid SIP INVITE= , and therefore it should attempt to apply the MRF selection policy on such= an INVITE. Either it can do that successfully, or it can reject the request back to th= e source and wait for the source to come to a better request. Given that the source may not know an MRB is involved, I am not sure that w= e can preclude offerless INVITES. What is not possible is changing the MRB decision after the selection polic= y has been applied. Therefore if the SDP finally resolves to being video, a= nd the decision was made on the assumption that it would turn out to be spe= ech, then the MRF selected is not reversible, except by one entity clearing= and trying again. However in many scenarios, something can be made to work. My view is just cover these considerations in informative text, and allow o= fferless INVITES (or at least not preclude them). Keith > -----Original Message----- > From: mediactrl-bounces@ietf.org [mailto:mediactrl-bounces@ietf.org] On > Behalf Of Lorenzo Miniero > Sent: 10 July 2012 14:47 > To: mediactrl@ietf.org > Cc: Chris Boulton > Subject: [MEDIACTRL] Fw: New Version Notification for draft-ietf- > mediactrl-mrb-13.txt >=20 > Dear all, >=20 > during his AD review of the MRB draft, Robert provided us with a lot of > excellent feedback, which greatly helped improving the document. The > result so far is this new version I've just submitted, which will > hopefully need just some editorial refinement to be considered complete. >=20 >=20 > There's still a pending issue, though, that Robert asked us to bring to > the list. In order to help you understand what the issue is about, I'll > paste here the exact point Robert raised: >=20 > The 4th bullet of section 5.2.2.1's third list of bullets inspires > the question of whether MRBs in IAMM support offerless invites. > Please make it clear in the document what an MRB should do with an > INVITE that contains no SDP. >=20 > The problem in giving a simple aswer to this point is that, > considering the different scenarios that may occur in the IAMM mode, an > offerless INVITE could confuse the MRB. Specifically, as you'll know if > you read the draft, an INVITE reaching the MRB in IAMM mode can be any > of the following: >=20 > 1) an INVITE an AS sends to request a new session, or update an > existing one, to the MRB, and negotiate a control channel with one > of the chosen MS (in this case, the payload is multipart, containing > both the Consumer request as XML and the SDP to negotiate the control > channel); >=20 > 2) an INVITE an AS sends to request a new session, or update an > existing one, to the MRB, and attach a media session to a MS (in this > case too, the payload is multipart, containing both the Consumer > request as XML and the SDP to negotiate the media streams); >=20 > 3) an INVITE an AS sends to just attach a media session to a MS (in > this case, the payload only contains the SDP to negotiate the media > streams). >=20 > All of the above scenario are documented in the Examples sections, for > an easier understanding of how they're conceived. >=20 > The problem with offerless INVITEs is that the MRB might (WILL) be > confused about what the AS is asking for. The easy way out might be > just saying "the MRB doesn't support offerless INVITEs", but this could > look overly restrictive. An alternative might be adding some text that > explains that, whenever an MRB receives an offerless INVITE, it must > assume it is related to the 3) case, that is, an AS will only > originate such INVITEs when trying to attach a media dialog to a MS. >=20 > Of course these are just a few alternatives that have come to my mind: > if you have any feedback or suggestion on how to best proceed on this > matter and close this final issue, please let us know. >=20 >=20 > Thanks, > Lorenzo >=20 >=20 >=20 > Inizio messsaggio inviato: >=20 > Data: Tue, 10 Jul 2012 06:25:12 -0700 > Da: internet-drafts@ietf.org > A: lorenzo@meetecho.com > Cc: gamunson@att.com, chris@ns-technologies.com > Oggetto: New Version Notification for draft-ietf-mediactrl-mrb-13.txt >=20 >=20 >=20 > A new version of I-D, draft-ietf-mediactrl-mrb-13.txt > has been successfully submitted by Lorenzo Miniero and posted to the > IETF repository. >=20 > Filename: draft-ietf-mediactrl-mrb > Revision: 13 > Title: Media Resource Brokering > Creation date: 2012-07-10 > WG ID: mediactrl > Number of pages: 142 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-mrb-13.txt > Status: > http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb > Htmlized: http://tools.ietf.org/html/draft-ietf-mediactrl-mrb-13 > Diff: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mediactrl-mrb-13 >=20 > Abstract: > The MediaCtrl work group in the IETF has proposed an architecture for > controlling media services. The Session Initiation Protocol (SIP) is > used as the signalling protocol which provides many inherent > capabilities for message routing. In addition to such signalling > properties, a need exists for intelligent, application level media > service selection based on non-static signalling properties. This is > especially true when considered in conjunction with deployment > architectures that include 1:M and M:N combinations of Application > Servers and Media Servers. This document introduces a Media Resource > Broker (MRB) entity which manages the availability of Media Servers > and the media resource demands of Application Servers. The document > includes potential deployment options for an MRB and appropriate > interfaces to Application Servers and Media Servers. >=20 >=20 >=20 >=20 > The IETF Secretariat >=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 From internet-drafts@ietf.org Wed Jul 11 06:16:44 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 4F0EC21F86A0; Wed, 11 Jul 2012 06:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5isToHhTf0ei; Wed, 11 Jul 2012 06:16:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8279B21F865C; Wed, 11 Jul 2012 06:16:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120711131643.10952.51487.idtracker@ietfa.amsl.com> Date: Wed, 11 Jul 2012 06:16:43 -0700 Cc: mediactrl@ietf.org Subject: [MEDIACTRL] I-D Action: draft-ietf-mediactrl-call-flows-09.txt 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, 11 Jul 2012 13:16:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Media Server Control Working Group of the= IETF. Title : Media Control Channel Framework (CFW) Call Flow Examples Author(s) : Alessandro Amirante Tobia Castaldi Lorenzo Miniero Simon Pietro Romano Filename : draft-ietf-mediactrl-call-flows-09.txt Pages : 172 Date : 2012-07-11 Abstract: This document provides a list of typical Media Control Channel Framework [RFC6230] call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL- based Media Servers, as well as a base reference documentation for both implementors and protocol researchers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mediactrl-call-flows-09 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mediactrl-call-flows-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lorenzo@meetecho.com Wed Jul 11 06:17: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 C962821F86AA for ; Wed, 11 Jul 2012 06:17:28 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uyJ5xFKNLlH for ; Wed, 11 Jul 2012 06:17:27 -0700 (PDT) Received: from smtplq03.aruba.it (smtplq-out2.aruba.it [62.149.158.22]) by ietfa.amsl.com (Postfix) with SMTP id E8A9E21F8694 for ; Wed, 11 Jul 2012 06:17:26 -0700 (PDT) Received: (qmail 6659 invoked by uid 89); 11 Jul 2012 13:17:55 -0000 Received: from unknown (HELO smtp1.aruba.it) (62.149.158.221) by smtplq03.aruba.it with SMTP; 11 Jul 2012 13:17:55 -0000 Received: (qmail 30423 invoked by uid 89); 11 Jul 2012 13:11:15 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.200) by smtp1.ad.aruba.it with SMTP; 11 Jul 2012 13:11:15 -0000 Date: Wed, 11 Jul 2012 15:11:05 +0200 From: Lorenzo Miniero To: "DRAGE, Keith (Keith)" Message-ID: <20120711151105.4b66d4b4@lminiero-acer> In-Reply-To: References: <20120710154642.43be1860@lminiero-acer> Organization: Meetecho X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Cc: Chris Boulton , "mediactrl@ietf.org" Subject: Re: [MEDIACTRL] Fw: New Version Notification for draft-ietf-mediactrl-mrb-13.txt 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, 11 Jul 2012 13:17:28 -0000 Keith, thanks for your feedback! If nobody opposes to this view, we'll incorporate your suggestion in the next version of the draft to make it clearer for readers. Lorenzo Il giorno Tue, 10 Jul 2012 16:19:17 +0200 "DRAGE, Keith (Keith)" ha scritto: > I guess my opinion would be that the offerless INVITE is a valid SIP > INVITE, and therefore it should attempt to apply the MRF selection > policy on such an INVITE. > > Either it can do that successfully, or it can reject the request back > to the source and wait for the source to come to a better request. > > Given that the source may not know an MRB is involved, I am not sure > that we can preclude offerless INVITES. > > What is not possible is changing the MRB decision after the selection > policy has been applied. Therefore if the SDP finally resolves to > being video, and the decision was made on the assumption that it > would turn out to be speech, then the MRF selected is not reversible, > except by one entity clearing and trying again. > > However in many scenarios, something can be made to work. > > My view is just cover these considerations in informative text, and > allow offerless INVITES (or at least not preclude them). > > Keith > > > -----Original Message----- > > From: mediactrl-bounces@ietf.org > > [mailto:mediactrl-bounces@ietf.org] On Behalf Of Lorenzo Miniero > > Sent: 10 July 2012 14:47 > > To: mediactrl@ietf.org > > Cc: Chris Boulton > > Subject: [MEDIACTRL] Fw: New Version Notification for draft-ietf- > > mediactrl-mrb-13.txt > > > > Dear all, > > > > during his AD review of the MRB draft, Robert provided us with a > > lot of excellent feedback, which greatly helped improving the > > document. The result so far is this new version I've just > > submitted, which will hopefully need just some editorial refinement > > to be considered complete. > > > > > > There's still a pending issue, though, that Robert asked us to > > bring to the list. In order to help you understand what the issue > > is about, I'll paste here the exact point Robert raised: > > > > The 4th bullet of section 5.2.2.1's third list of bullets > > inspires the question of whether MRBs in IAMM support offerless > > invites. Please make it clear in the document what an MRB should do > > with an INVITE that contains no SDP. > > > > The problem in giving a simple aswer to this point is that, > > considering the different scenarios that may occur in the IAMM > > mode, an offerless INVITE could confuse the MRB. Specifically, as > > you'll know if you read the draft, an INVITE reaching the MRB in > > IAMM mode can be any of the following: > > > > 1) an INVITE an AS sends to request a new session, or update an > > existing one, to the MRB, and negotiate a control channel with > > one of the chosen MS (in this case, the payload is multipart, > > containing both the Consumer request as XML and the SDP to > > negotiate the control channel); > > > > 2) an INVITE an AS sends to request a new session, or update an > > existing one, to the MRB, and attach a media session to a MS (in > > this case too, the payload is multipart, containing both the > > Consumer request as XML and the SDP to negotiate the media streams); > > > > 3) an INVITE an AS sends to just attach a media session to a MS > > (in this case, the payload only contains the SDP to negotiate the > > media streams). > > > > All of the above scenario are documented in the Examples sections, > > for an easier understanding of how they're conceived. > > > > The problem with offerless INVITEs is that the MRB might (WILL) be > > confused about what the AS is asking for. The easy way out might be > > just saying "the MRB doesn't support offerless INVITEs", but this > > could look overly restrictive. An alternative might be adding some > > text that explains that, whenever an MRB receives an offerless > > INVITE, it must assume it is related to the 3) case, that is, an AS > > will only originate such INVITEs when trying to attach a media > > dialog to a MS. > > > > Of course these are just a few alternatives that have come to my > > mind: if you have any feedback or suggestion on how to best proceed > > on this matter and close this final issue, please let us know. > > > > > > Thanks, > > Lorenzo > > > > > > > > Inizio messsaggio inviato: > > > > Data: Tue, 10 Jul 2012 06:25:12 -0700 > > Da: internet-drafts@ietf.org > > A: lorenzo@meetecho.com > > Cc: gamunson@att.com, chris@ns-technologies.com > > Oggetto: New Version Notification for > > draft-ietf-mediactrl-mrb-13.txt > > > > > > > > A new version of I-D, draft-ietf-mediactrl-mrb-13.txt > > has been successfully submitted by Lorenzo Miniero and posted to the > > IETF repository. > > > > Filename: draft-ietf-mediactrl-mrb > > Revision: 13 > > Title: Media Resource Brokering > > Creation date: 2012-07-10 > > WG ID: mediactrl > > Number of pages: 142 > > URL: > > http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-mrb-13.txt > > Status: > > http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb > > Htmlized: > > http://tools.ietf.org/html/draft-ietf-mediactrl-mrb-13 Diff: > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-mediactrl-mrb-13 > > > > Abstract: > > The MediaCtrl work group in the IETF has proposed an > > architecture for controlling media services. The Session > > Initiation Protocol (SIP) is used as the signalling protocol which > > provides many inherent capabilities for message routing. In > > addition to such signalling properties, a need exists for > > intelligent, application level media service selection based on > > non-static signalling properties. This is especially true when > > considered in conjunction with deployment architectures that > > include 1:M and M:N combinations of Application Servers and Media > > Servers. This document introduces a Media Resource Broker (MRB) > > entity which manages the availability of Media Servers and the > > media resource demands of Application Servers. The document > > includes potential deployment options for an MRB and appropriate > > interfaces to Application Servers and Media Servers. > > > > > > > > > > The IETF Secretariat > > > > > > -- > > 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/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 lorenzo@meetecho.com Wed Jul 11 06:22:44 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 A849321F8691 for ; Wed, 11 Jul 2012 06:22:44 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWr+3YJDRq3v for ; Wed, 11 Jul 2012 06:22:44 -0700 (PDT) Received: from smtplq04.aruba.it (smtplq-out2.aruba.it [62.149.158.22]) by ietfa.amsl.com (Postfix) with SMTP id 8BCC821F86AF for ; Wed, 11 Jul 2012 06:22:43 -0700 (PDT) Received: (qmail 6658 invoked by uid 89); 11 Jul 2012 13:23:11 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplq04.aruba.it with SMTP; 11 Jul 2012 13:23:11 -0000 Received: (qmail 25009 invoked by uid 89); 11 Jul 2012 13:23:11 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.200) by smtp2.ad.aruba.it with SMTP; 11 Jul 2012 13:23:11 -0000 Date: Wed, 11 Jul 2012 15:23:01 +0200 From: Lorenzo Miniero To: mediactrl@ietf.org Message-ID: <20120711152301.4e10d132@lminiero-acer> Organization: Meetecho X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp2.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Subject: [MEDIACTRL] Fw: New Version Notification for draft-ietf-mediactrl-call-flows-09.txt 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, 11 Jul 2012 13:22:44 -0000 Dear all, considering the MRB draft is basically done, and that we aligned the call flows document to its latest version, you can consider this document pretty much done as well. If you have any feedback or suggestion about it, please let us know. Thanks, Lorenzo Inizio messsaggio inviato: Data: Wed, 11 Jul 2012 06:16:43 -0700 Da: internet-drafts@ietf.org A: lorenzo@meetecho.com Cc: spromano@unina.it, tcastaldi@meetecho.com, alessandro.amirante@unina.it Oggetto: New Version Notification for draft-ietf-mediactrl-call-flows-09.txt A new version of I-D, draft-ietf-mediactrl-call-flows-09.txt has been successfully submitted by Lorenzo Miniero and posted to the IETF repository. Filename: draft-ietf-mediactrl-call-flows Revision: 09 Title: Media Control Channel Framework (CFW) Call Flow Examples Creation date: 2012-07-11 WG ID: mediactrl Number of pages: 172 URL: http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-call-flows-09.txt Status: http://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows Htmlized: http://tools.ietf.org/html/draft-ietf-mediactrl-call-flows-09 Diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-mediactrl-call-flows-09 Abstract: This document provides a list of typical Media Control Channel Framework [RFC6230] call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL- based Media Servers, as well as a base reference documentation for both implementors and protocol researchers. The IETF Secretariat -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From dworley@avaya.com Wed Jul 11 09:09:30 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 BEF4F11E8085 for ; Wed, 11 Jul 2012 09:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.659 X-Spam-Level: X-Spam-Status: No, score=-102.659 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK+Am-h2lycj for ; Wed, 11 Jul 2012 09:09:29 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 08F5521F85A2 for ; Wed, 11 Jul 2012 09:09:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAek/U/GmAcF/2dsb2JhbABFhWewYYEggQeCIAEBAQECARIREUMCBQsCAQgNDQImAgICMBUQAQEEDg0ah2UGoFKKHpMJgSCKNIRIMmADmzKKDoJ7gTo X-IronPort-AV: E=Sophos;i="4.77,569,1336363200"; d="scan'208";a="17804380" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 11 Jul 2012 12:05:50 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Jul 2012 12:06:42 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 11 Jul 2012 12:09:56 -0400 From: "Worley, Dale R (Dale)" To: "lorenzo@meetecho.com" Date: Wed, 11 Jul 2012 12:09:57 -0400 Thread-Topic: [MEDIACTRL] Fw: New Version Notification for draft-ietf-mediactrl-mrb-13.txt Thread-Index: Ac1ff52Frkbtxr3iTmqWkFvEqo6T4w== Message-ID: References: <20120710154642.43be1860@lminiero-acer> In-Reply-To: <20120710154642.43be1860@lminiero-acer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "chris@ns-technologies.com" , "mediactrl@ietf.org" Subject: Re: [MEDIACTRL] Fw: New Version Notification for draft-ietf-mediactrl-mrb-13.txt 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, 11 Jul 2012 16:09:31 -0000 KEkndmUgYXBwZW5kZWQgdGhlIGVzc2VudGlhbCBwYXJ0cyBvZiBMb3JlbnpvJ3MgbWVzc2FnZSBm b3IgcmVmZXJlbmNlLikKCkkndmUgZm9yZ290dGVuIG1hbnkgb2YgdGhlIGRldGFpbHMgb2YgdGhl IE1SQiBwcm90b2NvbCwgc28gYWNjZXB0IG15CmFwb2xvZ2llcyBmb3IgYW55dGhpbmcgSSd2ZSBt aXMtc3RhdGVkLgoKSW4gcmVnYXJkIHRvIG9mZmVybGVzcyBJTlZJVEVzLCBpdCBpcyBkZXNpcmFi bGUgdG8gc3VwcG9ydCB0aGVtIGlmIHRoZXJlCmlzIGEgcmVhc29uYWJsZSB3YXkgdG8gZG8gc28s IGJlY2F1c2UgdGhleSBhcmUgYSBzdGFuZGFyZCBwYXJ0IG9mIFNJUAphbmQgbWFueSBzY2VuYXJp b3MgYXNzdW1lIHRoYXQgdGhleSBhcmUgc3VwcG9ydGVkLiAgT24gdGhlIG90aGVyIGhhbmQsCmlu IG1vc3QgTVJCIGFwcGxpY2F0aW9ucywgdGhlIEFTIGtub3dzIHRoYXQgaXQgaXMgc2VuZGluZyB0 aGUgcmVxdWVzdCB0bwphbiBNUkIsIHNvIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGFzc3VtZSBh IGxpbWl0ZWQgcmFuZ2Ugb2Ygc2NlbmFyaW9zLgoKR2l2ZW4gTG9yZW56bydzIGJyZWFrZG93biBv ZiB0aGUgcG9zc2libGUgY2FzZXMsICgxKSBhbmQgKDIpICpyZXF1aXJlKgpjb25zdW1lciByZXF1 ZXN0IFhNTCwgYW5kIHRoZXJlZm9yZSBjYW5ub3QgaGFwcGVuIGluIHRoZSBjYXNlIG9mIGFuCm9m ZmVybGVzcyBJTlZJVEUuICBTbyBvbmx5IGNhc2UgKDMpIGNhbiBhcHBseSwgd2hpY2ggaXMgd2hh dCBMb3JlbnpvCnJlY29tbWVuZHMuICBPZiBjb3Vyc2UsIGluIG9yZGVyIGZvciB0aGUgTVJCIHRv IGltcGxlbWVudCB0aGF0LCBpdCBtdXN0CmhhdmUgc29tZSBzb3J0IG9mICJkZWZhdWx0IHBvbGlj eSIgZGV0ZXJtaW5pbmcgd2hpY2ggTVMgdGhlIHJlcXVlc3QgaXMKcm91dGVkIHRvIGlmIHRoZXJl IGlzIG5vIFNEUC4gIFRoYXQgTVMgd2lsbCBwcm92aWRlIHRoZSBvZmZlciBTRFAsIHdoaWNoCndp bGwgYmUgc2VudCBiYWNrIHRvIHRoZSBBUyBpbiB0aGUgSU5WSVRFIHJlc3BvbnNlLiAgSWYgdGhl cmUgYXJlIE1TcyBvZgp3aWRlbHkgdmFyeWluZyBjYXBhYmlsaXRpZXMsIGl0IG1heSBiZSB0aGF0 IHRoZSBNUkIgY2Fubm90IGltcGxlbWVudCBhCiJnb29kIiBkZWZhdWx0IHBvbGljeSwgYnV0IHRo YXQgc2VlbXMgdG8gYmUgdW5hdm9pZGFibGUuCgpBIG1vcmUgY29tcGxleCBjYXNlIGlzIGEgInZp cnR1YWxseSBvZmZlcmxlc3MiIElOVklURSwgd2hlcmUgdGhlIEFTCnByb3ZpZGVzIENvbnN1bWVy IHJlcXVlc3QgWE1MIGJ1dCBkb2VzIG5vdCBwcm92aWRlIFNEUCAocHJlc3VtYWJseQpiZWNhdXNl IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBjYWxsIGRpZCBub3QgcHJvdmlkZSBTRFApLiAgVGhpcyBj b3VsZCBiZQpkb25lIGJ5IHByb3ZpZGluZyBqdXN0IGEgQ29uc3VtZXIgcmVxdWVzdCBYTUwgYXMg YSBib2R5LCBvciBieSBwcm92aWRpbmcKYSBtdWx0aXBhcnQgYm9keSB3aXRoIG9ubHkgb25lIHBh cnQsIHRoZSBDb25zdW1lciByZXF1ZXN0IFhNTC4gIEl0CmFwcGVhcnMgZnJvbSBMb3JlbnpvJ3Mg Y2FzZXMsIHRoYXQgdGhpcyBzaXR1YXRpb24gaXMgZGlzdGluZ3Vpc2hhYmxlCmZyb20gdGhlICJu b3JtYWwiIGNhc2VzLiAgSSB3b3VsZCBleHBlY3QgdGhhdCB0aGUgTVJCIGNvdWxkIHRoZW4gcHJv Y2VzcwphbmQgYWN0IG9uIHRoZSBDb25zdW1lciByZXF1ZXN0IFhNTCBhcyBub3JtYWwsIGJ1dCBp ZiBpdCBlc3RhYmxpc2hlcyBhCnNlc3Npb24gd2l0aCB0aGUgTVMgKGJ5IHNlbmRpbmcgYW4gSU5W SVRFKSwgaXQgY2FuIGtub3cgdG8gc2VuZCBhbgpvZmZlcmxlc3MgSU5WSVRFLgoKU28gaXQgc2Vl bXMgdG8gbWUgdGhhdCB0aGVyZSBpcyBuZXZlciBhbnkgYW1iaWd1aXR5IGFzIHRvIHdoYXQgdGhl IE1SQgoic2hvdWxkIiBkbywgYW5kIGl0J3Mgbm90IGRpZmZpY3VsdCBmb3IgdGhlIE1SQiB0byBk byB0aGUgcmlnaHQgdGhpbmcuClRoZSBkaWZmaWN1bHR5IGlzIHRvIHdhcm4gdGhlIGltcGxlbWVu dGVycyB3aGF0IHRoZSAib2ZmZXJsZXNzIiBjYXNlcwphcmUgYW5kIGJld2FyZSB0byBpbXBsZW1l bnQgdGhlbS4KCk9yIGFtIEkgcGVyaGFwcyBvdmVybG9va2luZyBzb21ldGhpbmc/CgpEYWxlCgoK T24gVHVlLCAyMDEyLTA3LTEwIGF0IDE1OjQ2ICswMjAwLCBMb3JlbnpvIE1pbmllcm8gd3JvdGU6 Cgo+IFRoZSBwcm9ibGVtIGluIGdpdmluZyBhIHNpbXBsZSBhc3dlciB0byB0aGlzIHBvaW50IGlz IHRoYXQsCj4gY29uc2lkZXJpbmcgdGhlIGRpZmZlcmVudCBzY2VuYXJpb3MgdGhhdCBtYXkgb2Nj dXIgaW4gdGhlIElBTU0gbW9kZSwgYW4KPiBvZmZlcmxlc3MgSU5WSVRFIGNvdWxkIGNvbmZ1c2Ug dGhlIE1SQi4gU3BlY2lmaWNhbGx5LCBhcyB5b3UnbGwga25vdyBpZgo+IHlvdSByZWFkIHRoZSBk cmFmdCwgYW4gSU5WSVRFIHJlYWNoaW5nIHRoZSBNUkIgaW4gSUFNTSBtb2RlIGNhbiBiZSBhbnkK PiBvZiB0aGUgZm9sbG93aW5nOgo+IAo+ICAgIDEpIGFuIElOVklURSBhbiBBUyBzZW5kcyB0byBy ZXF1ZXN0IGEgbmV3IHNlc3Npb24sIG9yIHVwZGF0ZSBhbgo+ICAgIGV4aXN0aW5nIG9uZSwgdG8g dGhlIE1SQiwgYW5kIG5lZ290aWF0ZSBhIGNvbnRyb2wgY2hhbm5lbCB3aXRoIG9uZQo+ICAgIG9m IHRoZSBjaG9zZW4gTVMgKGluIHRoaXMgY2FzZSwgdGhlIHBheWxvYWQgaXMgbXVsdGlwYXJ0LCBj b250YWluaW5nCj4gICAgYm90aCB0aGUgQ29uc3VtZXIgcmVxdWVzdCBhcyBYTUwgYW5kIHRoZSBT RFAgdG8gbmVnb3RpYXRlIHRoZSBjb250cm9sCj4gICAgY2hhbm5lbCk7Cj4gCj4gICAgMikgYW4g SU5WSVRFIGFuIEFTIHNlbmRzIHRvIHJlcXVlc3QgYSBuZXcgc2Vzc2lvbiwgb3IgdXBkYXRlIGFu Cj4gICAgZXhpc3Rpbmcgb25lLCB0byB0aGUgTVJCLCBhbmQgYXR0YWNoIGEgbWVkaWEgc2Vzc2lv biB0byBhIE1TIChpbiB0aGlzCj4gICAgY2FzZSB0b28sIHRoZSBwYXlsb2FkIGlzIG11bHRpcGFy dCwgY29udGFpbmluZyBib3RoIHRoZSBDb25zdW1lcgo+ICAgIHJlcXVlc3QgYXMgWE1MIGFuZCB0 aGUgU0RQIHRvIG5lZ290aWF0ZSB0aGUgbWVkaWEgc3RyZWFtcyk7Cj4gCj4gICAgMykgYW4gSU5W SVRFIGFuIEFTIHNlbmRzIHRvIGp1c3QgYXR0YWNoIGEgbWVkaWEgc2Vzc2lvbiB0byBhIE1TIChp bgo+ICAgIHRoaXMgY2FzZSwgdGhlIHBheWxvYWQgb25seSBjb250YWlucyB0aGUgU0RQIHRvIG5l Z290aWF0ZSB0aGUgbWVkaWEKPiAgICBzdHJlYW1zKS4KPiAKPiBBbGwgb2YgdGhlIGFib3ZlIHNj ZW5hcmlvIGFyZSBkb2N1bWVudGVkIGluIHRoZSBFeGFtcGxlcyBzZWN0aW9ucywgZm9yCj4gYW4g ZWFzaWVyIHVuZGVyc3RhbmRpbmcgb2YgaG93IHRoZXkncmUgY29uY2VpdmVkLgo+IAo+IFRoZSBw cm9ibGVtIHdpdGggb2ZmZXJsZXNzIElOVklURXMgaXMgdGhhdCB0aGUgTVJCIG1pZ2h0IChXSUxM KSBiZQo+IGNvbmZ1c2VkIGFib3V0IHdoYXQgdGhlIEFTIGlzIGFza2luZyBmb3IuIFRoZSBlYXN5 IHdheSBvdXQgbWlnaHQgYmUKPiBqdXN0IHNheWluZyAidGhlIE1SQiBkb2Vzbid0IHN1cHBvcnQg b2ZmZXJsZXNzIElOVklURXMiLCBidXQgdGhpcyBjb3VsZAo+IGxvb2sgb3Zlcmx5IHJlc3RyaWN0 aXZlLiBBbiBhbHRlcm5hdGl2ZSBtaWdodCBiZSBhZGRpbmcgc29tZSB0ZXh0IHRoYXQKPiBleHBs YWlucyB0aGF0LCB3aGVuZXZlciBhbiBNUkIgcmVjZWl2ZXMgYW4gb2ZmZXJsZXNzIElOVklURSwg aXQgbXVzdAo+IGFzc3VtZSBpdCBpcyByZWxhdGVkIHRvIHRoZSAzKSBjYXNlLCB0aGF0IGlzLCBh biBBUyB3aWxsIG9ubHkKPiBvcmlnaW5hdGUgc3VjaCBJTlZJVEVzIHdoZW4gdHJ5aW5nIHRvIGF0 dGFjaCBhIG1lZGlhIGRpYWxvZyB0byBhIE1TLgoK From lorenzo@meetecho.com Thu Jul 12 03:00:39 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 2C7E721F87C7 for ; Thu, 12 Jul 2012 03:00:39 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UryZH0upsnj1 for ; Thu, 12 Jul 2012 03:00:38 -0700 (PDT) Received: from smtplq01.aruba.it (smtpweb23.aruba.it [62.149.158.23]) by ietfa.amsl.com (Postfix) with SMTP id 775A621F875A for ; Thu, 12 Jul 2012 03:00:37 -0700 (PDT) Received: (qmail 19637 invoked by uid 89); 12 Jul 2012 10:01:01 -0000 Received: from unknown (HELO smtp1.aruba.it) (62.149.158.221) by smtplq01.aruba.it with SMTP; 12 Jul 2012 10:01:01 -0000 Received: (qmail 14159 invoked by uid 89); 12 Jul 2012 10:01:01 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.200) by smtp1.ad.aruba.it with SMTP; 12 Jul 2012 10:01:01 -0000 Date: Thu, 12 Jul 2012 12:00:52 +0200 From: Lorenzo Miniero To: "Worley, Dale R (Dale)" Message-ID: <20120712120052.74559c65@lminiero-acer> In-Reply-To: References: <20120710154642.43be1860@lminiero-acer> Organization: Meetecho X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Cc: "chris@ns-technologies.com" , "mediactrl@ietf.org" Subject: Re: [MEDIACTRL] Fw: New Version Notification for draft-ietf-mediactrl-mrb-13.txt 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, 12 Jul 2012 10:00:39 -0000 Hi Dale, thanks for your feedback! I added a few comments inline. Il giorno Wed, 11 Jul 2012 12:09:57 -0400 "Worley, Dale R (Dale)" ha scritto: > (I've appended the essential parts of Lorenzo's message for > reference.) > > I've forgotten many of the details of the MRB protocol, so accept my > apologies for anything I've mis-stated. > > In regard to offerless INVITEs, it is desirable to support them if > there is a reasonable way to do so, because they are a standard part > of SIP and many scenarios assume that they are supported. On the > other hand, in most MRB applications, the AS knows that it is sending > the request to an MRB, so it would be possible to assume a limited > range of scenarios. > > Given Lorenzo's breakdown of the possible cases, (1) and (2) *require* > consumer request XML, and therefore cannot happen in the case of an > offerless INVITE. So only case (3) can apply, which is what Lorenzo > recommends. Of course, in order for the MRB to implement that, it > must have some sort of "default policy" determining which MS the > request is routed to if there is no SDP. That MS will provide the > offer SDP, which will be sent back to the AS in the INVITE response. > If there are MSs of widely varying capabilities, it may be that the > MRB cannot implement a "good" default policy, but that seems to be > unavoidable. > > A more complex case is a "virtually offerless" INVITE, where the AS > provides Consumer request XML but does not provide SDP (presumably > because the originator of the call did not provide SDP). This could > be done by providing just a Consumer request XML as a body, or by > providing a multipart body with only one part, the Consumer request > XML. It appears from Lorenzo's cases, that this situation is > distinguishable from the "normal" cases. I would expect that the MRB > could then process and act on the Consumer request XML as normal, but > if it establishes a session with the MS (by sending an INVITE), it > can know to send an offerless INVITE. > About this second scenario you're describing, this might not be that easy. In fact, a few meetings ago (I think it was in Anaheim but I may be wrong) what was supposed to be in the INVITE for the IAMM case was discussed, and if I recall correctly there were objections about having just the Consumer XML in the INVITE (that is, having the SIP case act mostly like HTTP in the Query mode), since this would have caused several problems according to how SIP works (but that may have been related to the fact we involved redirects as well). This lead us to eventually move to what we have in the draft now, that is the multipart stuff. That said, having just the Consumer XML in an INVITE (either as it is or as a multipart with only the XML) could probably confuse the MRB anyway: in fact, the Consumer XML may at the moment appear in either case 1) or 2) of my previous mail, and so the MRB would still not know whether it is supposed to negotiate a control channel or a media dialog which, as you pointed out, may be part of the decision process behind the MRB policy. But if this is a legitimate scenario, do you think that just clarifying this in the draft, together with the points Keith made, to be enough? > So it seems to me that there is never any ambiguity as to what the MRB > "should" do, and it's not difficult for the MRB to do the right thing. > The difficulty is to warn the implementers what the "offerless" cases > are and beware to implement them. > > Or am I perhaps overlooking something? > I think what Robert wanted to warn us about in his review, is that keeping silent on what to do in the MRB for offerless INVITEs could lead to trouble, and so just warning them without providing some guidance might not be enough. But if there is actually a standard behaviour implementors can follow, my opinion is that just by highlighting the possible scenarios and warning about them as you suggested might be the path to follow. > Dale > Thanks, Lorenzo > > On Tue, 2012-07-10 at 15:46 +0200, Lorenzo Miniero wrote: > > > The problem in giving a simple aswer to this point is that, > > considering the different scenarios that may occur in the IAMM > > mode, an offerless INVITE could confuse the MRB. Specifically, as > > you'll know if you read the draft, an INVITE reaching the MRB in > > IAMM mode can be any of the following: > > > > 1) an INVITE an AS sends to request a new session, or update an > > existing one, to the MRB, and negotiate a control channel with > > one of the chosen MS (in this case, the payload is multipart, > > containing both the Consumer request as XML and the SDP to > > negotiate the control channel); > > > > 2) an INVITE an AS sends to request a new session, or update an > > existing one, to the MRB, and attach a media session to a MS (in > > this case too, the payload is multipart, containing both the > > Consumer request as XML and the SDP to negotiate the media streams); > > > > 3) an INVITE an AS sends to just attach a media session to a MS > > (in this case, the payload only contains the SDP to negotiate the > > media streams). > > > > All of the above scenario are documented in the Examples sections, > > for an easier understanding of how they're conceived. > > > > The problem with offerless INVITEs is that the MRB might (WILL) be > > confused about what the AS is asking for. The easy way out might be > > just saying "the MRB doesn't support offerless INVITEs", but this > > could look overly restrictive. An alternative might be adding some > > text that explains that, whenever an MRB receives an offerless > > INVITE, it must assume it is related to the 3) case, that is, an AS > > will only originate such INVITEs when trying to attach a media > > dialog to a MS. > -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com