From cboulton@ubiquity.net Tue, 2 May 2006 10:50:35 +0100 From: "Chris Boulton" Date: Tue, 2 May 2006 10:50:35 +0100 To: Subject: [mediactrl] New version of Control Framework - draft-boulton-sip-control-framework-02 Message-ID: <45730E094814E44488F789C1CDED27AE03118A09@gbnewp0758m.eu.ubiquity.net> MIME-Version: 1.0 Content-Type: text/plain Hi all, A new version of the SIP Control Framework has been submitted. Until it appears in the archives it can be retrieved from the following links:- http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-02.txt http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-02.html Changes include a new mechanism for control channel and SIP dialog association + a detailed call flow. The authors would appreciate as much feedback as possible to help consolidate this version. Best Regards, Chris. Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you From diegob@mailvision.com Thu, 4 May 2006 08:09:55 +0100 From: Diego B Date: Thu, 4 May 2006 08:09:55 +0100 To: mediactrl@lists.ubiquitysoftware.com Subject: [mediactrl] PLEASE IGNORE [TESTING] Message-ID: <4459B660.2000103@mailvision.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary..5624.1163798078.multipart/alternative" --Boundary..5624.1163798078.multipart/alternative Content-Type: text/plain Content-Transfer-Encoding: 7bit Test -- -- Regards, Diego B (:-:) MailVision Ltd. End to End SIP Solutionstel:+97248508000;ext=102 mailto:diegob@mailvision.com sip:diegob@mailvision.net http://www.mailvision.com --Boundary..5624.1163798078.multipart/alternative Content-Type: application/octet-stream; name="gifgKCjf6sy2x.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="gifgKCjf6sy2x.gif" Content-Description: "" R0lGODlhjgBkAPcAAP///wAAAJ2dnf7+/qioqP39/cXFxfz8/Pn5+be3t2Zra9LT0zU4OFRVVenp 6X+AgPv7+yAgIPHx8ff39+Hh4ZGSkvX29tvc3OXl5Q4ODvj4+Orq6u3t7fLy8vb29vPz8/Dw8O7u 7u/v7+Li4uvr6/X19VWemt7e3tzc3A1OSuTk5ODg4AdZVOfn5/T09Ia1sgkxL0eUkPr6+mSmogpA PRJ5c9vb29fX13CuqiqGgA5dWN/f3+zs7N3d3ejo6AUfHprAvubm5rrX1tjY2BBsZhFxbB+AeziM h9nZ2QMDA9vi4qq+vczR0SJpZePj43ihn67Cwcnf3pawr6vAvmWTkKK2tQ9lYLbFxNbW1tTU1BJ2 cC9xbS1QTj98eDt4dLXJyBZ7dXOcmQYmJEF/e8/Pz2+YlqzNy0J/fG6dmlqNimaJhzJ0cHCZlzx6 dgYGBnGamNra2oSenLnOzZWzsmyVk6m9vEB+ej57d6e7uoCppqe8u1OGgz17dxp9d7LCwaq/vm2W lGKQjc7Y18PNzai9u3Sdm6S5uEOAfTl3c5q4t02FgtLS0tLZ2XukoT16dhN6dHylo+Dm5XyRkDZk YcbOzaa6ucDQzxZjXm2bmbDFxH2mpI2sqlWIhdDQ0LfBwK6+vZu0szN1cVeKh9PT07K/vl+Tjz16 d0mBfpGurRViXbDEw0dycF6Rjomopjt5ddXa2hRhXD57eMbQz3min77OzYKmpCRsaODt7C9ybsnZ 2EJ/e7TJx8TU00B9elyPjLHGxLnEw6C0s1iLiISjoSxva7zGxsfS0cfW1czMzJqysCRrZ7LGxTx5 diRsZ8rPz9Te3WmSkLPHxqW6uMHMyz99edPd3FGJhsPT0pqurUF+e12QjaO9u6a/vrnIx6S4t+Tp 6Z6zsoaqqJ64ttXg35+5uJi3tdHW1XegnbXEw/X6+dro6Ed/fOzy8rvPzsTJyZ+0sujt7a28u7fH xtjd3dne3tvg4LfMynGfnL3My7/JyH6ioGuUkmmWlBViXjF0cOPo6CH5BAAAAAAALAAAAACOAGQA AAj/AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHapyAQEKAh0QEPCAwQKJRpE6jErUIoIETSNwKLCggoIMAQxY QFBgAMOrWbeWTYiWgdYCa2taiBJFiBAzZgTOrXsXCMSuDQIEICAhgYIIgjFg4CvEr8BbdBsLAQBY MGEJZBFWHiwBc4GaUYDgmGGizyoECEKPNlFEDWq4DL0iDiBggYAGYCMYMADkxYwjKV6HnpEjxQIE sgXXpoAZYXLaC5gjqCkER4wcRnRMcsDBjPUcNVJI/+LueaECBoIHJ6gQOAADAglemMhhBQZ50cUZ OHDQAL3lBAZgYIFZBp2XHnwBDkgTEDMYUQMRNHCxwALyOVjfAxNiIMFnCrXnHgEEPNBeAwIQYF0R KcAwIYUx1KfAhP59CN8FGx7k4Xsz1ihTOvL18SANCiQQXwxg1HAhgAtwMJ1CAggWgQBQGhiAAiXO EAOKXMBnxgvA/SCAkA84CeWXC+hYUJMBPAllAmVyGNMtL8RQgxYQUolfDTXoAMMDZDqwpEJGGbCU AIcJxicBcWqRAhcligYGDTAsRcBuAghaYgI0ullQoJJiaiZMUeBwRBF00rCKABXW8IgOYhy6gJ+v Kv9kAQYGJLBUobSVKF94jCJqAhEwUFmiARRcUCuCAmIQa0GzHguggAMoe0FDEpQJkndGFJEDESms EoeoPq76QwVkdnUeAbZV0BRSRnnVAKVfBZDBmrsuqusROowLZQXqKvDubhfYJiIDDSwwwADt+rub ATQK7O97cbX7wAMWGCBiBgvEtREQJtCZbQpqxDFDDUf08UgK+gLolVsRPOCvGwFYYEGI6DEQMHtJ uEevCbyiioMRkErqcs0BU2CuWzBjPHNT7hXNgQErIx3WWAWE2B+VIiKmgARUa2RBnFbocIQWOqiB RgxEzAdGCgyQu955OWcQQQS5KcaeYA1ccIGIeO//HN4kqM4ArLAE+Iu33ubCnJ4CF2BwdwB5Nw51 AxEojjcFHFjAHt0RMOCWYDZLR+BF6ryQgw6rHJGtGqXpgMYRjzIwppSCJaE4A7sxPWXu/pEIn3yK TvJtDPmS+6WUCuwWImJypymkxf4lb4C5YKWX3vQONJVzAElksD0DAGaaUXVrqxFDyUecPsnZj0RY YtZOer99A7f69wCIUh7KG2sgf5tD0CUqnP3gw7cAVMAwhxKgoeCzPCfVTjAV2A3tHgg5+LzqTxYx wwyKQAPzxcAIH2Ndx4BUIsN9iHLVI9FzyLXCYXGMbGZjTbAkdZvZkEuBaRpTiQhlwxI9LgIEcEv1 /xSAv9kQLAMpHBYGMFgR+ViBBnEwwQfzRANJoEGGVGKP/ZhCOcFkEVf7AmOJFsCxB10RX/r6Ug2V U6IuCiYD9xNS4WYDJZrhzWpDvBUds+JFJTJxIuyIk54IcMWP0UAApBkcF+m4SAhyMTf7wk0OyVQh LcSASACcFHsgeTzrySuCtpGkmnhoqEeycZM5hJ8Bh+UnjISqODQwkQmMACHAWelCjRyMALwClnlx EXRQKqDsyGQGtRmBPmIgnMXaM0w2echJDHvcMEkZAD4V0JfCZEq8fMmmVl6EfBGSJRhcJAkrsUoS hJLkMKUZzN69z50zEgJxHgEGRaWRTVLyHaayl/8BN2yPTbrznSrbCUymuFNEOWtmkjRFEQYVIViI jIGixCAJkaGxftUjqM4IFb0odXRSFJAneH40zEktAHnDSoAElMKA6sEHpXiEoLpmQyKO9jGbX6LR 6JpoAlxaiYMwEID/UObR6jFAAbhSIa74RE39YUCkeLKCGGo6KQMs9VITE1QD4hal2RyqKUb11/bC 6FWbQu5SF7AARuBEPDGQyzr1aUAFRGYEtkGpP9XLgNSquUtcLeU5kjKAA6BqT6ayyTCzoeF5GtAf YALWhy3l3tyS2NfErqyUIFXrRV6JsqVYh1UPqIBvHsUog1bPk6vk5SRVqyY2cQCqEGrbsChQOE7/ Dg2JeSWXyzgpJLqh1pd9haTLejipJWIECPiCQWlZQwMvIfJ0yt3hadNkva4WFFcK7c4RiKCDFEz1 hq96gBGDidop6bGgzvwtU+cITNrV8YIYKY4YflDT+vygtBD6wQ+oNKn2ZIB2ajptTQW8JhoBIUXz /UFoySQBAqsxRnAclIMxdYFnMoCpXyJwjFq70IwgwAFGudSEErCm6VlqUsY6oA51yKYFnHh6xgps WgHw4RDfkFgDQgCtZIwBrGB4WBN6MY0kALXQ8quODHMABU4MoFqtqU0eBrGtwudiEE3PxVNeAAYc EGMQednKCzDWlBkmZmSpFQEcWICtRNxKHTuL/1hcFpSkLFisNwtoVmoeFJg5IAFajRnLVqaAgjCC ZhfvRstGOzQFEh0+PoO4VguDtJaVBekLOIDSjZ5OASQg5iYz5zOFrrSjsfy8V60UywxT0qYZ/bwL ZM4Cj0ZSwCTtTYwUANbFwgCfV7poB3RGyY3LHAJgrbfGYaBYFPA1r4P961xn7jMFQDMG9EYBDSHA LLcGtq7HYgEOTDvMmOO2tp89AASsNGBhtjZccN047lz6Asm2AEMrMoBoy4xqw5YZavKt77JEuzP3 vve++U0W1Ag8Lva2ANe6BoB6E9zfw+4M18gCl4ebxeES59paHC5wg/d7py052MEIInKRk+RgcP8B uULqrbGToPwAMI/5AeBCc7jIfOYitzkEdh7znUMA5mXJ+c2BXvMC3DzoVSlIvQ8AAQRoQAMTmMDT nz5wqEdd6jLoudMn4AEPXL0d7YDHBBDwc5vL4OlXn/rAEXB1rONc5UIZwAFkcIhQnOHuHbAHCyDR gQ8cwh5+D8UYQlGKb3hAAzKQwT3qfokxjIEXvAgFJiARikS4YAIygIAM2nGJu+siERJggS4k8AFN aKL0thi8NY5RAg1AoOVEKQAEJnCGaGxgPw5YRi/WUA8S2OEXvs+EDzYwh1BI4PITKEEHdtGLFrTA Acr4xQY2oIRUMOIDXp+AHMYwfQf4wAEsSIP/KjYwi1mQYBZP+L4llFENF7ge9kI5gAY+YIdaLOH+ K5jCHTYRhhXwoQ4UcAd1sAMU4ARpMAci8AEu0AEcAAWxcAInIA+4UIBOoAL8EA4h0HfL5w9/8Ad1 MAg7wALT4Ag7UAhhQAGFUAgnUICo4Ash4H4HAHdAcQATAALUIAxvEAZv0AOE0AY3sAXO4ApVgARt YAg2cAIrUAjnQAIg0AEgwANQcAc2gAJ44AgruGhKuAEiIAIhsAxNEAY6WAkowAJYwAlVUAZlgARv 8AZHmH9dsAEgUAIyMG9BAQElEAJdUAlDgAR7WAmusAjDQAeIkAyj4AVVcAMo0ANUUAs+EAIS/yAC UHgHcAAHfrAFKACBO7CILcADHEACqsAHe3gDNzAELNAJnoAIdLAPiwAIZXADNtADoKAILRACH6AB dAgUdsgBXWAIWCCKQyANrtAJZEAMxIANZIAI74AFcIAOTfAKLcBnIBACmRALNlCNTYAHEGgOsCAL QUACPEACUGAKoogFvcgCZEAGe4AI0EAGdAAIWYAEC4ALSxAEPFCLt/gTdoiHosAGa2gDetAGowCI LIANnYAIe1AGooALVzACjdgBThgNXbADEnkFuEAFYYALmzACm9iJqtAE/MgGRsgCAekJLLCOgOAF ZUAFGEkBQcAB9ph0AHAAHgACtLAEhFAHhP+wAq8gD3CABDcQDO6QBZ9QBdJwBStQbSQgASVQAi4Q CZYQBEGAASowAlMwBYwwAhighVyoBFBwk3owCCuwBHx4A/HgCVlQDFVgCHpwlCrgACJQApmRdPLX ASQwlSMwAirQAkGwaCuAAkiAAijwihSAlW6JfB7wASJAAiRwe3qpAiqwZRn4AR0QAj5wl4v2mHzZ A0gwhYm4AnjpAy45ARAggz9RADLgARJAAri3ARzQidMXlVGpAkHwfCQgAu6XeGznAhLQAY/IATww fSRAi153mCFwe9/njd3XAo8plRjwfBuQgR6AADGIESVHmg1XchshdwjgAbwpAU3oAi7wAZL/GY1c yAEhIAJN2Ho/x3RnF3UesIAi4JshAAIuMJy6GQIhYJ5NuJvRqJiLuQE8wAPziX1kl3LViXJGx3Q+ x3M353NEV3QJ6qBIdxFLJwNc13VS53Ro13VLuZReV6Avt3MykJvP8AXXMKDgGZ7RiJ8i0AEduoBf sAuR0JrneQ1fMA71qQEIkHlDt3OowXUdWgLZN3W50A5KEHVTp6NVpwTtkAtj93MjR6FwsaDrCXQ9 p3k8Z6A5Z3QQoAGlMAaNwArNEAKYcAmhwAsiwAJ2sKaR4KJdlwu2gAmN0AzlEAKRkA2s0AhjgAmk dwhyIHUakAd5gHZ+igZnEAr94HjlgKiY/9AB/3AGpQAJuoAGu6kJLGAPfccC4vmlkFAKtgCXr2ed D3GgpFqqcFdvMpALoaCaPkALDhB8DrABLNCc4aAItMiU1sANt+cAtEAC2jAL07cBvTAHJJANX9B3 LmB64vkBZ/AFnZgJ1OB8LZAJvRCrvxqsw0p+vkANr8oCG2AJa+B8DmAJbymdosoS8jcO/UAOfOmZ XbAER8kCrwgKd9ACLSoBrOALxkABR+kEqfAKjqkC4qAII9AFUPCcItAIjdCaPGAHqoABI7AEpgCB J7AEfHCU1oeXAqsIKBgGokAIFMACK2AMqQAKK9iWIOABr2cTcjcBHbANscACuKAPKLADfP9QCVPI AlUgBVsACirAA1uoBGnQBLBwCtNwAiyAhItWB46AAqawBG1JfrPgAz7QAgY7Ajvwj4nIg46Qsz1w lBSwBF3LBmUADF5Aiq6YDMwgs7UQBOV6jyFHgyDgAydgA37QBKQAB21wiKRIB2VACjbgBAJanE6A AkxQBqcwBLDABD1wAjuQDKdwA8xgCCcgm+dwDk7gBCMQC0uwAz2AB20AmCigB8wwBIrLBDW7A6Bw ClgACHSAjuBQiuSYBVhwt91AArV4ACxLg9VADyfgk1sQD1jgCsFAu+aYBUOAAiownyJgCU5gA0OA CuuQBZxQBq94Am3QClhgiDbgmaiQBiv/IJFNMAgQ+I89cL6kK4rVe4TYq72uiwykgAgsgAzAQAmL MAo/eAU+AAITMJ00IXcacAzKkAZvwAyBkAWt0AR7UAw3wAKLMAQ9kGwayAr+EAZUELxYwASuIAph wAdUgATDywk5iAoBKAxhYAphsANH+Qd3sGiUMLStMAQazMEeDAc3UAaAQAadsAfm+AlNUL3MQAU7 sL/9e64poZ0uEAJQ8AeDAAdD4Ad44A2oiwdwUG1w2HUuAAKCMAV14Jd/iQJXsASysAOB6QeGgAdL IA93KQ91QAmDiQFBQA/44HzzsMTocL4oIA9/IAsrcAIoMA35IIrOUAXviAKVgAfkOwIb/9ABRVwT qFoCIuADKkABPXCJnruCI0ABPsADcfijdAmxO+C4izYCFZjJK9DHnlmBdomXQfCqAaqYDqCcd5nJ Gqu5pXzKfowCp6zCb1yPGuC/NGF0GuACiekAsNkCzRmrWkigMLedEvCbVavMwYp7sfx8yrwfG0AC HCACu8mbIBCf/3l7wQqc35icrex92MwDHeABc3gT9dalC/iIW8iF3Nx3T+pvB7CdkumdDunN3gkC AL2FAA0C/9yEH1ACV+cBTLnPEkfQEqeAkjme3PzPDvkBmAfM/2t07anQQqrQXqejZZdzTdd2U9d2 Cc2hwzmkZCeiI2p1Jp12Vdd2GCp1IXDtziynoFRapUF3cUvnoDLn0zid0w9Kcz13pQxacz+9oG+3 E6ZanQfR1FB9oAMR1VSNnTB51Vid1Vq91Vzd1V791WAd1mI91mRd1mZ91mid1mq91mzd1m791nAd 13I913Rd13Z913id13q913y9EwEBADs= --Boundary..5624.1163798078.multipart/alternative-- From fluffy@cisco.com Sun, 7 May 2006 21:00:16 +0100 From: Cullen Jennings Date: Sun, 7 May 2006 21:00:16 +0100 To: MixerControl Subject: [mediactrl] How to get this work into a WG Message-ID: <89C69C42-F8E9-4290-82E9-A9BD207B62F4@cisco.com> MIME-Version: 1.0 Content-Type: text/plain A long time ago, we had talked about asking the SpeachSC chairs if that WG might take on this work. Is there still interest in that? With my AD hat on, I have no idea what is the best way to do this yet but I am looking for input on what the next logical steps are with all the work that has been happing here. Thanks, Cullen PS - A short summary of the status of where we are, what we have, and where various parties might want to eventually get to might be really helpful for me. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From cboulton@ubiquity.net Mon, 8 May 2006 10:34:57 +0100 From: "Chris Boulton" Date: Mon, 8 May 2006 10:34:57 +0100 To: "Cullen Jennings" Subject: RE: [mediactrl] How to get this work into a WG Message-ID: <45730E094814E44488F789C1CDED27AE03118A18@gbnewp0758m.eu.ubiquity.net> MIME-Version: 1.0 Content-Type: text/plain Hi Cullen (donning AD cap), We are still very much actively discussing this work and have met at every IETF since Paris (I think) - including a Beer BOF and a Meal BOF :-). A long time ago, we had talked about asking the SpeachSC chairs if that WG might take on this work. Is there still interest in that? Very much so - we have been discussing this regularly and I think we had hoped (Eric will confirm but I know he is snowed under at the moment) to move towards IETF working group towards the end of this year/maybe early next. PS - A short summary of the status of where we are, what we have, and where various parties might want to eventually get to might be really helpful for me. We are at the point where we have a Control Framework which has been discussed at length at previous meetings (http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework -02.txt) which aims to fulfill the detail outlined in the Requirements document (http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01 .txt). This is an agnostic approach that is not 'Media Server' specific and aims to provide a core connection management system using SIP. The authors of the Framework have also created a number of extensions to the Control Framework that provides modules for achieving various levels of Media Server Control. - First extension provides simple IVR functionality (http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-0 1.txt). - There is an extension to the SIMPLE IVR functionality for the purpose of using VXML (http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-pack age-00.txt). - This extensions provides conferencing capabilities (http://www.ietf.org/internet-drafts/draft-boulton-conference-control-pa ckage-00.txt). If you need anymore information then give me a shout. Best Regards, Chris. -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Cullen Jennings Sent: 07 May 2006 16:11 To: MixerControl Subject: [mediactrl] How to get this work into a WG A long time ago, we had talked about asking the SpeachSC chairs if that WG might take on this work. Is there still interest in that? With my AD hat on, I have no idea what is the best way to do this yet but I am looking for input on what the next logical steps are with all the work that has been happing here. Thanks, Cullen PS - A short summary of the status of where we are, what we have, and where various parties might want to eventually get to might be really helpful for me. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank you. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From asaleem@convedia.com Mon, 8 May 2006 21:00:20 +0100 From: "Adnan Saleem" Date: Mon, 8 May 2006 21:00:20 +0100 To: "Chris Boulton" Subject: RE: [mediactrl] How to get this work into a WG In-Reply-To: <45730E094814E44488F789C1CDED27AE03118A18@gbnewp0758m.eu.ubiquity.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cullen,I want to point out that we have rough consensus (imho) on the "control framework" ID (http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt), from an architectural perspective and the direction this is going. However, there is no consensus on the remaining IDs identified below. Convedia in particular objects to the "extension" IDs listed below, covering IVR and conference control. - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt). - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt). - (http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt). The above new IDs essentially provide a subset and duplication of the what MSML, and MSCML to a good extent,have already provided for years. Garland / Adnan -----Original Message-----From: owner-mediactrl@lists.ubiquitysoftware.com[mailto:owner-mediactrl@lists.ubiquitysoftware.com]On Behalf Of ChrisBoultonSent: May 8, 2006 2:36 AMTo: Cullen Jennings; MixerControlCc: Burger, EricSubject: RE: [mediactrl] How to get this work into a WGHi Cullen (donning AD cap),We are still very much actively discussing this work and have met atevery IETF since Paris (I think) - including a Beer BOF and a Meal BOF:-). A long time ago, we had talked about asking the SpeachSC chairsif that WG might take on this work. Is there still interest inthat?Very much so - we have been discussing this regularly and I think we hadhoped (Eric will confirm but I know he is snowed under at the moment) tomove towards IETF working group towards the end of this year/maybe earlynext. PS - A short summary of the status of where we are, what wehave, and where various parties might want to eventually get to might bereally helpful for me.We are at the point where we have a Control Framework which has beendiscussed at length at previous meetings(http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt) which aims to fulfill the detail outlined in the Requirementsdocument(http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01.txt). This is an agnostic approach that is not 'Media Server' specificand aims to provide a core connection management system using SIP.The authors of the Framework have also created a number of extensions tothe Control Framework that provides modules for achieving various levelsof Media Server Control.- First extension provides simple IVR functionality(http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt).- There is an extension to the SIMPLE IVR functionality for the purposeof using VXML(http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt).- This extensions provides conferencing capabilities(http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt).If you need anymore information then give me a shout.Best Regards,Chris.-----Original Message-----From: owner-mediactrl@lists.ubiquitysoftware.com[mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of CullenJenningsSent: 07 May 2006 16:11To: MixerControlSubject: [mediactrl] How to get this work into a WGA long time ago, we had talked about asking the SpeachSC chairs ifthat WG might take on this work. Is there still interest in that?With my AD hat on, I have no idea what is the best way to do this yetbut I am looking for input on what the next logical steps are withall the work that has been happing here.Thanks, CullenPS - A short summary of the status of where we are, what we have, andwhere various parties might want to eventually get to might be reallyhelpful for me.--------------------------Ubiquity Software does not control or endorse the content, messages orinformation found in this mail list and it specifically disclaims anyliability with regard to these communications.Ubiquity Software reserves the right the restrict access to anycommunications in violation of the Terms and Conditions of Use for thiswebsite or as otherwise deemed improper.Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank you.--------------------------Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From cboulton@ubiquity.net Tue, 9 May 2006 13:41:58 +0100 From: "Chris Boulton" Date: Tue, 9 May 2006 13:41:58 +0100 To: "Adnan Saleem" Subject: RE: [mediactrl] How to get this work into a WG Message-ID: <45730E094814E44488F789C1CDED27AE03118A20@gbnewp0758m.eu.ubiquity.net> MIME-Version: 1.0 Content-Type: text/plain   Cullen, I want to point out that we have rough consensus (imho) on the "control framework" ID (http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt), from an architectural perspective and the direction this is going. [Chris Boulton] That’s really good to hear. However, there is no consensus on the remaining IDs identified below.   [Chris Boulton] I’m not sure consensus was at all proposed – certainly not by me.  That’s jumping the gun a little.  I was just pointing out that we have current examples of how Control Packages are written in-line with the framework.   Convedia in particular objects to the "extension" IDs listed below, covering IVR and conference control.         - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt).       - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt).       - (http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt).   The above new IDs essentially provide a subset and duplication of the what MSML, and MSCML to a good extent, have already provided for years.   [Chris Boulton] Totally understand your position.  All I will say is that:-   -          yes, you are correct in that this does provide duplication of MSML and MSCML.  The intention was to use and build on the experiences gained from such languages to provide a solution that architecturally fits with the new Control Framework. -          Yes it provides subsets of functionality.  This again was the intention to provide a modular approach.  We are thinking (and received quite a large amount of feedback from media control group) from the agnostic point of view that not everyone wants to implement a large scripting language for simple IVR interactions.  It should be possible to select exactly what you need to fit your requirements.   If you have got any more detail on your technical objections I think it would be great to have some discussion.   Best Regards,   Chris.       Garland / Adnan -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com]On Behalf Of Chris Boulton Sent: May 8, 2006 2:36 AM To: Cullen Jennings; MixerControl Cc: Burger, Eric Subject: RE: [mediactrl] How to get this work into a WG Hi Cullen (donning AD cap), We are still very much actively discussing this work and have met at every IETF since Paris (I think) - including a Beer BOF and a Meal BOF :-).         A long time ago, we had talked about asking the SpeachSC chairs if          that WG might take on this work. Is there still interest in that?          Very much so - we have been discussing this regularly and I think we had hoped (Eric will confirm but I know he is snowed under at the moment) to move towards IETF working group towards the end of this year/maybe early next.         PS - A short summary of the status of where we are, what we have, and          where various parties might want to eventually get to might be really          helpful for me. We are at the point where we have a Control Framework which has been discussed at length at previous meetings (http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework -02.txt) which aims to fulfill the detail outlined in the Requirements document (http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01 .txt).  This is an agnostic approach that is not 'Media Server' specific and aims to provide a core connection management system using SIP. The authors of the Framework have also created a number of extensions to the Control Framework that provides modules for achieving various levels of Media Server Control. - First extension provides simple IVR functionality (http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-0 1.txt). - There is an extension to the SIMPLE IVR functionality for the purpose of using VXML (http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-pack age-00.txt). - This extensions provides conferencing capabilities (http://www.ietf.org/internet-drafts/draft-boulton-conference-control-pa ckage-00.txt). If you need anymore information then give me a shout. Best Regards, Chris. -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Cullen Jennings Sent: 07 May 2006 16:11 To: MixerControl Subject: [mediactrl] How to get this work into a WG A long time ago, we had talked about asking the SpeachSC chairs if  that WG might take on this work. Is there still interest in that?  With my AD hat on, I have no idea what is the best way to do this yet  but I am looking for input on what the next logical steps are with  all the work that has been happing here. Thanks, Cullen PS - A short summary of the status of where we are, what we have, and  where various parties might want to eventually get to might be really  helpful for me. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From gsharratt@convedia.com Wed, 10 May 2006 14:40:08 +0100 From: "Garland Sharratt" Date: Wed, 10 May 2006 14:40:08 +0100 To: "'Tom-PT Taylor'" Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft In-Reply-To: <43F3558D.2080207@nortel.com> Message-ID: <00ab01c67437$8278b590$b474a7d9@wwvnu073> MIME-Version: 1.0 Content-Type: text/plain Tom, Gary, a few belated comments on your two emails together: 1. Dumb media server vs. smart media server. I don't agree that an H.248 MS is dumb and a SIP MS is smarter. If you look at an H.248 media server and a SIP media server, there is no real difference between them. Both do the same job, media processing. Yes, the control interface looks different, but they are both doing playing, recording, DTMF collection, conference mixing, etc. Yes, pure VoiceXML (pure = no call control, e.g., "transfer" element) is often used with SIP media servers and not with H.248 media servers, but this doesn't change the role or function of a media server, which is to perform media processing under the total control of an external application. 2. Inline MRB vs. Query MRB I don't really have an axe to grind on either side but based on what I know at this time I don't agree that the Query MRB is better than the Inline MRB. The Query MRB needs new protocols and interfaces defined, whereas the Inline MRB doesn't. For this reason the Inline MRB seems more elegant to me. (Incidentally, moving to a TCP channel instead of SIP INFO, see below, removes one of the objections to the Inline MRB, that in order for it to have visibility of BYE messages (which is necessary for resource control purposes) it needs to also flow through all the SIP INFO messages, which is inefficient.) The last time I looked at the MSF has only the Inline MRB, not the Query MRB. Tom, has this really changed? 3. Separate TCP control channel negotiated by SIP I think that for efficiently reasons such a TCP channel needs to be: (a) long lived, and (b) used to control multiple RTP streams. For example, one very viable way to use these channels would be to have *one* such long-live TCP channel set up between each combination of AS and MS, at restart time. The AS would use the one TCP channel to control all its RTP streams on that MS. So if there were N ASs and M MSs, there would be N x M control channels, assuming all ASs had access to all MSs. Perhaps there could also be a time-out mechanism that might tear down a TCP channel if it hadn't been used in an hour, if this was valuable for some reason. And of course if a particular MS isn't useable by a particular AS, there would be no TCP channel. I don't see a conflict between having these long-lived TCP channels and the presence of the MRB. Comments welcome. Garland -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Tom-PT Taylor Sent: Wednesday, February 15, 2006 08:24 To: gamunson@att.com Cc: mediactrl@lists.ubiquitysoftware.com Subject: Re: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft The MSF has taken the Media Resource Broker into its architecture, with two different SIP interfaces. The first requests media resources of a specific type, with a URI to a media server as a return result. The second has the MRB acting as a proxy (optional) between the client and the Media Server. I'll confess that in the short term the MSF is using SIP INFO transport. (Strong influence by specific vendors here.) However, if this architecture were to persist but with the SIP setting up separate control channels, I find it hard to picture those channels remaining up once the individual call is completed. Control channels persisting for longer than the duration of an individual usage (call) imply a tighter relationship between the AS and the MS than I think compatible with the role of a media resource broker. gamunson@att.com wrote: > Hi folks, > > I'll throw in my views here on some topics that have been in the recent emails, say from February 4 onward. > > 1) It seems that there are two basic concepts of what is meant by Media Server > a) the really dumb kind (a la IMS MRFP) > b) the one that can be smarter (a la IMS MRFC + MRFP) > > * I believe that the AS-MS protocol that the Mediactrl BoF should be fundamentally addressing is (b); but it should be extensible to allow finer control granularity. In a practical architecture, it should be possible for the AS to tell the MS to do routine tricks on its own (e.g., roll over, fetch a stick, bite the mailman) without the AS controlling every itsy-bitsy step. So, yes, something like VXML on the MS makes perfectly good sense. On the other hand, to preclude a potentially finer level of control for some applications seems unwise. > > 2) While I used above the representation of the 'smarter' MS as IMS MRFC +MRFP, as have others, it has a flaw. The IMS MRFC consists of two functions. One is the MRFP control function, which is okay to be part of the MS. But the MRFC also has a media resource *assignment* function. At the network level, that assignment function cannot be part of a Media Server. (Local resource assignment among a cluster of servers is a different matter.) [One other side note - in an earlier mail, the AS-MS control interface was referred to, in IMS terms, as the Mr interface. On the MS side that's fine. However, in the IMS pictures I have seen, the Mr interface has as its other endpoint the S-CSCF, not the AS.] > > * That MS assignment function is related to topics that came in multiple earlier emails about MS discovery, and whether we're assuming a static connection between an AS and MS, and whether the resource management function lives 'below S-CSCF'. > One of the scenarios we need to allow for is a many-to-many AS-MS relationship where the MS resources are a shared pool across many different services residing on many ASes, with tons of traffic with variations in volumes, some predictable, some not, and where MS resources are not infinite and the MS boxes don't all have the same size or capability set, and services don't all have the same priority, etc.. In such as case, we want to > - Allow for a network-level MS assignment function (referred to as a Media Server Resource Broker or just Media Resource Broker); one model of the way MSRB works (e.g., recent work in the ATIS-PTSC and in the ITU-T NGN based on a set of requirements), is for an AS to query the MSRB when it wants MS resources. The MSRB responds to the AS with identified MS resources that it allocates to that AS. When the AS is done with its assigned MS resources, it releases them back to the MSRB. In that model, the MSRB doesn't have to live below, and can be unrelated to, S-CSCF. There is another model of MRB that would live below S-CSCF, but it doesn't support as broad a set of needs as the AS-MSRB model described here. > - Allow for more than just a static AS-MS control channel situation. > In short, while recognizing the topics of MS 'discovery' and/or MS resource management/allocation as important, they should remain outside the scope of the BoF AS-MS protocol effort, and we should allow the AS-MS control channel connection situation to be fluid. > > Next, a couple comments for Chris & co on the "A Control Framework for SIP" draft, staying out of the Control Package fray, and questions about which protocol might be a chicken or an egg :-) -- > > A) I resonate strongly with the option of having a separate AS-MS control channel set up by SIP, and TCP for transport is good. Here are some additional points to potentially clarify: > a) *Must* the control channel be established before a call leg is brought to the Media Server? The Control Framework for SIP draft seems to only talk about setting up the control channel before a call leg is brought to the MS. It might be useful to allow for both. > b) Can a single control channel be used to control multiple calls at the MS (using the same control package)? For example, 10 simultaneous IVR sessions? I believe the intent is to allow that, but I didn't see words to that effect. > c) Can different control packages be run over the same control channel? For example, one for simultaneous calls for IVR and another for conferences? I don't have a strong feeling about that one, but it should be clarified. > > B) The 'Control Framework for SIP' draft places the Control Package-related information at the SIP-level (the Control Packages header etc.) in SIP messages. An alternative would be to place that information in an SDP or SDP-like description as payload, similar to establishing media sessions using SIP. I wonder whether there was any discussion around the pros and cons of doing the latter? [I do realize media channels and control channels are not the same thing]. Take this question as one that is a mild push-back, and perhaps based on ignorance as much as anything. > > Cheers, > > Gary Munson > > > > > -------------------------- > Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. > Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. > > -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From gamunson@att.com Wed, 10 May 2006 19:15:09 +0100 From: Date: Wed, 10 May 2006 19:15:09 +0100 To: Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E1026F7B9A@NJFPSRVEXG2KCL.research.att.com> MIME-Version: 1.0 Content-Type: text/plain Garland, Regarding your Comment 2 below, the Query MRB approach addresses a broader set of needs than the Inline MRB. (Again, conferencing examples, the AS and not the MRB really knowing when the MS resources can be released, or the need to control really large conferences that span multiple MS devices, or the ability to alter a prior request or negotiate a resource request). I see Query MRB and Inline MRB as alternatives that one could implement depending on what the particular needs are. But posing the Inline MRB as the only solution, implying it meets all needs, is insufficient. Regarding Comment 3, I agree on both points: - to allow the TCP connection to be long-lived would be desirable, at least as an option - there is no conflict with MRB, whether the Query MRB or Inline MRB flavor [Didn't have anything useful to say wrt your Comment 1. Points noted. :-) ] Cheers, Gary -----Original Message----- From: Garland Sharratt [mailto:gsharratt@convedia.com] Sent: Wednesday, May 10, 2006 9:42 AM To: 'Tom-PT Taylor'; Munson,Gary A (Gary) Cc: mediactrl@lists.ubiquitysoftware.com Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft Tom, Gary, a few belated comments on your two emails together: 1. Dumb media server vs. smart media server. I don't agree that an H.248 MS is dumb and a SIP MS is smarter. If you look at an H.248 media server and a SIP media server, there is no real difference between them. Both do the same job, media processing. Yes, the control interface looks different, but they are both doing playing, recording, DTMF collection, conference mixing, etc. Yes, pure VoiceXML (pure = no call control, e.g., "transfer" element) is often used with SIP media servers and not with H.248 media servers, but this doesn't change the role or function of a media server, which is to perform media processing under the total control of an external application. 2. Inline MRB vs. Query MRB I don't really have an axe to grind on either side but based on what I know at this time I don't agree that the Query MRB is better than the Inline MRB. The Query MRB needs new protocols and interfaces defined, whereas the Inline MRB doesn't. For this reason the Inline MRB seems more elegant to me. (Incidentally, moving to a TCP channel instead of SIP INFO, see below, removes one of the objections to the Inline MRB, that in order for it to have visibility of BYE messages (which is necessary for resource control purposes) it needs to also flow through all the SIP INFO messages, which is inefficient.) The last time I looked at the MSF has only the Inline MRB, not the Query MRB. Tom, has this really changed? 3. Separate TCP control channel negotiated by SIP I think that for efficiently reasons such a TCP channel needs to be: (a) long lived, and (b) used to control multiple RTP streams. For example, one very viable way to use these channels would be to have *one* such long-live TCP channel set up between each combination of AS and MS, at restart time. The AS would use the one TCP channel to control all its RTP streams on that MS. So if there were N ASs and M MSs, there would be N x M control channels, assuming all ASs had access to all MSs. Perhaps there could also be a time-out mechanism that might tear down a TCP channel if it hadn't been used in an hour, if this was valuable for some reason. And of course if a particular MS isn't useable by a particular AS, there would be no TCP channel. I don't see a conflict between having these long-lived TCP channels and the presence of the MRB. Comments welcome. Garland -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Tom-PT Taylor Sent: Wednesday, February 15, 2006 08:24 To: gamunson@att.com Cc: mediactrl@lists.ubiquitysoftware.com Subject: Re: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft The MSF has taken the Media Resource Broker into its architecture, with two different SIP interfaces. The first requests media resources of a specific type, with a URI to a media server as a return result. The second has the MRB acting as a proxy (optional) between the client and the Media Server. I'll confess that in the short term the MSF is using SIP INFO transport. (Strong influence by specific vendors here.) However, if this architecture were to persist but with the SIP setting up separate control channels, I find it hard to picture those channels remaining up once the individual call is completed. Control channels persisting for longer than the duration of an individual usage (call) imply a tighter relationship between the AS and the MS than I think compatible with the role of a media resource broker. gamunson@att.com wrote: > Hi folks, > > I'll throw in my views here on some topics that have been in the recent emails, say from February 4 onward. > > 1) It seems that there are two basic concepts of what is meant by Media Server > a) the really dumb kind (a la IMS MRFP) > b) the one that can be smarter (a la IMS MRFC + MRFP) > > * I believe that the AS-MS protocol that the Mediactrl BoF should be fundamentally addressing is (b); but it should be extensible to allow finer control granularity. In a practical architecture, it should be possible for the AS to tell the MS to do routine tricks on its own (e.g., roll over, fetch a stick, bite the mailman) without the AS controlling every itsy-bitsy step. So, yes, something like VXML on the MS makes perfectly good sense. On the other hand, to preclude a potentially finer level of control for some applications seems unwise. > > 2) While I used above the representation of the 'smarter' MS as IMS MRFC +MRFP, as have others, it has a flaw. The IMS MRFC consists of two functions. One is the MRFP control function, which is okay to be part of the MS. But the MRFC also has a media resource *assignment* function. At the network level, that assignment function cannot be part of a Media Server. (Local resource assignment among a cluster of servers is a different matter.) [One other side note - in an earlier mail, the AS-MS control interface was referred to, in IMS terms, as the Mr interface. On the MS side that's fine. However, in the IMS pictures I have seen, the Mr interface has as its other endpoint the S-CSCF, not the AS.] > > * That MS assignment function is related to topics that came in multiple earlier emails about MS discovery, and whether we're assuming a static connection between an AS and MS, and whether the resource management function lives 'below S-CSCF'. > One of the scenarios we need to allow for is a many-to-many AS-MS relationship where the MS resources are a shared pool across many different services residing on many ASes, with tons of traffic with variations in volumes, some predictable, some not, and where MS resources are not infinite and the MS boxes don't all have the same size or capability set, and services don't all have the same priority, etc.. In such as case, we want to > - Allow for a network-level MS assignment function (referred to as a Media Server Resource Broker or just Media Resource Broker); one model of the way MSRB works (e.g., recent work in the ATIS-PTSC and in the ITU-T NGN based on a set of requirements), is for an AS to query the MSRB when it wants MS resources. The MSRB responds to the AS with identified MS resources that it allocates to that AS. When the AS is done with its assigned MS resources, it releases them back to the MSRB. In that model, the MSRB doesn't have to live below, and can be unrelated to, S-CSCF. There is another model of MRB that would live below S-CSCF, but it doesn't support as broad a set of needs as the AS-MSRB model described here. > - Allow for more than just a static AS-MS control channel situation. > In short, while recognizing the topics of MS 'discovery' and/or MS resource management/allocation as important, they should remain outside the scope of the BoF AS-MS protocol effort, and we should allow the AS-MS control channel connection situation to be fluid. > > Next, a couple comments for Chris & co on the "A Control Framework for SIP" draft, staying out of the Control Package fray, and questions about which protocol might be a chicken or an egg :-) -- > > A) I resonate strongly with the option of having a separate AS-MS control channel set up by SIP, and TCP for transport is good. Here are some additional points to potentially clarify: > a) *Must* the control channel be established before a call leg is brought to the Media Server? The Control Framework for SIP draft seems to only talk about setting up the control channel before a call leg is brought to the MS. It might be useful to allow for both. > b) Can a single control channel be used to control multiple calls at the MS (using the same control package)? For example, 10 simultaneous IVR sessions? I believe the intent is to allow that, but I didn't see words to that effect. > c) Can different control packages be run over the same control channel? For example, one for simultaneous calls for IVR and another for conferences? I don't have a strong feeling about that one, but it should be clarified. > > B) The 'Control Framework for SIP' draft places the Control Package-related information at the SIP-level (the Control Packages header etc.) in SIP messages. An alternative would be to place that information in an SDP or SDP-like description as payload, similar to establishing media sessions using SIP. I wonder whether there was any discussion around the pros and cons of doing the latter? [I do realize media channels and control channels are not the same thing]. Take this question as one that is a mild push-back, and perhaps based on ignorance as much as anything. > > Cheers, > > Gary Munson > > > > > -------------------------- > Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. > Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. > > -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From gamunson@att.com Wed, 10 May 2006 20:25:22 +0100 From: Date: Wed, 10 May 2006 20:25:22 +0100 To: Subject: RE: [mediactrl] New version of Control Framework - draft-boulton-sip-control-framework-02 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E1026F7BAA@NJFPSRVEXG2KCL.research.att.com> MIME-Version: 1.0 Content-Type: text/plain Hi Chris,   Some feedback on the SIP Control Framework draft-02:   1) General comment, sort of. I believe the placeholder Section 4 Locating External Server Resources should be removed, and the related text in Section 3 on Caller Preferences/Callee Capabilities etc. as well.     I agree that this is an important topic, and there is general interest in addressing it (somewhere). However, my concerns about carrying it in this document fall along two lines:     a) The current direction in the draft seems to be pushing along the lines of RFCs 3840/3841 and SIP Proxying, which I believe is reasonable but too exclusive. The scope should be extended to acknowledge multiple solutions that could be used based on particular needs. I don’t think there’s a ‘one approach fits all’ solution here; and if there is, then it’s not the 3840/3841 SIP Proxy one.    b) It will be a sizeable topic in its own right, so should be separated out. (Divide and conquer/manage.) There may be some implied corollary comments, having to do with how the AS knows which MS it’s talking to over which control channel, which I believe is an issue to include and address, but is only necessary with the use of certain MS resource location approaches and not others.   2) There were a few comments I made earlier (toward the end of my Feb. 15 email) that I still feel strongly about and I don’t think are addressed. They are resupplied here:    A) *Must* the control channel be established before a call leg is brought to the Media Server? The Control Framework for SIP draft seems to only talk about setting up the control channel before a call leg is brought to the MS. It might be useful to allow for both, don’t know whether it’s problematic. Either way, it should be clarified.   B) Can a single control channel be used to control multiple calls at the MS (using the same control package)? Or in Garland’s jargon, a ‘long-lived’ control channel? I believe that would be desirable to allow for, and should be explicitly addressed.  C) Can different control packages be run over the same control channel? For example, one for simultaneous calls for IVR and another for conferences? I would favor that flexibility, don’t know whether it’s problematic.  Either way, it should be clarified.   Cheers,   Gary   From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Chris Boulton Sent: Tuesday, May 02, 2006 5:52 AM To: mediactrl@lists.ubiquitysoftware.com Cc: McGlashan, Scott; Tim Melanchuk; Asher Shiratzky Subject: [mediactrl] New version of Control Framework - draft-boulton-sip-control-framework-02   Hi all,   A new version of the SIP Control Framework has been submitted.  Until it appears in the archives it can be retrieved from the following links:-   http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-02.txt   http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-02.html   Changes include a new mechanism for control channel and SIP dialog association + a detailed call flow.  The authors would appreciate as much feedback as possible to help consolidate this version.   Best Regards,   Chris.   Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you From taylor@nortel.com Wed, 10 May 2006 20:40:56 +0100 From: "Tom-PT Taylor" Date: Wed, 10 May 2006 20:40:56 +0100 To: gsharratt@convedia.com Subject: Re: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft In-Reply-To: <387B5A9BF31B5D43A2B18DD9F326B8E1026F7B9A@NJFPSRVEXG2KCL.research.att.com> Message-ID: <44624223.3060203@nortel.com> MIME-Version: 1.0 Content-Type: text/plain On comment 3, what bothers me is that since the AS is supposed to maintain a semi-permanent connection to each MS, it must presumably know the capabilities of that MS. (It obtained the address of the MS through the MRB in the first place.) The only reason to get the MRB back into the picture is therefore to detect and act on resource exhaustion at a particular MS. But if the MS rejects a request from the AS the AS already knows what alternatives are available. gamunson@att.com wrote: Garland, Regarding your Comment 2 below, the Query MRB approach addresses a broader set of needs than the Inline MRB. (Again, conferencing examples, the AS and not the MRB really knowing when the MS resources can be released, or the need to control really large conferences that span multiple MS devices, or the ability to alter a prior request or negotiate a resource request). I see Query MRB and Inline MRB as alternatives that one could implement depending on what the particular needs are. But posing the Inline MRB as the only solution, implying it meets all needs, is insufficient. Regarding Comment 3, I agree on both points: - to allow the TCP connection to be long-lived would be desirable, at least as an option - there is no conflict with MRB, whether the Query MRB or Inline MRB flavor [Didn't have anything useful to say wrt your Comment 1. Points noted. :-) ] Cheers, Gary -----Original Message----- From: Garland Sharratt [mailto:gsharratt@convedia.com] Sent: Wednesday, May 10, 2006 9:42 AM To: 'Tom-PT Taylor'; Munson,Gary A (Gary) Cc: mediactrl@lists.ubiquitysoftware.com Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft Tom, Gary, a few belated comments on your two emails together: 1. Dumb media server vs. smart media server. I don't agree that an H.248 MS is dumb and a SIP MS is smarter. If you look at an H.248 media server and a SIP media server, there is no real difference between them. Both do the same job, media processing. Yes, the control interface looks different, but they are both doing playing, recording, DTMF collection, conference mixing, etc. Yes, pure VoiceXML (pure = no call control, e.g., "transfer" element) is often used with SIP media servers and not with H.248 media servers, but this doesn't change the role or function of a media server, which is to perform media processing under the total control of an external application. 2. Inline MRB vs. Query MRB I don't really have an axe to grind on either side but based on what I know at this time I don't agree that the Query MRB is better than the Inline MRB. The Query MRB needs new protocols and interfaces defined, whereas the Inline MRB doesn't. For this reason the Inline MRB seems more elegant to me. (Incidentally, moving to a TCP channel instead of SIP INFO, see below, removes one of the objections to the Inline MRB, that in order for it to have visibility of BYE messages (which is necessary for resource control purposes) it needs to also flow through all the SIP INFO messages, which is inefficient.) The last time I looked at the MSF has only the Inline MRB, not the Query MRB. Tom, has this really changed? 3. Separate TCP control channel negotiated by SIP I think that for efficiently reasons such a TCP channel needs to be: (a) long lived, and (b) used to control multiple RTP streams. For example, one very viable way to use these channels would be to have *one* such long-live TCP channel set up between each combination of AS and MS, at restart time. The AS would use the one TCP channel to control all its RTP streams on that MS. So if there were N ASs and M MSs, there would be N x M control channels, assuming all ASs had access to all MSs. Perhaps there could also be a time-out mechanism that might tear down a TCP channel if it hadn't been used in an hour, if this was valuable for some reason. And of course if a particular MS isn't useable by a particular AS, there would be no TCP channel. I don't see a conflict between having these long-lived TCP channels and the presence of the MRB. Comments welcome. Garland -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Tom-PT Taylor Sent: Wednesday, February 15, 2006 08:24 To: gamunson@att.com Cc: mediactrl@lists.ubiquitysoftware.com Subject: Re: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft The MSF has taken the Media Resource Broker into its architecture, with two different SIP interfaces. The first requests media resources of a specific type, with a URI to a media server as a return result. The second has the MRB acting as a proxy (optional) between the client and the Media Server. I'll confess that in the short term the MSF is using SIP INFO transport. (Strong influence by specific vendors here.) However, if this architecture were to persist but with the SIP setting up separate control channels, I find it hard to picture those channels remaining up once the individual call is completed. Control channels persisting for longer than the duration of an individual usage (call) imply a tighter relationship between the AS and the MS than I think compatible with the role of a media resource broker. gamunson@att.com wrote: Hi folks, I'll throw in my views here on some topics that have been in the recent emails, say from February 4 onward. 1) It seems that there are two basic concepts of what is meant by Media Server a) the really dumb kind (a la IMS MRFP) b) the one that can be smarter (a la IMS MRFC + MRFP) * I believe that the AS-MS protocol that the Mediactrl BoF should be fundamentally addressing is (b); but it should be extensible to allow finer control granularity. In a practical architecture, it should be possible for the AS to tell the MS to do routine tricks on its own (e.g., roll over, fetch a stick, bite the mailman) without the AS controlling every itsy-bitsy step. So, yes, something like VXML on the MS makes perfectly good sense. On the other hand, to preclude a potentially finer level of control for some applications seems unwise. 2) While I used above the representation of the 'smarter' MS as IMS MRFC +MRFP, as have others, it has a flaw. The IMS MRFC consists of two functions. One is the MRFP control function, which is okay to be part of the MS. But the MRFC also has a media resource *assignment* function. At the network level, that assignment function cannot be part of a Media Server. (Local resource assignment among a cluster of servers is a different matter.) [One other side note - in an earlier mail, the AS-MS control interface was referred to, in IMS terms, as the Mr interface. On the MS side that's fine. However, in the IMS pictures I have seen, the Mr interface has as its other endpoint the S-CSCF, not the AS.] * That MS assignment function is related to topics that came in multiple earlier emails about MS discovery, and whether we're assuming a static connection between an AS and MS, and whether the resource management function lives 'below S-CSCF'. One of the scenarios we need to allow for is a many-to-many AS-MS relationship where the MS resources are a shared pool across many different services residing on many ASes, with tons of traffic with variations in volumes, some predictable, some not, and where MS resources are not infinite and the MS boxes don't all have the same size or capability set, and services don't all have the same priority, etc.. In such as case, we want to - Allow for a network-level MS assignment function (referred to as a Media Server Resource Broker or just Media Resource Broker); one model of the way MSRB works (e.g., recent work in the ATIS-PTSC and in the ITU-T NGN based on a set of requirements), is for an AS to query the MSRB when it wants MS resources. The MSRB responds to the AS with identified MS resources that it allocates to that AS. When the AS is done with its assigned MS resources, it releases them back to the MSRB. In that model, the MSRB doesn't have to live below, and can be unrelated to, S-CSCF. There is another model of MRB that would live below S-CSCF, but it doesn't support as broad a set of needs as the AS-MSRB model described here. - Allow for more than just a static AS-MS control channel situation. In short, while recognizing the topics of MS 'discovery' and/or MS resource management/allocation as important, they should remain outside the scope of the BoF AS-MS protocol effort, and we should allow the AS-MS control channel connection situation to be fluid. Next, a couple comments for Chris & co on the "A Control Framework for SIP" draft, staying out of the Control Package fray, and questions about which protocol might be a chicken or an egg :-) -- A) I resonate strongly with the option of having a separate AS-MS control channel set up by SIP, and TCP for transport is good. Here are some additional points to potentially clarify: a) *Must* the control channel be established before a call leg is brought to the Media Server? The Control Framework for SIP draft seems to only talk about setting up the control channel before a call leg is brought to the MS. It might be useful to allow for both. b) Can a single control channel be used to control multiple calls at the MS (using the same control package)? For example, 10 simultaneous IVR sessions? I believe the intent is to allow that, but I didn't see words to that effect. c) Can different control packages be run over the same control channel? For example, one for simultaneous calls for IVR and another for conferences? I don't have a strong feeling about that one, but it should be clarified. B) The 'Control Framework for SIP' draft places the Control Package-related information at the SIP-level (the Control Packages header etc.) in SIP messages. An alternative would be to place that information in an SDP or SDP-like description as payload, similar to establishing media sessions using SIP. I wonder whether there was any discussion around the pros and cons of doing the latter? [I do realize media channels and control channels are not the same thing]. Take this question as one that is a mild push-back, and perhaps based on ignorance as much as anything. Cheers, Gary Munson -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From gamunson@att.com Wed, 10 May 2006 22:01:00 +0100 From: Date: Wed, 10 May 2006 22:01:00 +0100 To: Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E1026F7BF0@NJFPSRVEXG2KCL.research.att.com> MIME-Version: 1.0 Content-Type: text/plain Tom, Here is one real motivation I see for *optionally* allowing the control channel to persist over the course of many calls. A service provider knows it will handle a huge spike/volume of calls in a certain time period (e.g., people calling in to cast American Idol votes). It would be useful for the AS handling those calls to be able to make one request to the MRB essentially saying "I need X thousand audio ports for the time interval A-B, all for simple prompt & collect" in one request, and have the MS resources identified to the AS in one response, as opposed to the overhead of the AS making millions of separate requests, one for each call. And setting up and tearing down the corresponding TCP connections for each call. Later, the AS could release those ports. The AS could release a portion at a time, as traffic falls off. One could ask why not just let the MRB assume they are all free up at time B, but there could be other cases where the traffic patterns may not be so predictable; maybe some emergency/disaster situation and a government service whose calls need to be given high priority and involve use of MS resources. Cheers, Gary -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortel.com] Sent: Wednesday, May 10, 2006 3:42 PM To: Munson,Gary A (Gary); gsharratt@convedia.com Cc: mediactrl@lists.ubiquitysoftware.com Subject: Re: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft On comment 3, what bothers me is that since the AS is supposed to maintain a semi-permanent connection to each MS, it must presumably know the capabilities of that MS. (It obtained the address of the MS through the MRB in the first place.) The only reason to get the MRB back into the picture is therefore to detect and act on resource exhaustion at a particular MS. But if the MS rejects a request from the AS the AS already knows what alternatives are available. gamunson@att.com wrote: > Garland, > > Regarding your Comment 2 below, the Query MRB approach addresses a > broader set of needs than the Inline MRB. (Again, conferencing examples, > the AS and not the MRB really knowing when the MS resources can be > released, or the need to control really large conferences that span > multiple MS devices, or the ability to alter a prior request or > negotiate a resource request). I see Query MRB and Inline MRB as > alternatives that one could implement depending on what the particular > needs are. But posing the Inline MRB as the only solution, implying it > meets all needs, is insufficient. > > Regarding Comment 3, I agree on both points: > - to allow the TCP connection to be long-lived would be desirable, at > least as an option > - there is no conflict with MRB, whether the Query MRB or Inline MRB > flavor > > [Didn't have anything useful to say wrt your Comment 1. Points noted. > :-) ] > > Cheers, > > Gary > > -----Original Message----- > From: Garland Sharratt [mailto:gsharratt@convedia.com] > Sent: Wednesday, May 10, 2006 9:42 AM > To: 'Tom-PT Taylor'; Munson,Gary A (Gary) > Cc: mediactrl@lists.ubiquitysoftware.com > Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the > Control Framework for SIP draft > > Tom, Gary, a few belated comments on your two emails together: > > 1. Dumb media server vs. smart media server. > > I don't agree that an H.248 MS is dumb and a SIP MS is smarter. If you > look > at an H.248 media server and a SIP media server, there is no real > difference > between them. Both do the same job, media processing. Yes, the control > interface looks different, but they are both doing playing, recording, > DTMF > collection, conference mixing, etc. Yes, pure VoiceXML (pure = no call > control, e.g., "transfer" element) is often used with SIP media servers > and > not with H.248 media servers, but this doesn't change the role or > function > of a media server, which is to perform media processing under the total > control of an external application. > > > 2. Inline MRB vs. Query MRB > > I don't really have an axe to grind on either side but based on what I > know > at this time I don't agree that the Query MRB is better than the Inline > MRB. > The Query MRB needs new protocols and interfaces defined, whereas the > Inline > MRB doesn't. For this reason the Inline MRB seems more elegant to me. > > (Incidentally, moving to a TCP channel instead of SIP INFO, see below, > removes one of the objections to the Inline MRB, that in order for it to > have visibility of BYE messages (which is necessary for resource control > purposes) it needs to also flow through all the SIP INFO messages, which > is > inefficient.) > > The last time I looked at the MSF has only the Inline MRB, not the Query > MRB. Tom, has this really changed? > > > 3. Separate TCP control channel negotiated by SIP > > I think that for efficiently reasons such a TCP channel needs to be: (a) > long lived, and (b) used to control multiple RTP streams. For example, > one > very viable way to use these channels would be to have *one* such > long-live > TCP channel set up between each combination of AS and MS, at restart > time. > The AS would use the one TCP channel to control all its RTP streams on > that > MS. So if there were N ASs and M MSs, there would be N x M control > channels, > assuming all ASs had access to all MSs. Perhaps there could also be a > time-out mechanism that might tear down a TCP channel if it hadn't been > used > in an hour, if this was valuable for some reason. And of course if a > particular MS isn't useable by a particular AS, there would be no TCP > channel. > > I don't see a conflict between having these long-lived TCP channels and > the > presence of the MRB. > > > Comments welcome. > > Garland > > > -----Original Message----- > From: owner-mediactrl@lists.ubiquitysoftware.com > [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Tom-PT > Taylor > Sent: Wednesday, February 15, 2006 08:24 > To: gamunson@att.com > Cc: mediactrl@lists.ubiquitysoftware.com > Subject: Re: [mediactrl] a few comments on AS-MS-related topics; and the > Control Framework for SIP draft > > The MSF has taken the Media Resource Broker into its architecture, with > two different SIP interfaces. The first requests media resources of a > specific type, with a URI to a media server as a return result. The > second has the MRB acting as a proxy (optional) between the client and > the Media Server. > > I'll confess that in the short term the MSF is using SIP INFO transport. > > (Strong influence by specific vendors here.) However, if this > architecture were to persist but with the SIP setting up separate > control channels, I find it hard to picture those channels remaining up > once the individual call is completed. Control channels persisting for > longer than the duration of an individual usage (call) imply a tighter > relationship between the AS and the MS than I think compatible with the > role of a media resource broker. > > gamunson@att.com wrote: >> Hi folks, >> >> I'll throw in my views here on some topics that have been in the > recent > emails, say from February 4 onward. >> 1) It seems that there are two basic concepts of what is meant by > Media > Server >> a) the really dumb kind (a la IMS MRFP) >> b) the one that can be smarter (a la IMS MRFC + MRFP) >> >> * I believe that the AS-MS protocol that the Mediactrl BoF should be > fundamentally addressing is (b); but it should be extensible to allow > finer > control granularity. In a practical architecture, it should be possible > for > the AS to tell the MS to do routine tricks on its own (e.g., roll over, > fetch a stick, bite the mailman) without the AS controlling every > itsy-bitsy > step. So, yes, something like VXML on the MS makes perfectly good sense. > On > the other hand, to preclude a potentially finer level of control for > some > applications seems unwise. >> 2) While I used above the representation of the 'smarter' MS as IMS > MRFC > +MRFP, as have others, it has a flaw. The IMS MRFC consists of two > functions. One is the MRFP control function, which is okay to be part of > the > MS. But the MRFC also has a media resource *assignment* function. At the > network level, that assignment function cannot be part of a Media > Server. > (Local resource assignment among a cluster of servers is a different > matter.) [One other side note - in an earlier mail, the AS-MS control > interface was referred to, in IMS terms, as the Mr interface. On the MS > side > that's fine. However, in the IMS pictures I have seen, the Mr interface > has > as its other endpoint the S-CSCF, not the AS.] >> * That MS assignment function is related to topics that came in > multiple > earlier emails about MS discovery, and whether we're assuming a static > connection between an AS and MS, and whether the resource management > function lives 'below S-CSCF'. >> One of the scenarios we need to allow for is a many-to-many AS-MS > relationship where the MS resources are a shared pool across many > different > services residing on many ASes, with tons of traffic with variations in > volumes, some predictable, some not, and where MS resources are not > infinite > and the MS boxes don't all have the same size or capability set, and > services don't all have the same priority, etc.. In such as case, we > want to >> - Allow for a network-level MS assignment function (referred to as a > Media > Server Resource Broker or just Media Resource Broker); one model of the > way > MSRB works (e.g., recent work in the ATIS-PTSC and in the ITU-T NGN > based on > a set of requirements), is for an AS to query the MSRB when it wants MS > resources. The MSRB responds to the AS with identified MS resources that > it > allocates to that AS. When the AS is done with its assigned MS > resources, > it releases them back to the MSRB. In that model, the MSRB doesn't have > to > live below, and can be unrelated to, S-CSCF. There is another model of > MRB > that would live below S-CSCF, but it doesn't support as broad a set of > needs > as the AS-MSRB model described here. >> - Allow for more than just a static AS-MS control channel situation. >> In short, while recognizing the topics of MS 'discovery' and/or MS > resource management/allocation as important, they should remain outside > the > scope of the BoF AS-MS protocol effort, and we should allow the AS-MS > control channel connection situation to be fluid. >> Next, a couple comments for Chris & co on the "A Control Framework for > SIP" draft, staying out of the Control Package fray, and questions about > which protocol might be a chicken or an egg :-) -- >> A) I resonate strongly with the option of having a separate AS-MS > control > channel set up by SIP, and TCP for transport is good. Here are some > additional points to potentially clarify: >> a) *Must* the control channel be established before a call leg is > brought to the Media Server? The Control Framework for SIP draft seems > to > only talk about setting up the control channel before a call leg is > brought > to the MS. It might be useful to allow for both. >> b) Can a single control channel be used to control multiple calls at > the > MS (using the same control package)? For example, 10 simultaneous IVR > sessions? I believe the intent is to allow that, but I didn't see words > to > that effect. >> c) Can different control packages be run over the same control > channel? > For example, one for simultaneous calls for IVR and another for > conferences? > I don't have a strong feeling about that one, but it should be > clarified. >> B) The 'Control Framework for SIP' draft places the Control > Package-related information at the SIP-level (the Control Packages > header > etc.) in SIP messages. An alternative would be to place that information > in > an SDP or SDP-like description as payload, similar to establishing media > sessions using SIP. I wonder whether there was any discussion around the > pros and cons of doing the latter? [I do realize media channels and > control > channels are not the same thing]. Take this question as one that is a > mild > push-back, and perhaps based on ignorance as much as anything. >> Cheers, >> >> Gary Munson >> >> >> >> >> -------------------------- >> Ubiquity Software does not control or endorse the content, messages or > information found in this mail list and it specifically disclaims any > liability with regard to these communications. >> Ubiquity Software reserves the right the restrict access to any > communications in violation of the Terms and Conditions of Use for this > website or as otherwise deemed improper. >> > > -------------------------- > Ubiquity Software does not control or endorse the content, messages or > information found in this mail list and it specifically disclaims any > liability with regard to these communications. > Ubiquity Software reserves the right the restrict access to any > communications in violation of the Terms and Conditions of Use for this > website or as otherwise deemed improper. > > > > -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From cboulton@ubiquity.net Thu, 11 May 2006 08:56:10 +0100 From: "Chris Boulton" Date: Thu, 11 May 2006 08:56:10 +0100 To: Subject: RE: [mediactrl] New version of Control Framework - draft-boulton-sip-control-framework-02 Message-ID: <45730E094814E44488F789C1CDED27AE03118A2A@gbnewp0758m.eu.ubiquity.net> MIME-Version: 1.0 Content-Type: text/plain Hi Gary – many thanks for the comments.  More ‘in-line’.   Chris.     -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of gamunson@att.com Sent: 10 May 2006 20:00 To: mediactrl@lists.ubiquitysoftware.com Subject: RE: [mediactrl] New version of Control Framework - draft-boulton-sip-control-framework-02   Hi Chris,   Some feedback on the SIP Control Framework draft-02:   1) General comment, sort of. I believe the placeholder Section 4 Locating External Server Resources should be removed, and the related text in Section 3 on Caller Preferences/Callee Capabilities etc. as well.     I agree that this is an important topic, and there is general interest in addressing it (somewhere). However, my concerns about carrying it in this document fall along two lines:     a) The current direction in the draft seems to be pushing along the lines of RFCs 3840/3841 and SIP Proxying, which I believe is reasonable but too exclusive. The scope should be extended to acknowledge multiple solutions that could be used based on particular needs. I don’t think there’s a ‘one approach fits all’ solution here; and if there is, then it’s not the 3840/3841 SIP Proxy one.    b) It will be a sizeable topic in its own right, so should be separated out. (Divide and conquer/manage.) There may be some implied corollary comments, having to do with how the AS knows which MS it’s talking to over which control channel, which I believe is an issue to include and address, but is only necessary with the use of certain MS resource location approaches and not others.   [Chris Boulton] Yes – totally agree.  To be honest you are correct in that this was only ever really meant to be a placeholder and the intention was that if this work had legs it would become a separate topic for discussion and documentation.  I can easily take it out or leave it now that you know it is simply a pointer.   2) There were a few comments I made earlier (toward the end of my Feb. 15 email) that I still feel strongly about and I don’t think are addressed. They are resupplied here:    A) *Must* the control channel be established before a call leg is brought to the Media Server? The Control Framework for SIP draft seems to only talk about setting up the control channel before a call leg is brought to the MS. It might be useful to allow for both, don’t know whether it’s problematic. Either way, it should be clarified.   [Chris Boulton] I don’t see why you MUST have a control channel established.  It would just mean that you can’t issue any commands on that media stream.  Does that seem ok to everyone? At the end of the day we are talking about two mechanisms that are not dependant on each other.   I will clarify the text in the next revision if no-one opposes.     B) Can a single control channel be used to control multiple calls at the MS (using the same control package)?   [Chris Boulton] It most definitely can – that is the primary concept + the reason the dialog xml is provided.  Remember that the control frameworks intention is to be agnostic – so if you take a look at the IVR package you will see how it can import the dialog XML schema from the framework and reference multiple calls on one control channel.    Or in Garland’s jargon, a ‘long-lived’ control channel? I believe that would be desirable to allow for, and should be explicitly addressed.   [Chris Boulton] I will clarify the text where possible BUT this really is part of a package to make use of the channel how it wants.  We create a SIP dialog which results in a control chancel being established – you tear it down the control channel goes as well.  If in a control package this is long lived then so be it – just don’t tear down the SIP dialog.    C) Can different control packages be run over the same control channel?   [Chris Boulton] Definitely.    For example, one for simultaneous calls for IVR and another for conferences?   [Chris Boulton] Correct.    I would favor that flexibility, don’t know whether it’s problematic.  Either way, it should be clarified.   [Chris Boulton] I will take a look at the text.  It definitely talks about negotiating all of the packages that CAN be used on a particular control channel (and the BNF supports this).  It is intended that ‘1>’ control packages MUST be included and ANY of them can be used on a control channel.  The individual CONTROL messages are associated to a specific Control Package by the ‘Control-Package’ header at the framework level – which can only contain one value.   Cheers,   Gary   From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Chris Boulton Sent: Tuesday, May 02, 2006 5:52 AM To: mediactrl@lists.ubiquitysoftware.com Cc: McGlashan, Scott; Tim Melanchuk; Asher Shiratzky Subject: [mediactrl] New version of Control Framework - draft-boulton-sip-control-framework-02   Hi all,   A new version of the SIP Control Framework has been submitted.  Until it appears in the archives it can be retrieved from the following links:-   http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-02.txt   http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-02.html   Changes include a new mechanism for control channel and SIP dialog association + a detailed call flow.  The authors would appreciate as much feedback as possible to help consolidate this version.   Best Regards,   Chris.   Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you From asaleem@convedia.com Thu, 11 May 2006 23:11:13 +0100 From: "Adnan Saleem" Date: Thu, 11 May 2006 23:11:13 +0100 To: "Chris Boulton" Subject: RE: [mediactrl] How to get this work into a WG In-Reply-To: <45730E094814E44488F789C1CDED27AE03118A20@gbnewp0758m.eu.ubiquity.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi Chris,   Please see response inline:   Thanks   Adnan -----Original Message-----From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com]On Behalf Of Chris BoultonSent: May 9, 2006 5:40 AMTo: Adnan Saleem; Cullen Jennings; mediactrl@lists.ubiquitysoftware.comCc: Burger, EricSubject: RE: [mediactrl] How to get this work into a WG   Cullen,I want to point out that we have rough consensus (imho) on the "control framework" ID (http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt), from an architectural perspective and the direction this is going. [Chris Boulton] That’s really good to hear. However, there is no consensus on the remaining IDs identified below.   [Chris Boulton] I’m not sure consensus was at all proposed – certainly not by me.  That’s jumping the gun a little.  I was just pointing out that we have current examples of how Control Packages are written in-line with the framework.   Convedia in particular objects to the "extension" IDs listed below, covering IVR and conference control.         - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt).       - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt).       - (http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt).   The above new IDs essentially provide a subset and duplication of the what MSML, and MSCML to a good extent, have already provided for years.   [Chris Boulton] Totally understand your position.  All I will say is that:-   -          yes, you are correct in that this does provide duplication of MSML and MSCML.  The intention was to use and build on the experiences gained from such languages to provide a solution that architecturally fits with the new Control Framework. [Adnan Saleem] The intention is for MSML to fit within the Control Framework, which may require a few minor tweaks. Once the Control Framework specification has been reviewed / updated sufficiently to a point of stability, then MSML can be updated with some minor changes. But of course, this all depends on the what ends up in the Control Framework specification. The main purpose, from what I remember, was for Control Framework to allow SIP initiated TCP/IP control channel establishment, which it is addressing. As for the control language itself and the requirement for modularity or concept of packages was also an agreed upon requirement, which is already coverd by MSML.   -          Yes it provides subsets of functionality.  This again was the intention to provide a modular approach.  We are thinking (and received quite a large amount of feedback from media control group) from the agnostic point of view that not everyone wants to implement a large scripting language for simple IVR interactions.  It should be possible to select exactly what you need to fit your requirements. [Adnan Saleem] Not sure if you're aware of this, but MSML is already highly modular, utilizing a package scheme. The packages are defined as mandatory or optional. This facilitates cross product interoperability as well as the choice of using simple or complex functions is available, depending on application level requirements. The following shows the MSML package scheme.                     +----------------------------------------------+                   |                  MSML Core                   |                   +----------------------------------------------+                       /                                       \                   +--------+                              +--------+                   | Dialog |                              | Conf   |                   | Core   |                              | Core   |              -  - +--------+ - -  -  -  -  -   -   -      +--------+             /        /          \           \       \        +--------+  +--------+ +---------+ +------+ +------+        | Dialog |  | Dialog | |Dialog   | |Dialog| |Dialog|        | Base   |  | Group  | |Transform| |Speech| |Fax   |        +--------+  +--------+ +---------+ +------+ +------+     If you have got any more detail on your technical objections I think it would be great to have some discussion.[Adnan Saleem] Not any new ones at the moment, but I may have some additional items in the near future when I complete the reviews of the latest revisions. Review comments and technical objections were sent a while ago on earlier revisions.   Best Regards,   Chris.       Garland / Adnan -----Original Message-----From: owner-mediactrl@lists.ubiquitysoftware.com[mailto:owner-mediactrl@lists.ubiquitysoftware.com]On Behalf Of ChrisBoultonSent: May 8, 2006 2:36 AMTo: Cullen Jennings; MixerControlCc: Burger, EricSubject: RE: [mediactrl] How to get this work into a WGHi Cullen (donning AD cap),We are still very much actively discussing this work and have met atevery IETF since Paris (I think) - including a Beer BOF and a Meal BOF:-).        A long time ago, we had talked about asking the SpeachSC chairsif         that WG might take on this work. Is there still interest inthat?        Very much so - we have been discussing this regularly and I think we hadhoped (Eric will confirm but I know he is snowed under at the moment) tomove towards IETF working group towards the end of this year/maybe earlynext.        PS - A short summary of the status of where we are, what wehave, and         where various parties might want to eventually get to might bereally         helpful for me.We are at the point where we have a Control Framework which has beendiscussed at length at previous meetings(http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt) which aims to fulfill the detail outlined in the Requirementsdocument(http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01.txt).  This is an agnostic approach that is not 'Media Server' specificand aims to provide a core connection management system using SIP.The authors of the Framework have also created a number of extensions tothe Control Framework that provides modules for achieving various levelsof Media Server Control.- First extension provides simple IVR functionality(http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt).- There is an extension to the SIMPLE IVR functionality for the purposeof using VXML(http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt).- This extensions provides conferencing capabilities(http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt).If you need anymore information then give me a shout.Best Regards,Chris.-----Original Message-----From: owner-mediactrl@lists.ubiquitysoftware.com[mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of CullenJenningsSent: 07 May 2006 16:11To: MixerControlSubject: [mediactrl] How to get this work into a WGA long time ago, we had talked about asking the SpeachSC chairs if that WG might take on this work. Is there still interest in that? With my AD hat on, I have no idea what is the best way to do this yet but I am looking for input on what the next logical steps are with all the work that has been happing here.Thanks, CullenPS - A short summary of the status of where we are, what we have, and where various parties might want to eventually get to might be really helpful for me.--------------------------Ubiquity Software does not control or endorse the content, messages orinformation found in this mail list and it specifically disclaims anyliability with regard to these communications.Ubiquity Software reserves the right the restrict access to anycommunications in violation of the Terms and Conditions of Use for thiswebsite or as otherwise deemed improper.Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.--------------------------Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From gamunson@att.com Fri, 12 May 2006 15:18:38 +0100 From: Date: Fri, 12 May 2006 15:18:38 +0100 To: Subject: RE: [mediactrl] New version of Control Framework - draft-boulton-sip-control-framework-02 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E1026F7E0F@NJFPSRVEXG2KCL.research.att.com> MIME-Version: 1.0 Content-Type: text/plain Thanks, Chris.   All sounds good to me. I would personally still lean toward taking out the placeholder section on “Locating … Resources”, or at most, if the section stays, say something very brief and generic that acknowledges the topic but says methods are not addressed in this document.   Regarding the very last item, about running different control packages over the same control channel, where you commented . “ It definitely talks about negotiating all of the packages that CAN be used on a particular control channel (and the BNF supports this).” , I probably wasn’t reading closely enough. Didn’t know whether the “can” had the sense of “I the AS will do any *one* of these” or “I the AS might do any *subset* of these”.   Cheers,   Gary   From: Chris Boulton [mailto:cboulton@ubiquity.net] Sent: Thursday, May 11, 2006 3:58 AM To: Munson,Gary A (Gary); mediactrl@lists.ubiquitysoftware.com Subject: RE: [mediactrl] New version of Control Framework - draft-boulton-sip-control-framework-02   Hi Gary – many thanks for the comments.  More ‘in-line’.   Chris.     -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of gamunson@att.com Sent: 10 May 2006 20:00 To: mediactrl@lists.ubiquitysoftware.com Subject: RE: [mediactrl] New version of Control Framework - draft-boulton-sip-control-framework-02   Hi Chris,   Some feedback on the SIP Control Framework draft-02:   1) General comment, sort of. I believe the placeholder Section 4 Locating External Server Resources should be removed, and the related text in Section 3 on Caller Preferences/Callee Capabilities etc. as well.     I agree that this is an important topic, and there is general interest in addressing it (somewhere). However, my concerns about carrying it in this document fall along two lines:     a) The current direction in the draft seems to be pushing along the lines of RFCs 3840/3841 and SIP Proxying, which I believe is reasonable but too exclusive. The scope should be extended to acknowledge multiple solutions that could be used based on particular needs. I don’t think there’s a ‘one approach fits all’ solution here; and if there is, then it’s not the 3840/3841 SIP Proxy one.    b) It will be a sizeable topic in its own right, so should be separated out. (Divide and conquer/manage.) There may be some implied corollary comments, having to do with how the AS knows which MS it’s talking to over which control channel, which I believe is an issue to include and address, but is only necessary with the use of certain MS resource location approaches and not others.   [Chris Boulton] Yes – totally agree.  To be honest you are correct in that this was only ever really meant to be a placeholder and the intention was that if this work had legs it would become a separate topic for discussion and documentation.  I can easily take it out or leave it now that you know it is simply a pointer.   2) There were a few comments I made earlier (toward the end of my Feb. 15 email) that I still feel strongly about and I don’t think are addressed. They are resupplied here:    A) *Must* the control channel be established before a call leg is brought to the Media Server? The Control Framework for SIP draft seems to only talk about setting up the control channel before a call leg is brought to the MS. It might be useful to allow for both, don’t know whether it’s problematic. Either way, it should be clarified.   [Chris Boulton] I don’t see why you MUST have a control channel established.  It would just mean that you can’t issue any commands on that media stream.  Does that seem ok to everyone? At the end of the day we are talking about two mechanisms that are not dependant on each other.   I will clarify the text in the next revision if no-one opposes.     B) Can a single control channel be used to control multiple calls at the MS (using the same control package)?   [Chris Boulton] It most definitely can – that is the primary concept + the reason the dialog xml is provided.  Remember that the control frameworks intention is to be agnostic – so if you take a look at the IVR package you will see how it can import the dialog XML schema from the framework and reference multiple calls on one control channel.    Or in Garland’s jargon, a ‘long-lived’ control channel? I believe that would be desirable to allow for, and should be explicitly addressed.   [Chris Boulton] I will clarify the text where possible BUT this really is part of a package to make use of the channel how it wants.  We create a SIP dialog which results in a control chancel being established – you tear it down the control channel goes as well.  If in a control package this is long lived then so be it – just don’t tear down the SIP dialog.    C) Can different control packages be run over the same control channel?   [Chris Boulton] Definitely.    For example, one for simultaneous calls for IVR and another for conferences?   [Chris Boulton] Correct.    I would favor that flexibility, don’t know whether it’s problematic.  Either way, it should be clarified.   [Chris Boulton] I will take a look at the text.  It definitely talks about negotiating all of the packages that CAN be used on a particular control channel (and the BNF supports this).  It is intended that ‘1>’ control packages MUST be included and ANY of them can be used on a control channel.  The individual CONTROL messages are associated to a specific Control Package by the ‘Control-Package’ header at the framework level – which can only contain one value.   Cheers,   Gary   From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Chris Boulton Sent: Tuesday, May 02, 2006 5:52 AM To: mediactrl@lists.ubiquitysoftware.com Cc: McGlashan, Scott; Tim Melanchuk; Asher Shiratzky Subject: [mediactrl] New version of Control Framework - draft-boulton-sip-control-framework-02   Hi all,   A new version of the SIP Control Framework has been submitted.  Until it appears in the archives it can be retrieved from the following links:-   http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-02.txt   http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-02.html   Changes include a new mechanism for control channel and SIP dialog association + a detailed call flow.  The authors would appreciate as much feedback as possible to help consolidate this version.   Best Regards,   Chris.   Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you From asaleem@convedia.com Tue, 16 May 2006 06:41:17 +0100 From: "Adnan Saleem" Date: Tue, 16 May 2006 06:41:17 +0100 To: "Cullen Jennings" Subject: RE: [mediactrl] How to get this work into a WG In-Reply-To: <89C69C42-F8E9-4290-82E9-A9BD207B62F4@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi Cullen, The SpeechSC WG would be ok for mediactrl work, if the charter of this WG is changed to make it clear that the MS work and the Speech Server (SS) work are completely separate. SpeechSC in the past has occasionally expressed interest in turning MRCP into a full media server control interface, and we want to make sure that is clarified and prevented by the group's charter. Thanks Adnan -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com]On Behalf Of Cullen Jennings Sent: May 7, 2006 8:11 AM To: MixerControl Subject: [mediactrl] How to get this work into a WG A long time ago, we had talked about asking the SpeachSC chairs if that WG might take on this work. Is there still interest in that? With my AD hat on, I have no idea what is the best way to do this yet but I am looking for input on what the next logical steps are with all the work that has been happing here. Thanks, Cullen PS - A short summary of the status of where we are, what we have, and where various parties might want to eventually get to might be really helpful for me. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From fluffy@cisco.com Tue, 16 May 2006 07:22:41 +0100 From: Cullen Jennings Date: Tue, 16 May 2006 07:22:41 +0100 To: Chris Boulton Subject: Re: [mediactrl] How to get this work into a WG In-Reply-To: <45730E094814E44488F789C1CDED27AE03118A18@gbnewp0758m.eu.ubiquity.net> Message-ID: <4EC550A0-886B-4413-98E0-4DAE1301108D@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Thanks for update and glad to hear things are moving along - I had a quick skim of all the documents and it gives me an idea where things. When the group here decides they are ready to talk about adding this to speeachsc, the chairs can give me a ping. Thanks, Cullen On May 8, 2006, at 11:36 AM, Chris Boulton wrote: Hi Cullen (donning AD cap), We are still very much actively discussing this work and have met at every IETF since Paris (I think) - including a Beer BOF and a Meal BOF :-). A long time ago, we had talked about asking the SpeachSC chairs if that WG might take on this work. Is there still interest in that? Very much so - we have been discussing this regularly and I think we had hoped (Eric will confirm but I know he is snowed under at the moment) to move towards IETF working group towards the end of this year/maybe early next. PS - A short summary of the status of where we are, what we have, and where various parties might want to eventually get to might be really helpful for me. We are at the point where we have a Control Framework which has been discussed at length at previous meetings (http://www.ietf.org/internet-drafts/draft-boulton-sip-control- framework -02.txt) which aims to fulfill the detail outlined in the Requirements document (http://www.ietf.org/internet-drafts/draft-dolly-xcon- mediacntrlframe-01 .txt). This is an agnostic approach that is not 'Media Server' specific and aims to provide a core connection management system using SIP. The authors of the Framework have also created a number of extensions to the Control Framework that provides modules for achieving various levels of Media Server Control. - First extension provides simple IVR functionality (http://www.ietf.org/internet-drafts/draft-boulton-ivr-control- package-0 1.txt). - There is an extension to the SIMPLE IVR functionality for the purpose of using VXML (http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control- pack age-00.txt). - This extensions provides conferencing capabilities (http://www.ietf.org/internet-drafts/draft-boulton-conference- control-pa ckage-00.txt). If you need anymore information then give me a shout. Best Regards, Chris. -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Cullen Jennings Sent: 07 May 2006 16:11 To: MixerControl Subject: [mediactrl] How to get this work into a WG A long time ago, we had talked about asking the SpeachSC chairs if that WG might take on this work. Is there still interest in that? With my AD hat on, I have no idea what is the best way to do this yet but I am looking for input on what the next logical steps are with all the work that has been happing here. Thanks, Cullen PS - A short summary of the status of where we are, what we have, and where various parties might want to eventually get to might be really helpful for me. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank you. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From EBurger@cantata.com Tue, 16 May 2006 17:30:28 +0100 From: "Burger, Eric" Date: Tue, 16 May 2006 17:30:28 +0100 To: Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft Message-ID: <330A23D8336C0346B5C1A5BB1966664702E02846@ATLANTIS.Brooktrout.com> MIME-Version: 1.0 Content-Type: text/plain I would offer that one of the major justifications for using SIP for AS-MS communication is precisely because it enables us to create TRANSPARENT, Inline MRFB's. A Query MRB is entirely orthogonal to the AS-MS communication channel. I would offer we can (and should?) define that as a separate task (read "work item"). -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of gamunson@att.com Sent: Wednesday, May 10, 2006 2:17 PM To: gsharratt@convedia.com; taylor@nortel.com Cc: mediactrl@lists.ubiquitysoftware.com Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft Garland, Regarding your Comment 2 below, the Query MRB approach addresses a broader set of needs than the Inline MRB. (Again, conferencing examples, the AS and not the MRB really knowing when the MS resources can be released, or the need to control really large conferences that span multiple MS devices, or the ability to alter a prior request or negotiate a resource request). I see Query MRB and Inline MRB as alternatives that one could implement depending on what the particular needs are. But posing the Inline MRB as the only solution, implying it meets all needs, is insufficient. Regarding Comment 3, I agree on both points: - to allow the TCP connection to be long-lived would be desirable, at least as an option - there is no conflict with MRB, whether the Query MRB or Inline MRB flavor [Didn't have anything useful to say wrt your Comment 1. Points noted. :-) ] Cheers, Gary -----Original Message----- From: Garland Sharratt [mailto:gsharratt@convedia.com] Sent: Wednesday, May 10, 2006 9:42 AM To: 'Tom-PT Taylor'; Munson,Gary A (Gary) Cc: mediactrl@lists.ubiquitysoftware.com Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft Tom, Gary, a few belated comments on your two emails together: 1. Dumb media server vs. smart media server. I don't agree that an H.248 MS is dumb and a SIP MS is smarter. If you look at an H.248 media server and a SIP media server, there is no real difference between them. Both do the same job, media processing. Yes, the control interface looks different, but they are both doing playing, recording, DTMF collection, conference mixing, etc. Yes, pure VoiceXML (pure = no call control, e.g., "transfer" element) is often used with SIP media servers and not with H.248 media servers, but this doesn't change the role or function of a media server, which is to perform media processing under the total control of an external application. 2. Inline MRB vs. Query MRB I don't really have an axe to grind on either side but based on what I know at this time I don't agree that the Query MRB is better than the Inline MRB. The Query MRB needs new protocols and interfaces defined, whereas the Inline MRB doesn't. For this reason the Inline MRB seems more elegant to me. (Incidentally, moving to a TCP channel instead of SIP INFO, see below, removes one of the objections to the Inline MRB, that in order for it to have visibility of BYE messages (which is necessary for resource control purposes) it needs to also flow through all the SIP INFO messages, which is inefficient.) The last time I looked at the MSF has only the Inline MRB, not the Query MRB. Tom, has this really changed? 3. Separate TCP control channel negotiated by SIP I think that for efficiently reasons such a TCP channel needs to be: (a) long lived, and (b) used to control multiple RTP streams. For example, one very viable way to use these channels would be to have *one* such long-live TCP channel set up between each combination of AS and MS, at restart time. The AS would use the one TCP channel to control all its RTP streams on that MS. So if there were N ASs and M MSs, there would be N x M control channels, assuming all ASs had access to all MSs. Perhaps there could also be a time-out mechanism that might tear down a TCP channel if it hadn't been used in an hour, if this was valuable for some reason. And of course if a particular MS isn't useable by a particular AS, there would be no TCP channel. I don't see a conflict between having these long-lived TCP channels and the presence of the MRB. Comments welcome. Garland -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Tom-PT Taylor Sent: Wednesday, February 15, 2006 08:24 To: gamunson@att.com Cc: mediactrl@lists.ubiquitysoftware.com Subject: Re: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft The MSF has taken the Media Resource Broker into its architecture, with two different SIP interfaces. The first requests media resources of a specific type, with a URI to a media server as a return result. The second has the MRB acting as a proxy (optional) between the client and the Media Server. I'll confess that in the short term the MSF is using SIP INFO transport. (Strong influence by specific vendors here.) However, if this architecture were to persist but with the SIP setting up separate control channels, I find it hard to picture those channels remaining up once the individual call is completed. Control channels persisting for longer than the duration of an individual usage (call) imply a tighter relationship between the AS and the MS than I think compatible with the role of a media resource broker. gamunson@att.com wrote: > Hi folks, > > I'll throw in my views here on some topics that have been in the recent emails, say from February 4 onward. > > 1) It seems that there are two basic concepts of what is meant by Media Server > a) the really dumb kind (a la IMS MRFP) > b) the one that can be smarter (a la IMS MRFC + MRFP) > > * I believe that the AS-MS protocol that the Mediactrl BoF should be fundamentally addressing is (b); but it should be extensible to allow finer control granularity. In a practical architecture, it should be possible for the AS to tell the MS to do routine tricks on its own (e.g., roll over, fetch a stick, bite the mailman) without the AS controlling every itsy-bitsy step. So, yes, something like VXML on the MS makes perfectly good sense. On the other hand, to preclude a potentially finer level of control for some applications seems unwise. > > 2) While I used above the representation of the 'smarter' MS as IMS MRFC +MRFP, as have others, it has a flaw. The IMS MRFC consists of two functions. One is the MRFP control function, which is okay to be part of the MS. But the MRFC also has a media resource *assignment* function. At the network level, that assignment function cannot be part of a Media Server. (Local resource assignment among a cluster of servers is a different matter.) [One other side note - in an earlier mail, the AS-MS control interface was referred to, in IMS terms, as the Mr interface. On the MS side that's fine. However, in the IMS pictures I have seen, the Mr interface has as its other endpoint the S-CSCF, not the AS.] > > * That MS assignment function is related to topics that came in multiple earlier emails about MS discovery, and whether we're assuming a static connection between an AS and MS, and whether the resource management function lives 'below S-CSCF'. > One of the scenarios we need to allow for is a many-to-many AS-MS relationship where the MS resources are a shared pool across many different services residing on many ASes, with tons of traffic with variations in volumes, some predictable, some not, and where MS resources are not infinite and the MS boxes don't all have the same size or capability set, and services don't all have the same priority, etc.. In such as case, we want to > - Allow for a network-level MS assignment function (referred to as a Media Server Resource Broker or just Media Resource Broker); one model of the way MSRB works (e.g., recent work in the ATIS-PTSC and in the ITU-T NGN based on a set of requirements), is for an AS to query the MSRB when it wants MS resources. The MSRB responds to the AS with identified MS resources that it allocates to that AS. When the AS is done with its assigned MS resources, it releases them back to the MSRB. In that model, the MSRB doesn't have to live below, and can be unrelated to, S-CSCF. There is another model of MRB that would live below S-CSCF, but it doesn't support as broad a set of needs as the AS-MSRB model described here. > - Allow for more than just a static AS-MS control channel situation. > In short, while recognizing the topics of MS 'discovery' and/or MS resource management/allocation as important, they should remain outside the scope of the BoF AS-MS protocol effort, and we should allow the AS-MS control channel connection situation to be fluid. > > Next, a couple comments for Chris & co on the "A Control Framework for SIP" draft, staying out of the Control Package fray, and questions about which protocol might be a chicken or an egg :-) -- > > A) I resonate strongly with the option of having a separate AS-MS control channel set up by SIP, and TCP for transport is good. Here are some additional points to potentially clarify: > a) *Must* the control channel be established before a call leg is brought to the Media Server? The Control Framework for SIP draft seems to only talk about setting up the control channel before a call leg is brought to the MS. It might be useful to allow for both. > b) Can a single control channel be used to control multiple calls at the MS (using the same control package)? For example, 10 simultaneous IVR sessions? I believe the intent is to allow that, but I didn't see words to that effect. > c) Can different control packages be run over the same control channel? For example, one for simultaneous calls for IVR and another for conferences? I don't have a strong feeling about that one, but it should be clarified. > > B) The 'Control Framework for SIP' draft places the Control Package-related information at the SIP-level (the Control Packages header etc.) in SIP messages. An alternative would be to place that information in an SDP or SDP-like description as payload, similar to establishing media sessions using SIP. I wonder whether there was any discussion around the pros and cons of doing the latter? [I do realize media channels and control channels are not the same thing]. Take this question as one that is a mild push-back, and perhaps based on ignorance as much as anything. > > Cheers, > > Gary Munson > > > > > -------------------------- > Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. > Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. > > -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From EBurger@cantata.com Tue, 16 May 2006 17:30:28 +0100 From: "Burger, Eric" Date: Tue, 16 May 2006 17:30:28 +0100 To: "Garland Sharratt" Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft Message-ID: <330A23D8336C0346B5C1A5BB1966664702E02845@ATLANTIS.Brooktrout.com> MIME-Version: 1.0 Content-Type: text/plain I would offer that there can be nothing further apart than the model, and thus application space, offered by H.248 (device control) and SIP+XML (where the XML is not just encapsulated MGCP). I will very quickly concede that you can do anything in H.248. It just takes more protocol messages, much more complex applications, and sophisticated controllers. Saying a media server "just does media processing" totally misses the point. If that were the case, I would offer that SMIL has been around a lot longer and has many more implementations. Why don't we use HTTP/SMIL for media servers? It is because the programming and deployment model is entirely different from what people want to use media servers for. -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Garland Sharratt Sent: Wednesday, May 10, 2006 9:42 AM To: 'Tom-PT Taylor'; Gary Munson [AT&T] Cc: mediactrl@lists.ubiquitysoftware.com Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft Tom, Gary, a few belated comments on your two emails together: 1. Dumb media server vs. smart media server. I don't agree that an H.248 MS is dumb and a SIP MS is smarter. If you look at an H.248 media server and a SIP media server, there is no real difference between them. Both do the same job, media processing. Yes, the control interface looks different, but they are both doing playing, recording, DTMF collection, conference mixing, etc. Yes, pure VoiceXML (pure = no call control, e.g., "transfer" element) is often used with SIP media servers and not with H.248 media servers, but this doesn't change the role or function of a media server, which is to perform media processing under the total control of an external application. 2. Inline MRB vs. Query MRB I don't really have an axe to grind on either side but based on what I know at this time I don't agree that the Query MRB is better than the Inline MRB. The Query MRB needs new protocols and interfaces defined, whereas the Inline MRB doesn't. For this reason the Inline MRB seems more elegant to me. (Incidentally, moving to a TCP channel instead of SIP INFO, see below, removes one of the objections to the Inline MRB, that in order for it to have visibility of BYE messages (which is necessary for resource control purposes) it needs to also flow through all the SIP INFO messages, which is inefficient.) The last time I looked at the MSF has only the Inline MRB, not the Query MRB. Tom, has this really changed? 3. Separate TCP control channel negotiated by SIP I think that for efficiently reasons such a TCP channel needs to be: (a) long lived, and (b) used to control multiple RTP streams. For example, one very viable way to use these channels would be to have *one* such long-live TCP channel set up between each combination of AS and MS, at restart time. The AS would use the one TCP channel to control all its RTP streams on that MS. So if there were N ASs and M MSs, there would be N x M control channels, assuming all ASs had access to all MSs. Perhaps there could also be a time-out mechanism that might tear down a TCP channel if it hadn't been used in an hour, if this was valuable for some reason. And of course if a particular MS isn't useable by a particular AS, there would be no TCP channel. I don't see a conflict between having these long-lived TCP channels and the presence of the MRB. Comments welcome. Garland -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Tom-PT Taylor Sent: Wednesday, February 15, 2006 08:24 To: gamunson@att.com Cc: mediactrl@lists.ubiquitysoftware.com Subject: Re: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft The MSF has taken the Media Resource Broker into its architecture, with two different SIP interfaces. The first requests media resources of a specific type, with a URI to a media server as a return result. The second has the MRB acting as a proxy (optional) between the client and the Media Server. I'll confess that in the short term the MSF is using SIP INFO transport. (Strong influence by specific vendors here.) However, if this architecture were to persist but with the SIP setting up separate control channels, I find it hard to picture those channels remaining up once the individual call is completed. Control channels persisting for longer than the duration of an individual usage (call) imply a tighter relationship between the AS and the MS than I think compatible with the role of a media resource broker. gamunson@att.com wrote: > Hi folks, > > I'll throw in my views here on some topics that have been in the recent emails, say from February 4 onward. > > 1) It seems that there are two basic concepts of what is meant by Media Server > a) the really dumb kind (a la IMS MRFP) > b) the one that can be smarter (a la IMS MRFC + MRFP) > > * I believe that the AS-MS protocol that the Mediactrl BoF should be fundamentally addressing is (b); but it should be extensible to allow finer control granularity. In a practical architecture, it should be possible for the AS to tell the MS to do routine tricks on its own (e.g., roll over, fetch a stick, bite the mailman) without the AS controlling every itsy-bitsy step. So, yes, something like VXML on the MS makes perfectly good sense. On the other hand, to preclude a potentially finer level of control for some applications seems unwise. > > 2) While I used above the representation of the 'smarter' MS as IMS MRFC +MRFP, as have others, it has a flaw. The IMS MRFC consists of two functions. One is the MRFP control function, which is okay to be part of the MS. But the MRFC also has a media resource *assignment* function. At the network level, that assignment function cannot be part of a Media Server. (Local resource assignment among a cluster of servers is a different matter.) [One other side note - in an earlier mail, the AS-MS control interface was referred to, in IMS terms, as the Mr interface. On the MS side that's fine. However, in the IMS pictures I have seen, the Mr interface has as its other endpoint the S-CSCF, not the AS.] > > * That MS assignment function is related to topics that came in multiple earlier emails about MS discovery, and whether we're assuming a static connection between an AS and MS, and whether the resource management function lives 'below S-CSCF'. > One of the scenarios we need to allow for is a many-to-many AS-MS relationship where the MS resources are a shared pool across many different services residing on many ASes, with tons of traffic with variations in volumes, some predictable, some not, and where MS resources are not infinite and the MS boxes don't all have the same size or capability set, and services don't all have the same priority, etc.. In such as case, we want to > - Allow for a network-level MS assignment function (referred to as a Media Server Resource Broker or just Media Resource Broker); one model of the way MSRB works (e.g., recent work in the ATIS-PTSC and in the ITU-T NGN based on a set of requirements), is for an AS to query the MSRB when it wants MS resources. The MSRB responds to the AS with identified MS resources that it allocates to that AS. When the AS is done with its assigned MS resources, it releases them back to the MSRB. In that model, the MSRB doesn't have to live below, and can be unrelated to, S-CSCF. There is another model of MRB that would live below S-CSCF, but it doesn't support as broad a set of needs as the AS-MSRB model described here. > - Allow for more than just a static AS-MS control channel situation. > In short, while recognizing the topics of MS 'discovery' and/or MS resource management/allocation as important, they should remain outside the scope of the BoF AS-MS protocol effort, and we should allow the AS-MS control channel connection situation to be fluid. > > Next, a couple comments for Chris & co on the "A Control Framework for SIP" draft, staying out of the Control Package fray, and questions about which protocol might be a chicken or an egg :-) -- > > A) I resonate strongly with the option of having a separate AS-MS control channel set up by SIP, and TCP for transport is good. Here are some additional points to potentially clarify: > a) *Must* the control channel be established before a call leg is brought to the Media Server? The Control Framework for SIP draft seems to only talk about setting up the control channel before a call leg is brought to the MS. It might be useful to allow for both. > b) Can a single control channel be used to control multiple calls at the MS (using the same control package)? For example, 10 simultaneous IVR sessions? I believe the intent is to allow that, but I didn't see words to that effect. > c) Can different control packages be run over the same control channel? For example, one for simultaneous calls for IVR and another for conferences? I don't have a strong feeling about that one, but it should be clarified. > > B) The 'Control Framework for SIP' draft places the Control Package-related information at the SIP-level (the Control Packages header etc.) in SIP messages. An alternative would be to place that information in an SDP or SDP-like description as payload, similar to establishing media sessions using SIP. I wonder whether there was any discussion around the pros and cons of doing the latter? [I do realize media channels and control channels are not the same thing]. Take this question as one that is a mild push-back, and perhaps based on ignorance as much as anything. > > Cheers, > > Gary Munson > > > > > -------------------------- > Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. > Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. > > -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From gsharratt@convedia.com Wed, 17 May 2006 23:36:24 +0100 From: "Garland Sharratt" Date: Wed, 17 May 2006 23:36:24 +0100 To: Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft - MRB In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702E02845@ATLANTIS.Brooktrout.com> Message-ID: <014c01c67a02$9c2c25a0$c63c14ac@wwvnu073> MIME-Version: 1.0 Content-Type: text/plain Of course I believe that SIP media servers are better (easier to use, more flexible, etc.) than H.248 or MGCP media servers. That's not being debated here. Some vendors (mostly NEPs) will tend toward H.248, while (IMO) most vendors (mostly app vendors) will tend toward SIP. I don't think this is likely to change in the near term, although I hope SIP wins out in the long term. The key thing is that a media server is a media server: a device whose purpose is to do media processing on media streams. Whether it's SIP, MGCP, H.248, SMIL, or RS-232, it's still a media server. Is the SIP one better? Yes, of course, but it's still doing the same kinds of things that an H.248 media server does: play, record, mix, DTMF, etc. But the real issue in all this protocol debate, in my view, is that there is a discontinuity between what in the market and what's in the IMS architecture. The market has mostly SIP media servers and some H.248 media servers. IMS has an H.248 media server (it's the MRFP) but *not* a SIP media server: the MRF is a superset of a SIP media server, loaded with functions that don't fit a pure media server. The MRF is the closest thing to a SIP media server. But if SIP media servers become MRFs to fit into IMS, where is the media resource broker (MRB) function done? Large service providers are asking for a separate (physical) MRB component in their networks. IMS doesn't have an explicit MRB as it was assumed that, since the media servers are the MRFPs, the MRB function would be done in the MRFC. But if the media server is the MRF, there is no separate MRFC to do the MRB role. Does anyone see a solution to this? -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Burger, Eric Sent: Tuesday, May 16, 2006 09:33 To: Garland Sharratt Cc: mediactrl@lists.ubiquitysoftware.com Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft I would offer that there can be nothing further apart than the model, and thus application space, offered by H.248 (device control) and SIP+XML (where the XML is not just encapsulated MGCP). I will very quickly concede that you can do anything in H.248. It just takes more protocol messages, much more complex applications, and sophisticated controllers. Saying a media server "just does media processing" totally misses the point. If that were the case, I would offer that SMIL has been around a lot longer and has many more implementations. Why don't we use HTTP/SMIL for media servers? It is because the programming and deployment model is entirely different from what people want to use media servers for. -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Garland Sharratt Sent: Wednesday, May 10, 2006 9:42 AM To: 'Tom-PT Taylor'; Gary Munson [AT&T] Cc: mediactrl@lists.ubiquitysoftware.com Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft Tom, Gary, a few belated comments on your two emails together: 1. Dumb media server vs. smart media server. I don't agree that an H.248 MS is dumb and a SIP MS is smarter. If you look at an H.248 media server and a SIP media server, there is no real difference between them. Both do the same job, media processing. Yes, the control interface looks different, but they are both doing playing, recording, DTMF collection, conference mixing, etc. Yes, pure VoiceXML (pure = no call control, e.g., "transfer" element) is often used with SIP media servers and not with H.248 media servers, but this doesn't change the role or function of a media server, which is to perform media processing under the total control of an external application. 2. Inline MRB vs. Query MRB I don't really have an axe to grind on either side but based on what I know at this time I don't agree that the Query MRB is better than the Inline MRB. The Query MRB needs new protocols and interfaces defined, whereas the Inline MRB doesn't. For this reason the Inline MRB seems more elegant to me. (Incidentally, moving to a TCP channel instead of SIP INFO, see below, removes one of the objections to the Inline MRB, that in order for it to have visibility of BYE messages (which is necessary for resource control purposes) it needs to also flow through all the SIP INFO messages, which is inefficient.) The last time I looked at the MSF has only the Inline MRB, not the Query MRB. Tom, has this really changed? 3. Separate TCP control channel negotiated by SIP I think that for efficiently reasons such a TCP channel needs to be: (a) long lived, and (b) used to control multiple RTP streams. For example, one very viable way to use these channels would be to have *one* such long-live TCP channel set up between each combination of AS and MS, at restart time. The AS would use the one TCP channel to control all its RTP streams on that MS. So if there were N ASs and M MSs, there would be N x M control channels, assuming all ASs had access to all MSs. Perhaps there could also be a time-out mechanism that might tear down a TCP channel if it hadn't been used in an hour, if this was valuable for some reason. And of course if a particular MS isn't useable by a particular AS, there would be no TCP channel. I don't see a conflict between having these long-lived TCP channels and the presence of the MRB. Comments welcome. Garland -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Tom-PT Taylor Sent: Wednesday, February 15, 2006 08:24 To: gamunson@att.com Cc: mediactrl@lists.ubiquitysoftware.com Subject: Re: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft The MSF has taken the Media Resource Broker into its architecture, with two different SIP interfaces. The first requests media resources of a specific type, with a URI to a media server as a return result. The second has the MRB acting as a proxy (optional) between the client and the Media Server. I'll confess that in the short term the MSF is using SIP INFO transport. (Strong influence by specific vendors here.) However, if this architecture were to persist but with the SIP setting up separate control channels, I find it hard to picture those channels remaining up once the individual call is completed. Control channels persisting for longer than the duration of an individual usage (call) imply a tighter relationship between the AS and the MS than I think compatible with the role of a media resource broker. gamunson@att.com wrote: > Hi folks, > > I'll throw in my views here on some topics that have been in the recent emails, say from February 4 onward. > > 1) It seems that there are two basic concepts of what is meant by Media Server > a) the really dumb kind (a la IMS MRFP) > b) the one that can be smarter (a la IMS MRFC + MRFP) > > * I believe that the AS-MS protocol that the Mediactrl BoF should be fundamentally addressing is (b); but it should be extensible to allow finer control granularity. In a practical architecture, it should be possible for the AS to tell the MS to do routine tricks on its own (e.g., roll over, fetch a stick, bite the mailman) without the AS controlling every itsy-bitsy step. So, yes, something like VXML on the MS makes perfectly good sense. On the other hand, to preclude a potentially finer level of control for some applications seems unwise. > > 2) While I used above the representation of the 'smarter' MS as IMS MRFC +MRFP, as have others, it has a flaw. The IMS MRFC consists of two functions. One is the MRFP control function, which is okay to be part of the MS. But the MRFC also has a media resource *assignment* function. At the network level, that assignment function cannot be part of a Media Server. (Local resource assignment among a cluster of servers is a different matter.) [One other side note - in an earlier mail, the AS-MS control interface was referred to, in IMS terms, as the Mr interface. On the MS side that's fine. However, in the IMS pictures I have seen, the Mr interface has as its other endpoint the S-CSCF, not the AS.] > > * That MS assignment function is related to topics that came in multiple earlier emails about MS discovery, and whether we're assuming a static connection between an AS and MS, and whether the resource management function lives 'below S-CSCF'. > One of the scenarios we need to allow for is a many-to-many AS-MS relationship where the MS resources are a shared pool across many different services residing on many ASes, with tons of traffic with variations in volumes, some predictable, some not, and where MS resources are not infinite and the MS boxes don't all have the same size or capability set, and services don't all have the same priority, etc.. In such as case, we want to > - Allow for a network-level MS assignment function (referred to as a Media Server Resource Broker or just Media Resource Broker); one model of the way MSRB works (e.g., recent work in the ATIS-PTSC and in the ITU-T NGN based on a set of requirements), is for an AS to query the MSRB when it wants MS resources. The MSRB responds to the AS with identified MS resources that it allocates to that AS. When the AS is done with its assigned MS resources, it releases them back to the MSRB. In that model, the MSRB doesn't have to live below, and can be unrelated to, S-CSCF. There is another model of MRB that would live below S-CSCF, but it doesn't support as broad a set of needs as the AS-MSRB model described here. > - Allow for more than just a static AS-MS control channel situation. > In short, while recognizing the topics of MS 'discovery' and/or MS resource management/allocation as important, they should remain outside the scope of the BoF AS-MS protocol effort, and we should allow the AS-MS control channel connection situation to be fluid. > > Next, a couple comments for Chris & co on the "A Control Framework for SIP" draft, staying out of the Control Package fray, and questions about which protocol might be a chicken or an egg :-) -- > > A) I resonate strongly with the option of having a separate AS-MS control channel set up by SIP, and TCP for transport is good. Here are some additional points to potentially clarify: > a) *Must* the control channel be established before a call leg is brought to the Media Server? The Control Framework for SIP draft seems to only talk about setting up the control channel before a call leg is brought to the MS. It might be useful to allow for both. > b) Can a single control channel be used to control multiple calls at the MS (using the same control package)? For example, 10 simultaneous IVR sessions? I believe the intent is to allow that, but I didn't see words to that effect. > c) Can different control packages be run over the same control channel? For example, one for simultaneous calls for IVR and another for conferences? I don't have a strong feeling about that one, but it should be clarified. > > B) The 'Control Framework for SIP' draft places the Control Package-related information at the SIP-level (the Control Packages header etc.) in SIP messages. An alternative would be to place that information in an SDP or SDP-like description as payload, similar to establishing media sessions using SIP. I wonder whether there was any discussion around the pros and cons of doing the latter? [I do realize media channels and control channels are not the same thing]. Take this question as one that is a mild push-back, and perhaps based on ignorance as much as anything. > > Cheers, > > Gary Munson > > > > > -------------------------- > Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. > Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. > > -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From EBurger@cantata.com Fri, 19 May 2006 23:38:15 +0100 From: "Burger, Eric" Date: Fri, 19 May 2006 23:38:15 +0100 To: Subject: RE: [mediactrl] How to get this work into a WG Message-ID: <330A23D8336C0346B5C1A5BB196666470231C479@ATLANTIS.Brooktrout.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [mediactrl] How to get this work into a WG chair-hat: off Agreed. Chair-hat: on Absolutely! -- Sent from my Palm Treo - Sorry if Terse -----Original Message----- From: Adnan Saleem [mailto:asaleem@convedia.com] Sent: Tuesday, May 16, 2006 01:46 AM Eastern Standard Time To: Cullen Jennings; mediactrl@lists.ubiquitysoftware.com Subject: RE: [mediactrl] How to get this work into a WG Hi Cullen, The SpeechSC WG would be ok for mediactrl work, if the charter of this WG is changed to make it clear that the MS work and the Speech Server (SS) work are completely separate. SpeechSC in the past has occasionally expressed interest in turning MRCP into a full media server control interface, and we want to make sure that is clarified and prevented by the group's charter. Thanks Adnan -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com]On Behalf Of Cullen Jennings Sent: May 7, 2006 8:11 AM To: MixerControl Subject: [mediactrl] How to get this work into a WG A long time ago, we had talked about asking the SpeachSC chairs if that WG might take on this work. Is there still interest in that? With my AD hat on, I have no idea what is the best way to do this yet but I am looking for input on what the next logical steps are with all the work that has been happing here. Thanks, Cullen PS - A short summary of the status of where we are, what we have, and where various parties might want to eventually get to might be really helpful for me. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From roni.even@polycom.co.il Sun, 21 May 2006 13:47:34 +0100 From: "Even, Roni" Date: Sun, 21 May 2006 13:47:34 +0100 To: "Chris Boulton" Subject: RE: [mediactrl] How to get this work into a WG Message-ID: <144ED8561CE90C41A3E5908EDECE315C038B5020@IsrExch01.israel.polycom.com> MIME-Version: 1.0 Content-Type: text/plain Hi During the last meeting I mentioned the requirement document I wrote when we started the work. It is attached here; I thought it will be added to the list of document in http://flyingfox.cantata.com/i-d/mediactrl/   BTW: I agree with Chris answers about the work and want to mention that MSML and MSCML are not the only proprietary protocols that support this interface. Polycom has its XML API that supports this functionality and MS has proposed CCCP for the protocol. I think that the consensus was to define a protocol that will be inline with the requirements and the framework and not to point at some vendors implementations. Of course we can leverage the knowledge that was learnt by the manufacturers to create a good solution as fast as we can. Regards Roni Even   From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Chris Boulton Sent: Tuesday, May 09, 2006 3:40 PM To: Adnan Saleem; Cullen Jennings; mediactrl@lists.ubiquitysoftware.com Cc: Burger, Eric Subject: RE: [mediactrl] How to get this work into a WG     Cullen, I want to point out that we have rough consensus (imho) on the "control framework" ID (http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt), from an architectural perspective and the direction this is going. [Chris Boulton] That’s really good to hear. However, there is no consensus on the remaining IDs identified below.   [Chris Boulton] I’m not sure consensus was at all proposed – certainly not by me.  That’s jumping the gun a little.  I was just pointing out that we have current examples of how Control Packages are written in-line with the framework.   Convedia in particular objects to the "extension" IDs listed below, covering IVR and conference control.         - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt).       - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt).       - (http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt).   The above new IDs essentially provide a subset and duplication of the what MSML, and MSCML to a good extent, have already provided for years.   [Chris Boulton] Totally understand your position.  All I will say is that:-   -          yes, you are correct in that this does provide duplication of MSML and MSCML.  The intention was to use and build on the experiences gained from such languages to provide a solution that architecturally fits with the new Control Framework. -          Yes it provides subsets of functionality.  This again was the intention to provide a modular approach.  We are thinking (and received quite a large amount of feedback from media control group) from the agnostic point of view that not everyone wants to implement a large scripting language for simple IVR interactions.  It should be possible to select exactly what you need to fit your requirements.   If you have got any more detail on your technical objections I think it would be great to have some discussion.   Best Regards,   Chris.       Garland / Adnan -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com]On Behalf Of Chris Boulton Sent: May 8, 2006 2:36 AM To: Cullen Jennings; MixerControl Cc: Burger, Eric Subject: RE: [mediactrl] How to get this work into a WG Hi Cullen (donning AD cap), We are still very much actively discussing this work and have met at every IETF since Paris (I think) - including a Beer BOF and a Meal BOF :-).         A long time ago, we had talked about asking the SpeachSC chairs if          that WG might take on this work. Is there still interest in that?          Very much so - we have been discussing this regularly and I think we had hoped (Eric will confirm but I know he is snowed under at the moment) to move towards IETF working group towards the end of this year/maybe early next.         PS - A short summary of the status of where we are, what we have, and          where various parties might want to eventually get to might be really          helpful for me. We are at the point where we have a Control Framework which has been discussed at length at previous meetings (http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework -02.txt) which aims to fulfill the detail outlined in the Requirements document (http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01 .txt).  This is an agnostic approach that is not 'Media Server' specific and aims to provide a core connection management system using SIP. The authors of the Framework have also created a number of extensions to the Control Framework that provides modules for achieving various levels of Media Server Control. - First extension provides simple IVR functionality (http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-0 1.txt). - There is an extension to the SIMPLE IVR functionality for the purpose of using VXML (http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-pack age-00.txt). - This extensions provides conferencing capabilities (http://www.ietf.org/internet-drafts/draft-boulton-conference-control-pa ckage-00.txt). If you need anymore information then give me a shout. Best Regards, Chris. -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Cullen Jennings Sent: 07 May 2006 16:11 To: MixerControl Subject: [mediactrl] How to get this work into a WG A long time ago, we had talked about asking the SpeachSC chairs if  that WG might take on this work. Is there still interest in that?  With my AD hat on, I have no idea what is the best way to do this yet  but I am looking for input on what the next logical steps are with  all the work that has been happing here. Thanks, Cullen PS - A short summary of the status of where we are, what we have, and  where various parties might want to eventually get to might be really  helpful for me. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. XCON R. Even Internet-Draft Polycom Expires: July 28, 2005 January 27, 2005 Requirements for a media server control protocol draft-even-media-server-req-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 28, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document addresses the communication between an application server and media server. The current work in SIPPING and XCON working groups show these logical functions but do not address the physical decomposition and the protocol between the entities. The document presents the architecture and the requirements from the protocol. The document lists current work that is relevant to the problem. Even Expires July 28, 2005 [Page 1] Internet-Draft Media Server January 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Current protocols . . . . . . . . . . . . . . . . . . . . . 10 6. IANA consideration . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . 13 8. Informative References . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 14 Even Expires July 28, 2005 [Page 2] Internet-Draft Media Server January 2005 1. Introduction The IETF SIPPING conferencing framework[CARCH] presents an architecture that is built of several functional entities. The framework document does not specify the protocols between the functional entities since it is considered out of scope. There is an interest to work on a protocol that will enable one physical entity that includes the conference/media policy server, notification server and the focus to interact with one or more physical entities that serves as mixer or media server. The document will present the requirements for such a protocol. It will address all phases and aspects of media handling in a conferencing service including announcements and IVR functionality. Even Expires July 28, 2005 [Page 3] Internet-Draft Media Server January 2005 2. Terminology The Media Server work uses, when appropriate, and expands on the terminology introduced in the SIPPING conferencing framework[CARCH]. The following additional terms are defined for use within the Media Server work. Application Server (AS) - The application server includes the conference policy server, the focus and the conference notification server as defined in draft-ietf-sipping-conferencing-framework.[CARCH] Media Server (MS) - The media server includes the mixer as defined in draft-ietf-sipping-conferencing-framework[CARCH] The media server source media streams for announcements, it process media streams for functions like DTMF detection and transcoding. The media server may also record media streams for supporting IVR functions like announcing participants. Even Expires July 28, 2005 [Page 4] Internet-Draft Media Server January 2005 3. Architecture The proposed architecture is composed of an application server (AS) and a media server (MS). This section does not define any specific model for the interaction between the AS and MS. It does assume that every interaction from the participant to the MS will be controlled by the AS. The MS only handles data and may tunnel controls received in the media streams to the AS (e.g. DTMF). The assumption is that the external protocols to these entities will be based on the IETF work. The Conference aware participants will use XCON protocols to the AS. The signaling protocol between the Participants and the AS will be SIP. The media between the Participants and the MS will be RTP based. The solution may work for other signaling protocols like H.323. The MS functionality includes: - Control of the RTP streams. - Mixing of incoming media streams. - Media stream source (for multimedia announcements). - Media stream processing (e.g. transcoding, DTMF detection). - Media stream sink ( Support announcing participants names) The AS functionality includes: - Creation and management of conferences by conference aware participants. - Creation of conference service logic using other mechanism which may be standard or non-standard. Example is to create an IVR based conference service. - Manage the conference flow in the MS from start to finish. The following diagram describes the architecture. The purpose of the work is to address the AS-MS protocol. Even Expires July 28, 2005 [Page 5] Internet-Draft Media Server January 2005 _____________ XCON Protocol | Application | +---------------------------| Server | | |_____________| | | | | | | | | | _____________ _______ SIP | | | | SIP | |---------+ |AS-MS | Participant |---------| SIP | |Protocol |_____________| | Proxy | | |_______|----------+ | SIP | | | | ________ | | | Media | | Server | |________| Even Expires July 28, 2005 [Page 6] Internet-Draft Media Server January 2005 4. Requirements This section addresses only the requirements. The requirements will be divided to general protocol requirements and to specific service logic requirements. General protocol 1. The Media server control messages shall be sent over a reliable connection. 2. The protocol shall enable one AS to work with multiple MS. 3. The protocol should enable many AS to work with the same MS 4. The AS should be able to find the MS and connect to it. 5. The MS shall be able to inform the AS about it status. 6. The protocol should be extendable. 7. The MS shall be able to tell the AS its capacities. 8. The MS shall be able to tell the AS its functionality (Mixing, IVR, Announcements) 9. The AS shall be able to request the MS to create, delete, and manipulate a mixing, IVR or announcement session 10. The MS shall supply the media addresses (RTP transport address) to be used to the AS. 11. The MS should send a summary report when the session is terminated by the AS. 12. The AS should be able to request call/session and conference state from the MS. 13. The MS should support DTMF detection (in band tones and RFC2833) 14. The protocol shall include redundancy procedures. 15. The protocol shall include security mechanisms. 16. The AS should be able to reserve resources on the MS. The resources models should be simple. (this requirement needs more discussion) Even Expires July 28, 2005 [Page 7] Internet-Draft Media Server January 2005 17. The MS may support resource reservation and shall report the support in the initial connection to the AS. 18. The MS shall inform the AS about any changes in it capacities. The changes may be due to reservation, internal usage or due to some malfunction. 19. The AS shall be able to tell the MS which stream parameters to use on incoming and out going streams. Stream parameters may be for example codec parameters (video codec features) or bit rates. This requirement will help the MS to allocate the right resources. 20. The AS shall be able to define operations that the MS will perform on streams like mute and gain control. 21. The MS shall supply the AS with sufficient information for the event package. Announcements Announcements may include voice, audio, slides or video clips. 1. The AS shall be able to instruct the MS to play a specific announcement. 2. The MS shall be able to retrieve announcements from an external connection. 3. The AS shall be able to tell the MS if the message can be delayed if the MS cannot play it immediately. 4. The AS shall be able to instruct the MS to play announcements to a single user or to a conference mix. Media mixing 1. The AS shall be able to define a conference mix. 2. The AS may be able to define a separate mix for each participant. 3. The AS shall be able to define the relationship between two mixes, for example a pair of audio and video for lip-synch or for voice activated video switch 4. The AS may be able to define a custom video layout built of rectangular sub windows. 5. For video the AS shall be able to map a stream to a specific Even Expires July 28, 2005 [Page 8] Internet-Draft Media Server January 2005 sub-window or to define to the MS how to decide which stream will go to each sub window. The number of sub-windows will start from one. 6. The MS shall be able to inform the AS who is the active speaker. 7. The AS may be able to cascade mixers ( side bar with whisper mode) 8. The MS shall be able to inform the AS which layouts it supports. IVR 1. The AS shall be able to load an IVR script to the MS and receive the result 2. The AS shall be able to mange the IVR session by sending announcements and receiving the response (DTMF) 3. The AS should be able to instruct the MS to record a short participant stream and play it back to the conference. This is not a recording requirement. Even Expires July 28, 2005 [Page 9] Internet-Draft Media Server January 2005 5. Current protocols Currently there are a few protocols that try to address this architecture. The IETF drafts and ITU standards include: 1. draft-vandyke-mscml-05 [MSCML] 2. draft-melanchuk-sipping-msml-03[MSML] 3. draft-melanchuk-sipping-moml-03[MOML] 4. draft-burger-sipping-netann-10[NETANN] 5. draft-levin-xcon-cccp-00[CCCP] 6. ITU H.248.19 - Decomposed multipoint control unit, audio, video and data conferencing packages[ITU.H248.19] Note: The list is to the best of my knowledge and the order is meaningless A short overview of the drafts based on my poor understanding is given here please feel free to correct my mistakes. MSML[MSML] Convedia MSML (Media Sessions Mark-up Language)[MSML]. The latest version added support for video. MSML addresses the relationships of media streams MSML defines an XML schema that enables the AS to create sessions on the MS. The draft outlines how to use SIP as a transport for the XML schema by using SIP invite to create a control session between the AS and the MS. Subsequent control messages between the MS and AS will be done using INFO or INVITE. The control connection is only used for the transporting the XML schema. MSML supports several models for client interaction. When clients use 3PCC to establish media sessions on behalf of end users, clients will have a SIP dialog for each media session. MSML may be sent on these dialogs. However the targets of MSML actions are not inferred from the session associated with the SIP dialog. The targets of MSML actions are always explicitly specified using identifiers previously defined. The signaling from the SIP users is going to the AS. The AS is using 3pcc (third party call control) procedures to direct the SIP signaling messages to the MS. The SDP is used to open the media channel between the user and the MS while the call control is handled by the AS. This is how the users join a media session on the MS that Even Expires July 28, 2005 [Page 10] Internet-Draft Media Server January 2005 was established using the MSML schema. Convedia has a second protocol called Media Objects Mark-up Language (MOML)[MOML] that can be used to specify individual user dialog or media control commands. MSCML[MSCML] Brooktrout Technology has suggested MSCML, Media Server Control Mark-up Language. This current version supports only audio. The general functionality is similar to MSML. MSCML is using SIP Invite and Info to send the communication between the AS and MS. Like MSML it opens a control connection for the conference. The difference is that MSCML messages sent in the control connection are for the entire conference while if they are sent over the users dialogs they apply to that user. Netann[NETANN] This protocol provides a simple way to initiate an announcement, IVR or mixing session on the media server using the URI parameters. The AS can create the session bur has less control on what is happening during the session itself. Centralized Conference Control Protocol (CCCP)[CCCP] This document may be of interest since it suggests a transaction protocol that can serve the AS to MS communication. The data schema is based on the conference event package. MEGACO / H.248[ITU.H248.19] The H.248[ITU.H248.19] protocol opens a channel between a controller and a device (these can be AS and MS in our implementations). In this channel it sends command to the MS to create context and to open connections (terminations) for the media channel. The specific functionality is defined by packages that can be extended. The MS connects to it AS when it starts up and notify the AS which packages it supports and its capacities. The H.248 packages include also support for announcement and IVR. Even Expires July 28, 2005 [Page 11] Internet-Draft Media Server January 2005 6. IANA consideration None. Even Expires July 28, 2005 [Page 12] Internet-Draft Media Server January 2005 7. Security Considerations The security section will be added later 8 Informative References [CARCH] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-03 (work in progress), October 2004. [CCCP] Levin, O. and G. Kimchi, "Centralized Conference Control Protocol (CCCP)", draft-levin-xcon-cccp-00 (work in progress), October 2004. [ITU.H248.19] International Telecommunications Union, "Gateway control protocol: Decomposed multipoint control unit, audio, video and data conferencing packages", ITU-T Recommendation H.248.19, March 2004. [MOML] Sharratt, G. and T. Melanchuk, Ed., "Media Objects Markup Language (MOML)", draft-melanchuk-sipping-moml-03 (work in progress), August 2004. [MSCML] Van Dyke, J. and Eric. Burger, Ed., "Media Server Control Markup Language (MSCML) and Protocol", draft-vandyke-mscml-05 (work in progress), October 2004. [MSML] Sharratt, G. and T. Melanchuk, Ed., "Media Server Markup Language (MSML)", draft-melanchuk-sipping-msml-03 (work in progress), August 2004. [NETANN] Van Dyke, J. and Eric. Burger, Ed., "Basic Network Media Services with SIP", draft-burger-sipping-netann-10 (work in progress), October 2004. Author's Address Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel EMail: roni.even@polycom.co.il Even Expires July 28, 2005 [Page 13] Internet-Draft Media Server January 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Even Expires July 28, 2005 [Page 14] From david.burke@voxpilot.com Sun, 21 May 2006 15:10:19 +0100 From: "Dave Burke" Date: Sun, 21 May 2006 15:10:19 +0100 To: "Even, Roni" Subject: Re: [mediactrl] How to get this work into a WG In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C038B5020@IsrExch01.israel.polycom.com> Message-ID: <008501c67ce0$8f76e490$0a01a8c0@db01.voxpilot.com> MIME-Version: 1.0 Content-Type: text/plain I just want to echo my support for the approach of defining a new protocol in line with firm requirements (although note we also have draft-dolly-xcon-mediacntrlframe so some clarification of which is authoriative would be useful). I too agree that there is good support for the draft-boulton-sip-control-framework approach for a dedicated control channel. As for the protocol'smessage formats and exchange patterns,Ifind thechoose one of MSML vs MSCML debate as not terribly constructive if the presumed goal of creating an industry standard,vendor independent,protocol is to be attained. Rather, I'd like to see the group cherry pick (at a granular level) the best approaches from the pre-existing solutions. I think some formalism associated with a WGwill ultimately help this group. Dave
----- Original Message -----
From: Even, Roni To: Chris Boulton ; Adnan Saleem ; Cullen Jennings ; mediactrl@lists.ubiquitysoftware.com Cc: Burger, Eric Sent: Sunday, May 21, 2006 1:49 PM Subject: RE: [mediactrl] How to get this work into a WG Hi During the last meeting I mentioned the requirement document I wrote when we started the work. It is attached here; I thought it will be added to the list of document in http://flyingfox.cantata.com/i-d/mediactrl/ BTW: I agree with Chris answers about the work and want to mention that MSML and MSCML are not the only proprietary protocols that support this interface. Polycom has its XML API that supports this functionality and MS has proposed CCCP for the protocol. I think that the consensus was to define a protocol that will be inline with the requirements and the framework and not to point at some vendors implementations. Of course we can leverage the knowledge that was learnt by the manufacturers to create a good solution as fast as we can. Regards Roni Even
From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Chris BoultonSent: Tuesday, May 09, 2006 3:40 PMTo: Adnan Saleem; Cullen Jennings; mediactrl@lists.ubiquitysoftware.comCc: Burger, EricSubject: RE: [mediactrl] How to get this work into a WG Cullen,I want to point out that we have rough consensus (imho) on the "control framework" ID (http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt), from an architectural perspective and the direction this is going. [Chris Boulton] That?s really good to hear. However, there is no consensus on the remaining IDs identified below. [Chris Boulton] I?m not sure consensus was at all proposed ? certainly not by me. That?s jumping the gun a little. I was just pointing out that we have current examples of how Control Packages are written in-line with the framework. Convedia in particular objects to the "extension" IDs listed below, covering IVR and conference control. - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt). - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt). - (http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt). The above new IDs essentially provide a subset and duplication of the what MSML, and MSCML to a good extent,have already provided for years. [Chris Boulton] Totally understand your position. All I will say is that:- - yes, you are correct in that this does provide duplication of MSML and MSCML. The intention was to use and build on the experiences gained from such languages to provide a solution that architecturally fits with the new Control Framework. - Yes it provides subsets of functionality. This again was the intention to provide a modular approach. We are thinking (and received quite a large amount of feedback from media control group) from the agnostic point of view that not everyone wants to implement a large scripting language for simple IVR interactions. It should be possible to select exactly what you need to fit your requirements. If you have got any more detail on your technical objections I think it would be great to have some discussion. Best Regards, Chris. Garland / Adnan -----Original Message-----From: owner-mediactrl@lists.ubiquitysoftware.com[mailto:owner-mediactrl@lists.ubiquitysoftware.com]On Behalf Of ChrisBoultonSent: May 8, 2006 2:36 AMTo: Cullen Jennings; MixerControlCc: Burger, EricSubject: RE: [mediactrl] How to get this work into a WGHi Cullen (donning AD cap),We are still very much actively discussing this work and have met atevery IETF since Paris (I think) - including a Beer BOF and a Meal BOF:-). A long time ago, we had talked about asking the SpeachSC chairsif that WG might take on this work. Is there still interest inthat?Very much so - we have been discussing this regularly and I think we hadhoped (Eric will confirm but I know he is snowed under at the moment) tomove towards IETF working group towards the end of this year/maybe earlynext. PS - A short summary of the status of where we are, what wehave, and where various parties might want to eventually get to might bereally helpful for me.We are at the point where we have a Control Framework which has beendiscussed at length at previous meetings(http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt) which aims to fulfill the detail outlined in the Requirementsdocument(http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01.txt). This is an agnostic approach that is not 'Media Server' specificand aims to provide a core connection management system using SIP.The authors of the Framework have also created a number of extensions tothe Control Framework that provides modules for achieving various levelsof Media Server Control.- First extension provides simple IVR functionality(http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt).- There is an extension to the SIMPLE IVR functionality for the purposeof using VXML(http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt).- This extensions provides conferencing capabilities(http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt).If you need anymore information then give me a shout.Best Regards,Chris.-----Original Message-----From: owner-mediactrl@lists.ubiquitysoftware.com[mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of CullenJenningsSent: 07 May 2006 16:11To: MixerControlSubject: [mediactrl] How to get this work into a WGA long time ago, we had talked about asking the SpeachSC chairs ifthat WG might take on this work. Is there still interest in that?With my AD hat on, I have no idea what is the best way to do this yetbut I am looking for input on what the next logical steps are withall the work that has been happing here.Thanks, CullenPS - A short summary of the status of where we are, what we have, andwhere various parties might want to eventually get to might be reallyhelpful for me.--------------------------Ubiquity Software does not control or endorse the content, messages orinformation found in this mail list and it specifically disclaims anyliability with regard to these communications.Ubiquity Software reserves the right the restrict access to anycommunications in violation of the Terms and Conditions of Use for thiswebsite or as otherwise deemed improper.Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank you.--------------------------Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From mdolly@att.com Sun, 21 May 2006 16:30:58 +0100 From: "Dolly, Martin C, ALABS" Date: Sun, 21 May 2006 16:30:58 +0100 To: "Even, Roni" Subject: RE: [mediactrl] How to get this work into a WG In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C038B5020@IsrExch01.israel.polycom.com> Message-ID: <28F05913385EAC43AF019413F674A0170DE0C733@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Roni,   Requirements in this document are included in the current framework document. As discuss, many times, if you feel that some of the requirements in your document are not covered, then please highlight those and they will be added.   Cheers,   Martin From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Even, RoniSent: Sunday, May 21, 2006 8:49 AMTo: Chris Boulton; Adnan Saleem; Cullen Jennings; mediactrl@lists.ubiquitysoftware.comCc: Burger, EricSubject: RE: [mediactrl] How to get this work into a WG Hi During the last meeting I mentioned the requirement document I wrote when we started the work. It is attached here; I thought it will be added to the list of document in http://flyingfox.cantata.com/i-d/mediactrl/   BTW: I agree with Chris answers about the work and want to mention that MSML and MSCML are not the only proprietary protocols that support this interface. Polycom has its XML API that supports this functionality and MS has proposed CCCP for the protocol. I think that the consensus was to define a protocol that will be inline with the requirements and the framework and not to point at some vendors implementations. Of course we can leverage the knowledge that was learnt by the manufacturers to create a good solution as fast as we can. Regards Roni Even  
From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Chris BoultonSent: Tuesday, May 09, 2006 3:40 PMTo: Adnan Saleem; Cullen Jennings; mediactrl@lists.ubiquitysoftware.comCc: Burger, EricSubject: RE: [mediactrl] How to get this work into a WG     Cullen,I want to point out that we have rough consensus (imho) on the "control framework" ID (http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt), from an architectural perspective and the direction this is going. [Chris Boulton] That’s really good to hear. However, there is no consensus on the remaining IDs identified below.   [Chris Boulton] I’m not sure consensus was at all proposed – certainly not by me.  That’s jumping the gun a little.  I was just pointing out that we have current examples of how Control Packages are written in-line with the framework.   Convedia in particular objects to the "extension" IDs listed below, covering IVR and conference control.         - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt).       - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt).       - (http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt).   The above new IDs essentially provide a subset and duplication of the what MSML, and MSCML to a good extent, have already provided for years.   [Chris Boulton] Totally understand your position.  All I will say is that:-   -          yes, you are correct in that this does provide duplication of MSML and MSCML.  The intention was to use and build on the experiences gained from such languages to provide a solution that architecturally fits with the new Control Framework. -          Yes it provides subsets of functionality.  This again was the intention to provide a modular approach.  We are thinking (and received quite a large amount of feedback from media control group) from the agnostic point of view that not everyone wants to implement a large scripting language for simple IVR interactions.  It should be possible to select exactly what you need to fit your requirements.   If you have got any more detail on your technical objections I think it would be great to have some discussion.   Best Regards,   Chris.       Garland / Adnan -----Original Message-----From: owner-mediactrl@lists.ubiquitysoftware.com[mailto:owner-mediactrl@lists.ubiquitysoftware.com]On Behalf Of ChrisBoultonSent: May 8, 2006 2:36 AMTo: Cullen Jennings; MixerControlCc: Burger, EricSubject: RE: [mediactrl] How to get this work into a WGHi Cullen (donning AD cap),We are still very much actively discussing this work and have met atevery IETF since Paris (I think) - including a Beer BOF and a Meal BOF:-).        A long time ago, we had talked about asking the SpeachSC chairsif         that WG might take on this work. Is there still interest inthat?        Very much so - we have been discussing this regularly and I think we hadhoped (Eric will confirm but I know he is snowed under at the moment) tomove towards IETF working group towards the end of this year/maybe earlynext.        PS - A short summary of the status of where we are, what wehave, and         where various parties might want to eventually get to might bereally         helpful for me.We are at the point where we have a Control Framework which has beendiscussed at length at previous meetings(http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt) which aims to fulfill the detail outlined in the Requirementsdocument(http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01.txt).  This is an agnostic approach that is not 'Media Server' specificand aims to provide a core connection management system using SIP.The authors of the Framework have also created a number of extensions tothe Control Framework that provides modules for achieving various levelsof Media Server Control.- First extension provides simple IVR functionality(http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt).- There is an extension to the SIMPLE IVR functionality for the purposeof using VXML(http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt).- This extensions provides conferencing capabilities(http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt).If you need anymore information then give me a shout.Best Regards,Chris.-----Original Message-----From: owner-mediactrl@lists.ubiquitysoftware.com[mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of CullenJenningsSent: 07 May 2006 16:11To: MixerControlSubject: [mediactrl] How to get this work into a WGA long time ago, we had talked about asking the SpeachSC chairs if that WG might take on this work. Is there still interest in that? With my AD hat on, I have no idea what is the best way to do this yet but I am looking for input on what the next logical steps are with all the work that has been happing here.Thanks, CullenPS - A short summary of the status of where we are, what we have, and where various parties might want to eventually get to might be really helpful for me.--------------------------Ubiquity Software does not control or endorse the content, messages orinformation found in this mail list and it specifically disclaims anyliability with regard to these communications.Ubiquity Software reserves the right the restrict access to anycommunications in violation of the Terms and Conditions of Use for thiswebsite or as otherwise deemed improper.Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.--------------------------Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From fluffy@cisco.com Mon, 22 May 2006 05:31:23 +0100 From: Cullen Jennings Date: Mon, 22 May 2006 05:31:23 +0100 To: Dave Burke Subject: Re: [mediactrl] How to get this work into a WG In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C038B5020@IsrExch01.israel.polycom.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On May 21, 2006, at 7:12 AM, Dave Burke wrote:Ifind thechoose one of MSML vs MSCML debate as not terribly constructive if the presumed goal of creating an industry standard,vendor independent,protocol is to be attained. Telling aworking group that they have to choose A or B and are not allowed to make what the WG thinks is best isalmostalways doomed for failure. The goal would be to great a goodprotocol that had consensus -clearly it would leverage much that has been done but I would not be telling the group to pick A or B.Cullen From roni.even@polycom.co.il Mon, 22 May 2006 08:25:43 +0100 From: "Even, Roni" Date: Mon, 22 May 2006 08:25:43 +0100 To: "Dolly, Martin C, ALABS" Subject: RE: [mediactrl] How to get this work into a WG Message-ID: <144ED8561CE90C41A3E5908EDECE315C038B511B@IsrExch01.israel.polycom.com> MIME-Version: 1.0 Content-Type: text/plain Hi Martin, I reviewed draft-dolly-xcon-mediacntrlframe-01 and here are my comments. My general view when writing this feedback is that we address the requirements for the communication between the AS and MS and not only the protocol. When we define the solution framework that is the place to say what is done in the protocol and what will be done using other means. This is important in order to have a gap analysis and find what the protocol need to address.   1. The draft should be renamed requirements draft and not framework, it was agreed in Dallas, see the meeting report. Here is part of it   "  Framework document will be renamed Requirements Document.   - Scott: need a more detailed requirements document. Should include the scope. Scott   will have a shot at writing qualifiers for IVR and conferencing to refine   the requirements. It needs to explain why we need to do a SIP-oriented   media control protocol, as opposed to lower-level H.248-style decomposition."   2.  In the overview you have a list of items that are out of scope to this document. I think that all the items are in scope for the requirements but they may be out of scope for the protocol since there may be other means to achieve them. The document has the following items out of scope   Media session establishment – I think that there are requirements for media session establishment, even your list has MCP-11. So there are requirement but the framework may show the solution and mention that they will be done by different means then the AS to MS protocol.   Mechanism for MS to advertise its capabilities – I see two kinds of capabilities one is functionality and the other is capacities. The requirement to be able to advertise them is important and is needed see you requirement MCP-8 and MCP-15   Ability to move an existing conference from the current MS to a different one. - This is a specific required functionality that may be used by applications servers, if it implies that there are requirements stemming from the requirement then the requirements should be listed, the solution may not require any new protocol.   3. From my document I see the following requirements missing From the general section: 4, 5, 7, 8, 9, 11, 14, 15, 18, 19, 20 From the announcement section: 1, 2, 3, 4. Also that announcement may include voice, audio (like music), slides or video clips, maybe also Instant messages. From the media mixing section: 1-6 and 8 All the IVR section. BTW this will explain why we need simple and complicated IVR mechanisms.     4. Some comments on the requirements in your draft  MCP -04 The second sentence is not a requirement but a proposed solution.   MCP-07 What about session based IM, what about text for people with disabilities.   MCP-09 is very confusing it lists all the options is that a requirement. My suggestion is to say that the solution MUST enable one control channel between an AS and MS and may support multiple channels.   In MCP-14 change compatability to compatibility     Thanks Roni Even                       From: Dolly, Martin C, ALABS [mailto:mdolly@att.com] Sent: Sunday, May 21, 2006 6:33 PM To: Even, Roni; Chris Boulton; Adnan Saleem; Cullen Jennings; mediactrl@lists.ubiquitysoftware.com Cc: Burger, Eric Subject: RE: [mediactrl] How to get this work into a WG   Roni,   Requirements in this document are included in the current framework document. As discuss, many times, if you feel that some of the requirements in your document are not covered, then please highlight those and they will be added.   Cheers,   Martin   From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Even, Roni Sent: Sunday, May 21, 2006 8:49 AM To: Chris Boulton; Adnan Saleem; Cullen Jennings; mediactrl@lists.ubiquitysoftware.com Cc: Burger, Eric Subject: RE: [mediactrl] How to get this work into a WG Hi During the last meeting I mentioned the requirement document I wrote when we started the work. It is attached here; I thought it will be added to the list of document in http://flyingfox.cantata.com/i-d/mediactrl/   BTW: I agree with Chris answers about the work and want to mention that MSML and MSCML are not the only proprietary protocols that support this interface. Polycom has its XML API that supports this functionality and MS has proposed CCCP for the protocol. I think that the consensus was to define a protocol that will be inline with the requirements and the framework and not to point at some vendors implementations. Of course we can leverage the knowledge that was learnt by the manufacturers to create a good solution as fast as we can. Regards Roni Even   From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Chris Boulton Sent: Tuesday, May 09, 2006 3:40 PM To: Adnan Saleem; Cullen Jennings; mediactrl@lists.ubiquitysoftware.com Cc: Burger, Eric Subject: RE: [mediactrl] How to get this work into a WG     Cullen, I want to point out that we have rough consensus (imho) on the "control framework" ID (http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt), from an architectural perspective and the direction this is going. [Chris Boulton] That’s really good to hear. However, there is no consensus on the remaining IDs identified below.   [Chris Boulton] I’m not sure consensus was at all proposed – certainly not by me.  That’s jumping the gun a little.  I was just pointing out that we have current examples of how Control Packages are written in-line with the framework.   Convedia in particular objects to the "extension" IDs listed below, covering IVR and conference control.         - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt).       - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt).       - (http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt).   The above new IDs essentially provide a subset and duplication of the what MSML, and MSCML to a good extent, have already provided for years.   [Chris Boulton] Totally understand your position.  All I will say is that:-   -          yes, you are correct in that this does provide duplication of MSML and MSCML.  The intention was to use and build on the experiences gained from such languages to provide a solution that architecturally fits with the new Control Framework. -          Yes it provides subsets of functionality.  This again was the intention to provide a modular approach.  We are thinking (and received quite a large amount of feedback from media control group) from the agnostic point of view that not everyone wants to implement a large scripting language for simple IVR interactions.  It should be possible to select exactly what you need to fit your requirements.   If you have got any more detail on your technical objections I think it would be great to have some discussion.   Best Regards,   Chris.       Garland / Adnan -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com]On Behalf Of Chris Boulton Sent: May 8, 2006 2:36 AM To: Cullen Jennings; MixerControl Cc: Burger, Eric Subject: RE: [mediactrl] How to get this work into a WG Hi Cullen (donning AD cap), We are still very much actively discussing this work and have met at every IETF since Paris (I think) - including a Beer BOF and a Meal BOF :-).         A long time ago, we had talked about asking the SpeachSC chairs if          that WG might take on this work. Is there still interest in that?          Very much so - we have been discussing this regularly and I think we had hoped (Eric will confirm but I know he is snowed under at the moment) to move towards IETF working group towards the end of this year/maybe early next.         PS - A short summary of the status of where we are, what we have, and          where various parties might want to eventually get to might be really          helpful for me. We are at the point where we have a Control Framework which has been discussed at length at previous meetings (http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework -02.txt) which aims to fulfill the detail outlined in the Requirements document (http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01 .txt).  This is an agnostic approach that is not 'Media Server' specific and aims to provide a core connection management system using SIP. The authors of the Framework have also created a number of extensions to the Control Framework that provides modules for achieving various levels of Media Server Control. - First extension provides simple IVR functionality (http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-0 1.txt). - There is an extension to the SIMPLE IVR functionality for the purpose of using VXML (http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-pack age-00.txt). - This extensions provides conferencing capabilities (http://www.ietf.org/internet-drafts/draft-boulton-conference-control-pa ckage-00.txt). If you need anymore information then give me a shout. Best Regards, Chris. -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Cullen Jennings Sent: 07 May 2006 16:11 To: MixerControl Subject: [mediactrl] How to get this work into a WG A long time ago, we had talked about asking the SpeachSC chairs if  that WG might take on this work. Is there still interest in that?  With my AD hat on, I have no idea what is the best way to do this yet  but I am looking for input on what the next logical steps are with  all the work that has been happing here. Thanks, Cullen PS - A short summary of the status of where we are, what we have, and  where various parties might want to eventually get to might be really  helpful for me. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you. -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From mdolly@att.com Mon, 22 May 2006 20:18:22 +0100 From: "Dolly, Martin C, ALABS" Date: Mon, 22 May 2006 20:18:22 +0100 To: "Even, Roni" Subject: RE: [mediactrl] How to get this work into a WG In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C038B511B@IsrExch01.israel.polycom.com> Message-ID: <28F05913385EAC43AF019413F674A0170DE0C73E@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Roni, Thanks, Martin From: Even, Roni [mailto:roni.even@polycom.co.il] Sent: Monday, May 22, 2006 3:28 AMTo: Dolly, Martin C, ALABS; Chris Boulton; Adnan Saleem; Cullen Jennings; mediactrl@lists.ubiquitysoftware.comCc: Burger, EricSubject: RE: [mediactrl] How to get this work into a WG Hi Martin, I reviewed draft-dolly-xcon-mediacntrlframe-01 and here are my comments. My general view when writing this feedback is that we address the requirements for the communication between the AS and MS and not only the protocol. When we define the solution framework that is the place to say what is done in the protocol and what will be done using other means. This is important in order to have a gap analysis and find what the protocol need to address.   1. The draft should be renamed requirements draft and not framework, it was agreed in Dallas, see the meeting report. Here is part of it   "  Framework document will be renamed Requirements Document.   - Scott: need a more detailed requirements document. Should include the scope. Scott   will have a shot at writing qualifiers for IVR and conferencing to refine   the requirements. It needs to explain why we need to do a SIP-oriented   media control protocol, as opposed to lower-level H.248-style decomposition."   2.  In the overview you have a list of items that are out of scope to this document. I think that all the items are in scope for the requirements but they may be out of scope for the protocol since there may be other means to achieve them. The document has the following items out of scope   Media session establishment – I think that there are requirements for media session establishment, even your list has MCP-11. So there are requirement but the framework may show the solution and mention that they will be done by different means then the AS to MS protocol.   Mechanism for MS to advertise its capabilities – I see two kinds of capabilities one is functionality and the other is capacities. The requirement to be able to advertise them is important and is needed see you requirement MCP-8 and MCP-15   Ability to move an existing conference from the current MS to a different one. - This is a specific required functionality that may be used by applications servers, if it implies that there are requirements stemming from the requirement then the requirements should be listed, the solution may not require any new protocol.   3. From my document I see the following requirements missing From the general section: 4, 5, 7, 8, 9, 11, 14, 15, 18, 19, 20 From the announcement section: 1, 2, 3, 4. Also that announcement may include voice, audio (like music), slides or video clips, maybe also Instant messages. From the media mixing section: 1-6 and 8 All the IVR section. BTW this will explain why we need simple and complicated IVR mechanisms.     4. Some comments on the requirements in your draft  MCP -04 The second sentence is not a requirement but a proposed solution.   MCP-07 What about session based IM, what about text for people with disabilities.   MCP-09 is very confusing it lists all the options is that a requirement. My suggestion is to say that the solution MUST enable one control channel between an AS and MS and may support multiple channels.   In MCP-14 change compatability to compatibility     Thanks Roni Even                      
From: Dolly, Martin C, ALABS [mailto:mdolly@att.com] Sent: Sunday, May 21, 2006 6:33 PMTo: Even, Roni; Chris Boulton; Adnan Saleem; Cullen Jennings; mediactrl@lists.ubiquitysoftware.comCc: Burger, EricSubject: RE: [mediactrl] How to get this work into a WG   Roni,   Requirements in this document are included in the current framework document. As discuss, many times, if you feel that some of the requirements in your document are not covered, then please highlight those and they will be added.   Cheers,   Martin   From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Even, RoniSent: Sunday, May 21, 2006 8:49 AMTo: Chris Boulton; Adnan Saleem; Cullen Jennings; mediactrl@lists.ubiquitysoftware.comCc: Burger, EricSubject: RE: [mediactrl] How to get this work into a WG Hi During the last meeting I mentioned the requirement document I wrote when we started the work. It is attached here; I thought it will be added to the list of document in http://flyingfox.cantata.com/i-d/mediactrl/   BTW: I agree with Chris answers about the work and want to mention that MSML and MSCML are not the only proprietary protocols that support this interface. Polycom has its XML API that supports this functionality and MS has proposed CCCP for the protocol. I think that the consensus was to define a protocol that will be inline with the requirements and the framework and not to point at some vendors implementations. Of course we can leverage the knowledge that was learnt by the manufacturers to create a good solution as fast as we can. Regards Roni Even  
From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Chris BoultonSent: Tuesday, May 09, 2006 3:40 PMTo: Adnan Saleem; Cullen Jennings; mediactrl@lists.ubiquitysoftware.comCc: Burger, EricSubject: RE: [mediactrl] How to get this work into a WG     Cullen,I want to point out that we have rough consensus (imho) on the "control framework" ID (http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt), from an architectural perspective and the direction this is going. [Chris Boulton] That’s really good to hear. However, there is no consensus on the remaining IDs identified below.   [Chris Boulton] I’m not sure consensus was at all proposed – certainly not by me.  That’s jumping the gun a little.  I was just pointing out that we have current examples of how Control Packages are written in-line with the framework.   Convedia in particular objects to the "extension" IDs listed below, covering IVR and conference control.         - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt).       - (http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt).       - (http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt).   The above new IDs essentially provide a subset and duplication of the what MSML, and MSCML to a good extent, have already provided for years.   [Chris Boulton] Totally understand your position.  All I will say is that:-   -          yes, you are correct in that this does provide duplication of MSML and MSCML.  The intention was to use and build on the experiences gained from such languages to provide a solution that architecturally fits with the new Control Framework. -          Yes it provides subsets of functionality.  This again was the intention to provide a modular approach.  We are thinking (and received quite a large amount of feedback from media control group) from the agnostic point of view that not everyone wants to implement a large scripting language for simple IVR interactions.  It should be possible to select exactly what you need to fit your requirements.   If you have got any more detail on your technical objections I think it would be great to have some discussion.   Best Regards,   Chris.       Garland / Adnan -----Original Message-----From: owner-mediactrl@lists.ubiquitysoftware.com[mailto:owner-mediactrl@lists.ubiquitysoftware.com]On Behalf Of ChrisBoultonSent: May 8, 2006 2:36 AMTo: Cullen Jennings; MixerControlCc: Burger, EricSubject: RE: [mediactrl] How to get this work into a WGHi Cullen (donning AD cap),We are still very much actively discussing this work and have met atevery IETF since Paris (I think) - including a Beer BOF and a Meal BOF:-).        A long time ago, we had talked about asking the SpeachSC chairsif         that WG might take on this work. Is there still interest inthat?        Very much so - we have been discussing this regularly and I think we hadhoped (Eric will confirm but I know he is snowed under at the moment) tomove towards IETF working group towards the end of this year/maybe earlynext.        PS - A short summary of the status of where we are, what wehave, and         where various parties might want to eventually get to might bereally         helpful for me.We are at the point where we have a Control Framework which has beendiscussed at length at previous meetings(http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt) which aims to fulfill the detail outlined in the Requirementsdocument(http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01.txt).  This is an agnostic approach that is not 'Media Server' specificand aims to provide a core connection management system using SIP.The authors of the Framework have also created a number of extensions tothe Control Framework that provides modules for achieving various levelsof Media Server Control.- First extension provides simple IVR functionality(http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt).- There is an extension to the SIMPLE IVR functionality for the purposeof using VXML(http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt).- This extensions provides conferencing capabilities(http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt).If you need anymore information then give me a shout.Best Regards,Chris.-----Original Message-----From: owner-mediactrl@lists.ubiquitysoftware.com[mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of CullenJenningsSent: 07 May 2006 16:11To: MixerControlSubject: [mediactrl] How to get this work into a WGA long time ago, we had talked about asking the SpeachSC chairs if that WG might take on this work. Is there still interest in that? With my AD hat on, I have no idea what is the best way to do this yet but I am looking for input on what the next logical steps are with all the work that has been happing here.Thanks, CullenPS - A short summary of the status of where we are, what we have, and where various parties might want to eventually get to might be really helpful for me.--------------------------Ubiquity Software does not control or endorse the content, messages orinformation found in this mail list and it specifically disclaims anyliability with regard to these communications.Ubiquity Software reserves the right the restrict access to anycommunications in violation of the Terms and Conditions of Use for thiswebsite or as otherwise deemed improper.Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.--------------------------Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From gamunson@att.com Tue, 23 May 2006 18:37:36 +0100 From: Date: Tue, 23 May 2006 18:37:36 +0100 To: Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft - MRB Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E102792989@NJFPSRVEXG2KCL.research.att.com> MIME-Version: 1.0 Content-Type: text/plain Garland and folks,   Regarding the topic below of MRB and MRFC/MRFP/IMS and “Does anyone see a solution to this?” question, the way I look at it is:   1) The Media Server (your SIP MS, I guess) is ‘an’ MRF, i.e., MRFC + MRFP. That MS can still have a localized resource assignment function, e.g. among a cluster of servers. But it doesn’t include the network-level MRB. 2) The MRB function should be acknowledged as a separate network function. How it works and where it fits into a network architecture can vary depending on what needs have to be met. (and could be an Inline MRB or a Query MRB of some kind). That whole story needs to be developed. 3) IMS is defined to serve a certain set of needs. There are things one could add to an overall NGN architecture, or clarify about an overall NGN architecture, whether or not they officially become part of IMS. Related to this exploder’s scope, MRB as a separate function is one. An AS – MS (or AS – MRF) direct control channel is another.   Cheers,   Gary     -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Garland Sharratt Sent: Wednesday, May 17, 2006 6:38 PM To: mediactrl@lists.ubiquitysoftware.com Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft - MRB   Of course I believe that SIP media servers are better (easier to use, more flexible, etc.) than H.248 or MGCP media servers.  That's not being debated here.  Some vendors (mostly NEPs) will tend toward H.248, while (IMO) most vendors (mostly app vendors) will tend toward SIP.  I don't think this is likely to change in the near term, although I hope SIP wins out in the long term.   The key thing is that a media server is a media server: a device whose purpose is to do media processing on media streams.  Whether it's SIP, MGCP, H.248, SMIL, or RS-232, it's still a media server.  Is the SIP one better? Yes, of course, but it's still doing the same kinds of things that an H.248 media server does: play, record, mix, DTMF, etc.   But the real issue in all this protocol debate, in my view, is that there is a discontinuity between what in the market and what's in the IMS architecture.  The market has mostly SIP media servers and some H.248 media servers.  IMS has an H.248 media server (it's the MRFP) but *not* a SIP media server: the MRF is a superset of a SIP media server, loaded with functions that don't fit a pure media server.     The MRF is the closest thing to a SIP media server.  But if SIP media servers become MRFs to fit into IMS, where is the media resource broker (MRB) function done?  Large service providers are asking for a separate (physical) MRB component in their networks.  IMS doesn't have an explicit MRB as it was assumed that, since the media servers are the MRFPs, the MRB function would be done in the MRFC.  But if the media server is the MRF, there is no separate MRFC to do the MRB role.    Does anyone see a solution to this?     -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Burger, Eric Sent: Tuesday, May 16, 2006 09:33 To: Garland Sharratt Cc: mediactrl@lists.ubiquitysoftware.com Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft   I would offer that there can be nothing further apart than the model, and thus application space, offered by H.248 (device control) and SIP+XML (where the XML is not just encapsulated MGCP).   I will very quickly concede that you can do anything in H.248.  It just takes more protocol messages, much more complex applications, and sophisticated controllers.   Saying a media server "just does media processing" totally misses the point.  If that were the case, I would offer that SMIL has been around a lot longer and has many more implementations.  Why don't we use HTTP/SMIL for media servers?  It is because the programming and deployment model is entirely different from what people want to use media servers for.   -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Garland Sharratt Sent: Wednesday, May 10, 2006 9:42 AM To: 'Tom-PT Taylor'; Gary Munson [AT&T] Cc: mediactrl@lists.ubiquitysoftware.com Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft   Tom, Gary, a few belated comments on your two emails together:   1. Dumb media server vs. smart media server.   I don't agree that an H.248 MS is dumb and a SIP MS is smarter.  If you look at an H.248 media server and a SIP media server, there is no real difference between them.  Both do the same job, media processing.  Yes, the control interface looks different, but they are both doing playing, recording, DTMF collection, conference mixing, etc.  Yes, pure VoiceXML (pure = no call control, e.g., "transfer" element) is often used with SIP media servers and not with H.248 media servers, but this doesn't change the role or function of a media server, which is to perform media processing under the total control of an external application.     2. Inline MRB vs. Query MRB   I don't really have an axe to grind on either side but based on what I know at this time I don't agree that the Query MRB is better than the Inline MRB. The Query MRB needs new protocols and interfaces defined, whereas the Inline MRB doesn't.  For this reason the Inline MRB seems more elegant to me.    (Incidentally, moving to a TCP channel instead of SIP INFO, see below, removes one of the objections to the Inline MRB, that in order for it to have visibility of BYE messages (which is necessary for resource control purposes) it needs to also flow through all the SIP INFO messages, which is inefficient.)   The last time I looked at the MSF has only the Inline MRB, not the Query MRB.  Tom, has this really changed?     3. Separate TCP control channel negotiated by SIP   I think that for efficiently reasons such a TCP channel needs to be: (a) long lived, and (b) used to control multiple RTP streams.  For example, one very viable way to use these channels would be to have *one* such long-live TCP channel set up between each combination of AS and MS, at restart time. The AS would use the one TCP channel to control all its RTP streams on that MS. So if there were N ASs and M MSs, there would be N x M control channels, assuming all ASs had access to all MSs.  Perhaps there could also be a time-out mechanism that might tear down a TCP channel if it hadn't been used in an hour, if this was valuable for some reason.  And of course if a particular MS isn't useable by a particular AS, there would be no TCP channel.   I don't see a conflict between having these long-lived TCP channels and the presence of the MRB.     Comments welcome.   Garland     -----Original Message----- From: owner-mediactrl@lists.ubiquitysoftware.com [mailto:owner-mediactrl@lists.ubiquitysoftware.com] On Behalf Of Tom-PT Taylor Sent: Wednesday, February 15, 2006 08:24 To: gamunson@att.com Cc: mediactrl@lists.ubiquitysoftware.com Subject: Re: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft   The MSF has taken the Media Resource Broker into its architecture, with two different SIP interfaces. The first requests media resources of a specific type, with a URI to a media server as a return result. The second has the MRB acting as a proxy (optional) between the client and the Media Server.   I'll confess that in the short term the MSF is using SIP INFO transport.   (Strong influence by specific vendors here.) However, if this architecture were to persist but with the SIP setting up separate control channels, I find it hard to picture those channels remaining up once the individual call is completed. Control channels persisting for longer than the duration of an individual usage (call) imply a tighter relationship between the AS and the MS than I think compatible with the role of a media resource broker.   gamunson@att.com wrote: > Hi folks, > > I'll throw in my views here on some topics that have been in the recent emails, say from February 4 onward. > > 1) It seems that there are two basic concepts of what is meant by Media Server >     a) the really dumb kind (a la IMS MRFP) >     b) the one that can be smarter (a la IMS MRFC + MRFP) > >   * I believe that the AS-MS protocol that the Mediactrl BoF should be fundamentally addressing is (b); but it should be extensible to allow finer control granularity. In a practical architecture, it should be possible for the AS to tell the MS to do routine tricks on its own (e.g., roll over, fetch a stick, bite the mailman) without the AS controlling every itsy-bitsy step. So, yes, something like VXML on the MS makes perfectly good sense. On the other hand, to preclude a potentially finer level of control for some applications seems unwise.  > > 2) While I used above the representation of the 'smarter' MS as IMS MRFC +MRFP, as have others, it has a flaw. The IMS MRFC consists of two functions. One is the MRFP control function, which is okay to be part of the MS. But the MRFC also has a media resource *assignment* function. At the network level, that assignment function cannot be part of a Media Server. (Local resource assignment among a cluster of servers is a different matter.) [One other side note - in an earlier mail, the AS-MS control interface was referred to, in IMS terms, as the Mr interface. On the MS side that's fine.  However, in the IMS pictures I have seen, the Mr interface has as its other endpoint the S-CSCF, not the AS.] > > * That MS assignment function is related to topics that came in multiple earlier emails about MS discovery, and whether we're assuming a static connection between an AS and MS, and whether the resource management function lives 'below S-CSCF'. > One of the scenarios we need to allow for is a many-to-many AS-MS relationship where the MS resources are a shared pool across many different services residing on many ASes, with tons of traffic with variations in volumes, some predictable, some not, and where MS resources are not infinite and the MS boxes don't all have the same size or capability set, and services don't all have the same priority, etc.. In such as case, we want to > - Allow for a network-level MS assignment function (referred to as a Media Server Resource Broker or just Media Resource Broker); one model of the way MSRB works (e.g., recent work in the ATIS-PTSC and in the ITU-T NGN based on a set of requirements), is for an AS to query the MSRB when it wants MS resources. The MSRB responds to the AS with identified MS resources that it allocates to that AS.  When the AS is done with its assigned MS resources, it releases them back to the MSRB. In that model, the MSRB doesn't have to live below, and can be unrelated to, S-CSCF. There is another model of MRB that would live below S-CSCF, but it doesn't support as broad a set of needs as the AS-MSRB model described here. > - Allow for more than just a static AS-MS control channel situation. > In short, while recognizing the topics of MS 'discovery' and/or MS resource management/allocation as important, they should remain outside the scope of the BoF AS-MS protocol effort, and we should allow the AS-MS control channel connection situation to be fluid. > > Next, a couple comments for Chris & co on the "A Control Framework for SIP" draft, staying out of the Control Package fray, and questions about which protocol might be a chicken or an egg  :-)     -- > > A) I resonate strongly with the option of having a separate AS-MS control channel set up by SIP, and TCP for transport is good. Here are some additional points to potentially clarify: >   a) *Must* the control channel be established before a call leg is brought to the Media Server? The Control Framework for SIP draft seems to only talk about setting up the control channel before a call leg is brought to the MS. It might be useful to allow for both. >   b) Can a single control channel be used to control multiple calls at the MS (using the same control package)? For example, 10 simultaneous IVR sessions?  I believe the intent is to allow that, but I didn't see words to that effect. >  c) Can different control packages be run over the same control channel? For example, one for simultaneous calls for IVR and another for conferences? I don't have a strong feeling about that one, but it should be clarified. > > B) The 'Control Framework for SIP' draft places the Control Package-related information at the SIP-level (the Control Packages header etc.) in SIP messages. An alternative would be to place that information in an SDP or SDP-like description as payload, similar to establishing media sessions using SIP. I wonder whether there was any discussion around the pros and cons of doing the latter?  [I do realize media channels and control channels are not the same thing]. Take this question as one that is a mild push-back, and perhaps based on ignorance as much as anything. > > Cheers, > > Gary Munson > > > > > -------------------------- > Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. > Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. > >   -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper.   -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper.   -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper.   -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper. From eburger@cantata.com Wed, 31 May 2006 19:34:52 +0100 From: "Burger, Eric" Date: Wed, 31 May 2006 19:34:52 +0100 To: Subject: [mediactrl] Web Site Updated Message-ID: <330A23D8336C0346B5C1A5BB1966664702F6CFB5@ATLANTIS.Brooktrout.com> MIME-Version: 1.0 Content-Type: text/plain With updated drafts folks have sent in. http://flyingfox.cantata.com/i-d/mediactrl -------------------------- Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications. Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper.