From mailnull@www1.ietf.org Wed Dec 4 20:33:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14075 for ; Wed, 4 Dec 2002 20:32:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB51ZOd04750 for speechsc-archive@odin.ietf.org; Wed, 4 Dec 2002 20:35:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB51ZOv04747 for ; Wed, 4 Dec 2002 20:35:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14062 for ; Wed, 4 Dec 2002 20:32:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB51ZFv04737; Wed, 4 Dec 2002 20:35:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB51Y2v04636 for ; Wed, 4 Dec 2002 20:34:02 -0500 Received: from mail2.intervoice-brite.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14040 for ; Wed, 4 Dec 2002 20:31:04 -0500 (EST) Received: from 172.16.16.64 (gwsmtpsrv.intervoice.com [172.16.16.64]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with SMTP id TAA04963 for ; Wed, 04 Dec 2002 19:47:08 -0600 Received: from intervoice.com ([204.62.0.159]) by 172.16.16.64; Wed, 04 Dec 2002 19:33:27 -0600 Message-ID: <3DEEACE7.2070800@intervoice.com> Date: Wed, 04 Dec 2002 19:33:27 -0600 From: Skip Cave User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: speechsc@ietf.org Subject: [Speechsc] SPEECHSC & usage of SIP Content-Type: multipart/mixed; boundary="------------070006030904080705040309" Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------070006030904080705040309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A comment on the usage of SIP or RTSP as a speech server control protocol: It is important to realize that in a distributed control architecture, the application execution engine may be separate from the telephony platform. An example of this type of distributed architecture is shown in the attached figure. In this example, control commands are sent from the application execution server (a VoiceXML or SALT browser for example) to the telephony platform, as well as the ASR, TTS, & Verification servers. In this scenario, the controlling entity (application execution server or browser) is not co-resident with the telephony platform. In fact, the browser client does not support media streaming at all, nor does it need to. The browser simply sends commands to, and receives status from, the ASR, TTS etc. servers. Of course the browser must initially tell the TTS and telephony servers where to send their media (RTP) streams to, and tell the ASR & Verification servers where to get their media streams from, but in this distributed architecture, the controlling entity never sources or terminates media streams. I don't believe either RTSP or RTP supports this configuration very well. Both of those protocols assume that the entity that originates the media/control session will also handle media streams, and as this example shows, this is not necessarily true. In order to allow for these types of architectures, the server control protocol needs to completely separate the control & media pieces of the protocol. Within the overall SpeechSC architecture there should be a SpeechSC control protocol, and a SpeechSC media protocol. I would assume that RTP could be the media protocol. The SpeechSC control protocol needs to have commands that will tell the servers where to send media strams, but the "send stream" command shouldn't much different than a "play media" or "start recognize" command. It should be pretty straightforward to define the sets of commands to set up media streams, just like the set of commands to control an ASR. The ITEF's SDP protocol (RFC2327) is great for this type of thing, and SDP doesn't assume that the controller has to handle the media. Another key architectural issue is the registration and discovery of server entities by the controlling entity, and whether this functionality should be part of the SpeechSC purview. Registration/Discovery functionality will be required for a robust distributed Speech system, but SpeechSc may not want to deal with this complexity, although there are several protocol standards that have been defined to deal with these issues already. THe SpeechSC group may only need to specify which one to use. --------------070006030904080705040309 Content-Type: image/gif; name="SpeechSC Architecture.gif" Content-Disposition: inline; filename="SpeechSC Architecture.gif" Content-Transfer-Encoding: base64 R0lGODdhvwPPAvcAAAAAAADMmf///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAC/A88CQAj/AAUIHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMN+BUBWIACV ZM8yTMu2rNi3cOPKnUu3LtO0BN2aVau3YN+BfwGr3ZvQLV6/g/OyVYxYQF+9fwMTtku5suXL mDMTlay5c8+2oEOLHk26tOnTqFOrXs26tevVnmPLnk27dkkAAXLr3s27t+/fwIMLH068uPHj yJMrX847se3n0KNLh46bufXr2LNr3849ufPp4MPXTHzMGeL3iOUdOz8svmv17vDjy59PH/v5 9vjzk0w/WXB/9f8FFhlf9/3HWIAE+gegggdClhh5+nn0nnZpwUcWdxfWF0CGuXGo4YcFRij8 4ojUgUbiZ9lNqJuHG06YoYcwuvgeix3OaGNzN+72ooy/qdhijT36+KOKNP44X4gnJqnkkkyC JOSHUEYp5ZTEIdnklVhmqaVBT1Lp5ZdgHrnlmFjy91hh56UnYGN5AcamWW4eCGebcca5npVk HtRlmHz26edxeOYp6HSSDTbgd4UuxNl6c/rlaJqO9gdhgJEO2tBrmGaq6aacdurpa5aGKuqo pEI1WqmopqrqqmQGyuqrsMYqa2yu6pnmrYreN+CsvPbq668cnWoerlwiuWitwCar7LLMNuvs s9B2tOef1FZr7bXYZutdtNx2y6W218bYXZHgpjhtuehuh6y3/+zKem66K+pIJI9ArkhvvUYC VyG++LJ4obhBNtfbvvKCli+O8tqLML9D3quvv6ExnK+NBh8Mr3Drtqvxqu9ePBy5Fnss8sgk x5fxxiiT2nHJLLfs8sv1nZzyzIOuHJy/CxNMsJEc7ugbWz22SKTFIA/sc43/VrdjjvwqrXC9 S+NWtL3nKi3k1E/ffLTQUluNdNYHO92v11yH/DPZPDMtn8w0t72lzR93CXTBMvo4N9d1J60z 1RWW9jDENN4tsI4C71w20nUHfTjiOPZNWuOGGw243ZF3OHi8ht8teOV8Ny65xNex7fboTcIN 8+mop676z6S3nuqnsMcu++y012777ZK4596p67ynLJpWv9sW/HNt2YRosRAeZljxBi4mGHvM L6jYnXuJ3vv16IllPWXbZ9Y9Rsc6Lz2D448f/fKG8oUgg5Ni776Tb33PpYHV00l++Z+NZ+yt D+4k//sAPNH/kPK/QpEnfW+qn1AGWBEz8e9++TMesSzCn1wF8IImYeBRNEgXDtbGgw5JFPkQ yL4HIap/9P/DoAo1AsKiyMyA4GNbBVniQRheZIZo+kkLV+it8oivedA7C3smM8TnNQh96BvJ DjfTQEiNcIQkpN+ZUjgTDYqQUuvLopwcA0GgLDGHGcEhD0uEEBNB0XnKM+EWHaTFLkqLe0z6 onjk6EAoEkaMY8wjReTIxJDgUSF/1GFKAllGPkZQjwG0YRNvyEdD9tFJ+7MjgAjJky/WMYtl oaRVHAlG+CHSe07EovkS1MUp4k8knBxKKueySun4cFcKCt7vjrVFI7qxkJ98XysXqCeaaPJS 4ymjL2uoFFf9Mpi5/OD3julJ71FRPdSLZWiqVzxalrJ9l9olF0+pQEnKcprWTOFWEPHIzEcm k12XHKV/yhlGWlVqLdpkofHqBM+lxNOX58znSu7JS0vxU1DR0yd+/ukTgn5meFlCaO8MKlCj CIhRt8SlrewHSDXVcnkJLMwHS8VQL64uWx3/bSgF7aKroJjuo1CiI0rDBb6UtgVyVTopn0Iq 0gjRtIwrZelJZJrTtbWUSj1bWNZ6djWemqymBLTSHy1qPiDuUY3qpOejbuqXnlZLpVb1k/WM mlV1IXVMO1TfAruqVZRwlaz2+Slav0TVr0anrYVZa5iw+rGEYc6ulgub3Bzmsa0CamhgS9rZ 8Do2wk1MbWGzK8CUA1e30qaxcQUU2Oh2tpfGNHA8wqxh9Wo25ND1rxi7mtEUh9ciketfhE3t cvwqVy9B1rGeeS1OW+tas9IWqGq9bUphuyzZRla3UfoscGOW25jBSHI3cty+dLYzvUnJt7yF 412GG1zbUldDrAURQFEht7XRchex1Y1ur6ALyOuCyLrmFdMN00sf8ooXLu79LXuPulPd2fe+ pokhfvfLX3a+d0nxrWh/B3xfzAR4Kwr//e8KD+yUBL+KwVyBsILjOCoJay9WFp6wAFW2FnGa 0qkdLl8Q7yREqE5vgxjWMA8zHBVdPdCWIiaxRBETRfEhUZLcPORE0om8QEVxjYYCMkX9GyxA zo/GCAwiNdk4PROOmMknliaLVdxOVE3ZK1euCp7Cl8aJ3u+ATFbyNtuH0YhSOcKqmiAVw+nh dxJ5KlmmSpxrVqAfHkqN4yTQi6WM5PbM+SlqLqIbcQjLqMJ4zCTE5psz+JBCZ/TLe94mNDH6 ZCQn2kH89HGOG709R9cS0vnhMpQnjWlJmVh6o8a0oGcjLI4my5gyLtaMc/Vjw+DPjAvqMo5h Yiwva5HMp66zbJNn/ekzxy/FwNTxjuP75xYb24Jyni9Kmy1pYgP70aeE5bVBLadFo+WpBRWd t6u8kSRS9IIPLWG3z4TCQUr7o9SuFbUduuwEKrqQQRbltqXY7k27RH6xNvQzy6zoeWP43asj cIHRsky5GLwpD8lHp8JTg3DVRRyVp7Zl+GQNlnvO0JhyNo+cL57QiqeO5C6Eb0sKTsRopttU 0Maxp9t8xHVfNJr+RupZTU4tlD/YwSnXcgifLZGJU3yw3oWa2rrLdBeVll7HfRhht1vY1EKd clOXG6mNzvWue13hyCY6loG6c+/o1udiz8oSTRxmtp8w7ebh+enQDvdN2nOhXx+N3GFG97qH 3O/A2/vL8k74whv+8IhPPKgAr3bBu6zvjI/8rMrueLZK/vKYt5XiN//1zHv+86APvehNR0/6 0pv+9KhPvepXz/rWu/71sI+97GdP+9rb/va4z73ud8/73vv+98APvvCHT/ziG//4vf1wJh/K fBJDddXcbvKJT5i+6q9T1T1GvvbfV5zqMi/ZyU8OtrBp3GTvu93U3n/ence9/fa731mUrzzq IP/++ktL/uylv/33X1z8A1f//BdD2aRAzGN+eNF2P8ZxHCdmqKZnJbZ8Dbhk1PRM/uR/5gWA AchCP6R+0jdp9bOBE8iBPYZrIghNJrh1y3coJohGacR+c6Quk9U0aMNZQ+V0hzVZUVd1oNM5 WScxOSguWGMdGJiBRHgpz/UkQWiB6lWETGhgSkhdQ9iEWNZoGBR/T1gyUSiF9XZuKdhJ6NFr 7xSGdZZR6Xdr43WF/6eFaihQAbWGblh/i4Fzb/I4h+73QucDG/nVanS4h24VGd00gApYbILo gnxYiLoEgoaYiJuEhozYiEuoiA1lhY44iWiYhZD4QRbXWUIYf0kYOpLIHJ0IioClhJZ4iaw2 d0jXNFMnVIc1IzoIMatIg6m4WUt3XHsjgzjoMDN4WvNCNYZlWlJTML/4iXNlipFIiciYjNti jPrEVZUTip6Idb5YWawYWvBmNXsldQGjg6pFW8S4IszYjOoSjNVIdWaDNTMYL1CTi8axWLD4 dJaDWnSTjjF4M56zWT7YMeh4L+9Yg/FIjnxDjzu4jdVYjxgSjvn0jcq4kCZXigjpPQwZkRIJ jv8PiXmIuEnQJxsXyWrT9BIk6IFFB1EgWW4OWZH1ZCeEOExitZGXoTzY1hkfxmv5NmhvF32v FIE2V3NmZpJodmGoRGuNooeCJJOkgYIB5ZLzxJNUBnkMBHSHlmsp6UfDFHNo0lYl6WtK2ZIO NyJXeRtVpFQud37R13JZaWCsZCoGRXJROVJliRX5BZRNFGBDeDIVpG1iCWLSlBNWBJZssm8x 1pev1ZVaqEgKSJjdB2osV23NdJZKIphVREMh0oIEN5NtCUlmlZFvRFKlwysgVBocyIJmxJKV 6T+GVIo1FJlIREqQAXGXKWASCJVS1XGjaU98qZNkCUF2OUha+RGeOYExoFmAmNlPGNdqcSiZ v6k9GedINzlkapZzsymcluGYPzl5coiTQTlF43SCkuaX1nluFP/4nCalGbUmkq1pbcU2c/sk ZN55G+PHnFjpnHcBnl6Emg5ISqgmE45pn3hpStmpnVwEPTKHc1ckiN/maal2aHrWJgD6awIa SgRqd/KpP8R5gJIJkqKpRO5UM7xTnRHKaqBka3+YJH7onygjlKOJnufZnDvZPFxImdVGnoqi kRcaRzNKUhMpnd3ycpUyoIPoY9UJUYf5nY1SUBO5IejFkNmFpB0KnUR6o0e6kEmaUgNDjeWY OZzzXMgXaFg5c4hYRItGSWt5f066U2NKQWDCi4GVN2qqkFVyfIsyaG8yoHmGbbUZiB8npONR pMKljFHKp0taSRukp0/qp+tVHKY1juNUwqaG+qc6wWyMBYxW14vaOJDasqcxZY1BEoSCg4uQ qo4AA4090n9xsyFJ142LxY3+yDDmCCSn6lmMehMHtjJFhY+4aJDqCI+lqjCSWpDLmEFl2kC/ 8PqqMcFginqBg5qMfWpcYpNVOOp7Elas12WpyJis2sVXoBNUOwiqFCKsw9pggkqmEkmtlNis u5dh0AqFxzqtoqqu3EpDLfat0QkrNdqucEZnYWpTaQai80qvd9cq+hqcHCav/DqFoqJprrmd TilMjJRx/fpgA4tgrlaVbYg8gLllHRmg6vmXqpQ9TxRsbXSwFMRsI+h8W1gn+wqID6uYoUKu OCFDkXRkBNqck5KYGotPFSVVhLlr3dkYo7azELiikMiy3wYsQvtvsPWWVRmyRbtyHONlPFZ+ H+do6ydouvaxBZVNF/t9JmKi5KeyY8FwQP9LtCpqarOWfj1rtvr5ViAaohpKtJzGtj26bOL3 knekn9jkkcmGl90JZShahoEItUu7coFLlPf6Vq8WdqRXuLxZpDPlllQJnEfUngj4mnxLoS3H sEy6YyPXspKXTsC2ta10rozLOldRp8dZgknbZyJoYylIfSRLbyFpbwmYsyDmlwaagI8ZLOFU nLcZgcDpt3UnuqPbHHcBfYOLn2xJYeUWgtNHtV7auhU6koAnvMNLkcV0shh3kiFEd8ermzxJ vdVrpK50l2iLm2i3SuaGk9wJnxtLlY0qbt0LkeE7JfHrZ6sJt8M5Sg/YTRSKuQ1rbXMbm/z7 RAz6acpXvy15q4lOhamiOFO7qqm7ilv4hsCPhb1aQsEqhISzmopo+jTuKKmneqW2eoOo2qqC xYqtqiMTjMG6p5x1mreiB77Vy8LGF1bka7e4q7gJOb/0m7LtP2uSMjy8NJx7FznEABTEo2vE tzexZYnEjKvEPrx6TgyvUVzFVnzFWJzFWrzFXNzFXvzFYBzGYjzGZFzGZnzGaEecxmq8xmzc xm78xnAcx3I8x3Rcx3Z8x3icx3q8x3zcx378x4AcyGXrwm/7oIJ8yB7pvLYJm9dnP3cLuHYq REO2yGfbbo+MyMpuXJNRxWY0GbPJ+bJ/yZ2cjMmArMOkfMpdPMU8nCKoPIeqvMqh08pv+Mqw DIqy7Ia0XMuMdctrmMu67Kq8nFRhBMWA9stYGMwoa8jaC25eGLaJZMwkQ8zEV5dhScma3Lvv qW4Ua2ivNJ7KnCeSGM4p7Ilr8yInh8zLTE/8+XyYu843S4Y1lrY3p81WW2EYcq1dk1malYsx wlzM9TmKBTLNBVO6GjFCQ1msqq0Yg867CbMzU3aiUapN14MDecJEg1gTHTfglY8K3Kk+s8XQ RXhWwJg4raiquqg52OjBtUrC2bqqFdNZI71cCinNIE20R0iQ0LzQNZ2BvpzTH7PTPO3TfQXU AdjTQq0vRP3OORm3T4m66ndFH4mwIOii2wm1nHnU8ELTWQqja5vN25vO7TmkcVrNKTp5WJ0u Wu2moLxqYBqZDi2GGgXPeuu1D3bW6JLW0+yZuBbVTGzVT42UgCvJlua8LgZ+Fpx6ppzUii24 h73Yjn1QCfvYkj2UAjzZk5adFHh92VoMv067Ri9qyRyq2ZINo7TmYE+rs6K92EU5LF592nia 2qrd17A923qZ2bStMnad211l24Fs1Lr9215129EJ3MSdcMI93MWd3Hx33JXh25toMlZYrPsM VNr1NU/I26WciRe9NXPTj81FNubYzwGdz91VjrHowTni0rV4deQtkNaNdFHTMJdzNECj0NaC 3f9/7NxmF6m4utIsnTMYHeCymKs4jc84var/Ld8GOS8bfY7L2sHzx9zcM3hWKtMHnTAVjo0k 7Yv+zDg8eDibijcR4895c4+UJd6Lszjd/YweTtApXo8obd/Ygt9+rN+JGtPKHa4SbqM53uPR vON1ocoyflU2bnFFPndA3kH2IVr0a4OEEzgX3Y5H7lmjWDgabKhVM+XGRVxJ7nAU4or8jaqI E+LZ+t7p2IkfXKU1+OCUUzEKzTnWmoT72N8mveZ5FTIRrYmV9VIQ/tFdDl+IusF3XtJ5NdC0 ijPTWOe8moN47uRmzugp7ak204+kmqvTPcKqGIOMfuGcXumFHnWhONAlt6jnrPzngO7jMPjE IkPjfazlqI7qrM7Hrv7qPR7rezzrtK7ctt2e2omNn8fb6y0GsKYeHlGNkY3tcMUuo70Jmb2k gdKy60y42qXLteIp7RXc1TLpZuwcyWNNJ5Vrb0vNvjUd2g0mhjgak9TR7MMq2EydsWRbmLMb 7/X82Nw7UCI67ODRd6fpYvP8zTaLtx3r2QKHTPi+UcfGm7fUpckOqFOp1Nl3tQUfW3ExQDLL 7c787+vuvmIt7gBf21F2QyHb5fQ3xPidaRZLgCxYQj+bvsDe6lspIqyuTdQMmOF+u69t2QCo xLsu8woPZszbv67bgcyd84z08clbsgTvR8MGPiHP8P8R7x4dxMzQZpzv7oGTibu5KyEnf4KQ i34ldrkXz2sM7bHpHLsEFORS38zl+7G5qZe8+cKMXPU1i81eFG7JXJmGGc+MYbv9tvZNNZ1R v7AG5PMjCfQPz7ywOpyDD34/37qHL70/DLbDDJ60S88ZK8pfD2lhpZkAJrCDtNbbDu01Zcqb z/md7y4ZpMlB2rN/bomhu/WsKUF3/7VPH/lor/TODmifn/svH8wHxPRNb1bxivtKPbPsHp/1 FXPGT9dhIfqjF7Uor2vYN7k3L0/Db5ndjklYD7vsCe/etP0Ey/U6rCYJKrv95spwv/aP3PaM 1tBX4vyFbPSru+152bsp39SI4t7ys8fEdha9AAFAoACBAwUcRFgQAEKCBRk+hBhRosSFEy1e xJhR40aOFyt2BBlS5EiSJSF+NJlS5UqWLScaTPjQ4UGYDWmiZFgzIc6dOT/inKnTI0+XRY0e RZpU6VKmTZ0iJfpUKsmoU61efYlV61aXNSsqjDlwpk+hYMmS/Rr0ptC1bG1yhf8bV+5cunXt 5rxrF6jPtVPd3uwrE+VYgnF5Dk5bFapig4QB7xycl6PitpIzUracWfNmzos1/sWKufPStCfZ mvVauufbtzBRIyYK2jRX1WdNN0b8+LHr2q9tC54serTH4cWNH0c+XHbwusKTs6xNU/DP3KyB z46YOqbt5XxpWy/8Wzv41dex6waKm/lzkc7Zv4cfX/5lyry923SvNP/8kNTxNtRJrLIcAzA9 2BL7qrLszDrvO68U7IlABiEzEC0FEaRowvv422g/Dj8EMcS7BixvPNa6S8pDETGKjUUCR1OR tP8s0lC5FdvL7kYdd+Sxx6Ji9HHGICUDcsgVMTQySSXZl9SxyBsPO4lJuKqT8kmFrqyxSi23 5HLELjPE8sUvjwozyzGPNPNMNdcEicrydAMQPf/gJG+3AK+UabsZ3XPSxzDZdOpPQE8KoFBD D0U0UUUXZbRRRx+FNFJJI+1zUEtpO2yvN+nLUMjbPouutfQuu/S3UplC8UsAJmW1VVdfhTXW ACo9tdZAM6UxP7dQrDDKDUU1j0bOVpW1WGOPRZZRWi9Ltllnn53USWKhpbZaape1NdsUqStz QDGxRGs5JCnU8Ns7WxzWWnXXRRZbj9iFN15WpZW3XnsXdf9XW33JBDTfFO8FOGB/KQq4YHnp jVcgRac1GNqB94U4YlJhbLhidR8m1GKNnUU4YYZnRZRhhQ0deVaRCy3ZZIElZnlK1G5rrMCg XhOzQJkx/iy8zj7euGdZcc7JZ6F/NolndhXmOWWVUZ5WaaY1BrplqYPNs07protqobLAS3VB 3ghLs7CooRu67FfHJshstSXteG238Z06blQx69rmHHfbtO5N3+wuVMuMfjvwWQMVvHCSizbc cLTllhrsT/WkM04h76TaPjDHilnmEiHXDPDEzUbb88+Fbnt0tRdnPHUb5zZOdNN7Dv11t0tf +MqQC3JV6aZxT9bpi1UHPnhfW5f/fXbCIe0W9+RT5t315hOnvdGkE1WI5FV5XxpL629nvnqm sXca++x9Z1t484FHvauzpR959zApbb/w2Fslf3vqmVcWf+53N/l678EXH9Lq96josY9kt6td Au23wPoJcIFPg+D2uger9J3PgjuqINnmFUHrnexQuhNdAO9XMgFqr38fBOAJc3e8eTnPdSok 4ATvp0CQcRCFxiqgo8hnQt/J8IG2g2AKa+jD9onshcq6YBJZlkENws+E+ALh91poRBoy8IYz JFpTjojF/NWOf1D8Ygeb57nwAXFpWaRK8U6nRDbqi4lN1KHRABhGG4qPew/s3xih6EU9opE0 agQd4gA5ArQ357bRkMcp5Eq2OMh7zY+RsBPkIzeWyENWcljvWaQkE8ZCTVYshxyjYic/aElS nomSKsmkKH+nRVV6MpJHs+MZVdZDD8pwgNU6ZSl1KZdcpiSVrbwWJ4HZyFdaK2l0xKMEr8jF g+3SmUvqpS+HaTBHTtNen7SmMZ+5zSFFs5jZ3CQrwVkvbI7zWd7kZjqhMp9fmrNY1XTnKtMY z6Op054hQuc36RlMce5TmyVppz/ndU+CspNDARVotNiUzzUxtKAPfY5D55lQfqpJol0CF0Q1 6sZdXtRSHq1S8jY60lKBlEcZJalJlaSpvf+R1KVcUimaypRSjcb0pTcNjSVZGrl72lRKPsVp ULW4TaCqqqZCRaqWitok+mTNTVwTTs06tNQOHTWpV10pN+vTUgiFi1d7M5HOrPMgrmZGV8u7 GUol5xxphbVzWIVrkKj6pKw0SKxwcuvwNmSisFqurESiSn1iQ1bikAdzqdHaUyXXnJegy5fY 0ltccTpXuk42sENxkWDVitfo8HVUc2HMTrVzmqf6NTx+pRzk1PNXyZaSspW9KZBkQ9o5Lchr 9/GN3cZaW1666K51Iu2vTFsi3p5oVHltrTNfe6SgLrdHzk1udDlHVNvyrbam/Qtudjom6GJQ ut/FJEEH+yvy0mk6V+elELCMGyGa+c2sVgXvU9xEtyJF1pDdFdF4ecrVr4qntFVZbV9tytbP ipWwqQ0WcpkKqsc22LrEff+w3IK7Gux21sKT4+1q9zuoABXUQGA77IQ2e7caOaTEjjFxRtsL o6niqbGd+uuJhVsdywnYMDkz7HwTExg7AVix/C1w4/R7HvRSmEqpHY99TSnSdOLXSAQu7377 i9v/wli9nL1xYfN2ZC5v2cqgKbJLlUzKEVPXshD18bm+ltjpiAqxaQbxmt885vimjs5J5BM+ qepk5tZZpxTVJJ/1amUi1XfP8PXz3wRNE0BLctGesqtnqcZTJHfZy1ROjmzfelnGJtqsoUXQ hVvDWqMgtNFle/R0K6djSPM4wxHebYN+vLP+HEjUNdOwdtvSG26x2c1R3sqyOkxqT1f3xViW cth+yHRqRqb6aixSp4cQvN7yTtjImL40hDvdlWmr+cSi3rBWmWyzFadXOlKFCrMHSVlxNbc9 ve6qshdr7guFWLf07mqWUVlgtzqO2jYu9t/UDUjnCurZL5XWBZ0dcCINXI0FN7hV+lZVJi3c oAxXoqkdDjVMUlLXckJ2jrPqMkX2/xnjCt+47CxOGlZf2U529ZNh6Lse/kR10yO588knk/LX rXxuvu7LzLg175xH9CrInRmYYB7eXIUL2bjmdWBcjNoU9xjYOlcfz0fnc0Q+edC/LbWlXT5c qxm96XstrrVnHPJ+85vr99X61rGeF7TCZ9Ezr/ebMwszC+k2xd768Nz1I8YyxdHUsYRXt1CI UGT+E7OCl0rEoz0ZyGsLcA0M4Me897TMS3GECDwhEBFfRzqa0XZP9Dzni5j60aNsOvKu/GLe bvbY23mPzFzmDkNJRM0Ti/coi6MBb0jC3i9T9cz0IfW8WvTaSxd16O7I7Cd7+xEK8XtzjGDy if/D4ge/i1dB3P4Quz8+5IdyYb5tfvrHVnVy7br9X0//lMip8Wi1HpjSj/8SWb52DbN36fkP jbj7HPwDQIiJGu1SjaQTmx2rmgKUPwFUHAeUQFVjsQk0DAiMQAt0QAJt1EBFwkD56cCTa7cQ tLwPFBwOJEGlUisUTEGcM8HAYcEWhCbJk8FTob8XTLwa9DTm08GQwkHj6cEgFMKT+sG1icEh RMICvMEidLwkdMInjCgmDCQopMIqtMIrxMIs1MIt5MIu9MIvBMMwFMMxJD/DMjTDM0TDNFTD NWTDNnTDN4TDOJTDOaTDOrTDO8TDPNTDPeTDPvTDPwTEQBTEQSTEQjTEQ0TERFTERWTERnQ4 xEeExEiUxEmkxEq0xEvExEzUxE3kxE70xE8ExVAUxVEkxVI0xVNExVRUxVVkxVZ0xVeExViU xVlqpMVatMVbxMVc1MVd5MVe9MVfBMZgFMZhJMZiNMZj5MFjVEah+jj5gjJiW8ZoFK/tYh0G uzppxMaeoq1bo7E5WbMNy6sAizAF7DFf67/+y8Z0/KluCzWhw5MwKzt03DX2W7VYMy+nKjN1 1JPHBYOMcXQqY0swHwMrfBwuAcE2INvHhFwpt9sTsnIczIE1WUMsvIgMvmG7XtEZf1PIjcyv fBOQTAG8NjO3b4szeDu3kLQQBHyc1+PIllxIl4RJEoS9QFxCKTzBmMTJhLDJbDrCnKzDmtxJ IPRJmATKoFyjoSRKoxymnkTKOCxKpSSkpnTJp4RKn2FKqXRDqqzKScL/So7Uyq20mKvsyjX8 SrBsGLEcyzQsS7MsGLSsxanTCnOZqf9TP7Z0tLSkO4CsNYAKrZUMwbW0S2LCS7rILpE0slAD DBSbtv+rMMWkHHfsxqETr8BstsEkTNEQu7FzLGojtIOssczkTICzJ8A8luTDIdJcN8sELby7 ttaMnEo7OyI7LnALrgq7Rtdqlls6m6JEzSJCzXpSTV7Kmnt8OsWCzWMLSG3zSIYMubLrqN6R pdIESt08zZAhuOBczYpUziRLEGsju7Uzj4+bS6hytZYbTeiMzjwCv9XLPVvyvTDqnt3zTfb0 otubz1nSvCsqIf/hGOwks7vZwXYxPg6iT1n6Nj32Qabwsx/TrE/C66PcW7zTK0u39E9nhL/4 WsLx4z4CNb8z0r3sG78oMtDLu6P0tKEgGtAT7b2dCo3GG5QjDS090APRpgFRPNK+Da2i8aml F62hDvogE20XFl1Gjdu86+OfzrOj/8m83vMf97m+CIVS9aSeJ90fMcpRK5XScxJSZfxNIKVO yiSgLUXGxIulIgXTFRLTYuzSM23CNA3GNWXTinLTN41TlZvTYYTTOu3PO6VTPZU7PgXGPPXT IAVUZxQplHKx10sQ5GRJAL031ZJLpWvUkRLUQcWhQvULxxo2R40xXOGx7fiaqglV5fw3yawp S4WoHkyNvO1yDUZtQL3US4GkQM58uWqjUIFDVRBU1VvZrESFVWsUllZTrWAlTvK80J7KVV3d 1WrknGacNGCliGOlxmb9rMUEOw9L1ptcVmYVVdj41WsFR06druHkVO08OHDF1mx9m1ulRRJ5 TW8RVlsFl8GiwbTSTig5uPEsRHbd1n79OX8FWIWbyYAl2H2p14JFWIPtloRlWAMst4aF2JJq 1VeN2IrlrmO1cdiM7ReN5dha4deOBVl05RTsoLrQzLCPDVljlK0hu0Z4dM6UhVlfwthnVbtv tdaYxVmZhUZKY1mbzcecBdrgiJmBBa6eZUyUDdpAXVias9XHo8ukhdroO1ivCbGq3cY5Q9qo 9UVf1dqurblk9NqwJUyx2/3E5THbs0XbtFXbtWXbtnXbt4XbuJXbuaXburXbu31bsvVYdeVb d8pavU2bvhVca/pbva3UwUXcZgLcSzncxHVceVrcfnncya3MyOUwysXc4ilcsm3czPVcP7Jc i3qkp+y83pnO5fEkqnyeF9xcse1cUCLd012XHromwGRQAWzdsH1d9CwjGFK9YxrQIjW9zSsj +Qyh/KRS4U1S7PO84f28BcU8D4rS3xU94psg+1vX0JXch0umA+XQ9vxRD01Q6SW/ZHJQEYVR /jyg7yW98AW/FJ1eHO3d9XXP1P/U3oZ6uPcxPgUdUfDdI/4VXwS63Tq6UlqivgD2Xwnq0PxZ 4O6lURUF0gG8X/xVuSry3v5lIB6t0QQ+PvOFYBoVURkVYQAmYfX9YC760BlqYAiW4Ak2JZV7 UScd0fccYSMSohtm3/Jl4flNX+JVXiyNHwzWYS8tYR8+YCNtPNPJXa/dXVj6vs+FyiXu2iae XTKiYigeXRd+YSzmYiPUYu7q4jBGtS9WFTE2Y0giY5g64zV2pTTeEsYzIyr1vtzhoeqJ4ypF PTBytCDGFz6ipeR53q2UYq2lP9r1GBHO0sVDZOEjuBVOvUVeXwK9UnD6Ugpy4zfGoSkNZBtd 3hSWo/QuNGEWVuEoWtIoVdL3vJ74LaEYIt/wNWDkeaFVHr74NOUxQuUeTWRZZmUmdZ9Kpv+f S1aq6nRf4MNRA81h+CVm/QnhGOJgYt5gScZlGoZe+mm9JP5S3bxgZ0ZgaN5R/cyk65VeX0ZT YK446Yzk9n1mZK5STc4eTmYb81tmBFbfXk7iCGbl6jNTe1bnYo7n8JtnwvNgX35l3NtTcoam dkllRFbQgaa+8FFkd2bn/R3fGpZhLEphSkG+HDXkfc7hfrZhH1Wgi4blSdbndzLockbohu7Q OEa94h1mj4ZkFWLQEg7eB84jmtbjYwZpdI7ph57piYboHn2ieN4f67Wlkh6ok14pNl4fu7xi HVLqpWbqaAnMpw7TqH6yqdZqcsLqrN7qr57dru4msCZrXBJruSoU67Qu6LPGILV269Jk6+d6 67mOlUH3juuZxSf9WyK7vmtJ9ROwTRLo+6if7Ti+S0bAJmSitTvF5i6uzZa6O7qaxbniwpG+ 1leZYmyMIuzBXtrQ2Ey+bAnE1t3L1rOp7ZfOfmwTW02KDbCqAzFTaW1Sfe21yi0mBovEEu3L RG2JFYt84+14zVRqVTFPLdaXPazwrNZZA1p8fdnChlRbmViJ2VRM+S2XtUdS9Y6CTDtwM1y8 vjiOoljw9u79A8n/cNfihkiTTU49UbAphqa44WtoCzY4w7fbnro4azN7uzcRc8fF5cD4Dm/G AXBgRsGHATMGjMib82wIK1mr27a+XqiK4xeXDbLmBq3LdFrhyt5LCLeon+IXq4G623xw6o5N w3wvDjcqCf+Rq5MQ91JwEndVvwQsFH9jD++KScNIWqU1mctw4X5xvXgZzx7wV4xBd+lZdjSV zcil2Tpyk8ono22Tlb3kIocOx5xY/sZylUqkMutV3/7xuAQwE/8198OPiRRx/w4p1RnyyoZx YqVV23zV77zfI1zzAMczkuvxczzZerRwwKVz9HGtNjfv5D5IY3VNLe7JOrdzNiokjQS5izxJ 2dxZ161xQO8oGjc5Gw8stRByvWA5To9siVL0lGVKTXtaaI1yT1+nUx/Zd/v/ckxnj1J39WhN 8ma8b6K72SkJu7rqx+yWs8Q080kPNjKms9wOFJiadS178z2Pc8rWt9DGzEKHcwwT9u8g9evC TEOjPaVKdlfV8wQ/zhFXJNas1Ucv7nK/pJzVm2Kfq6uMkV0pVknLNnQf2x8h13Bfdj439lWX OMcmNcHOxSIDuI+0sG+Pk1snOv3AqE33lAZ/dKDbToYaGEdXb22DeHPf9xRZcAcjxqs97nk0 SNne7useNY1f+PMZ9RUP7ti09XHpRcnGbkjH7pB/OoU/efNJeZW3UJbvxnPdWnptyF6P9OeO SO6et1K7WAvKeZ3nVmPjzozvRC4vyb4r8wOJt6r1OUgZSXGUp1Qt0lRml0ekhPpFD+2kV3qa 0o8gg/P2JkqAf6wDNKU7R3tYF3dut/c0EZexly+vx3v6ov9yur9ws7f3fau5nS+aRAd8XY97 MhGswzzM1wqdxndwNytwmIXLTt/7xd91nvd1n8+0W3Fa7vT8wAZZKGfavTz2Dmf80I9M/Fo/ ybfHzIatiC3MWmfAW3fMZ+V3wec2AF17F++6pn+23w+3bjqtzOHVoVhURR1+WJw4kW9Oou/z klP9zYc10a/2GU/79Y595X4utFt5gJzuvHHFvMeanh/I80/96s+42DLx3GhxlKxvBE/4cCV7 UoR3Y8X+d1X/oQIIAQIHEixo8CDChAoXMmzosCCAhxInUqxo8eLFiBg3cuzo8SNHABohihw5 UCRBlAJUClTJcmXElyNlmoT5EqadxJsgd/Ls6fMn0KBCf5ZMSfLkTJMuNcas2TIp0qEnpVIF 6rQq1qwVr2rt6tWnzpQ0xT5FGDYszqgHi5Z9iPYr3Lhy59Ktazfj3bxT9fK12vfv3ZtOWY5N a/As18IrD0Ndyxgw5MiSJ1Oey7Wy1MuYN0Pk7BmsUsIxnzINXdI0W5uKDacWLNPs59iyZ9OG rLm2x9u4be/u7dbtW8y6ff8TL278uFHkHweLZZo1tVmXa0+33GvZMVLnWKFP106S7czZww1/ Hq/8PPr0k82rh22dfHCil1cvfpw8bs3QZJ/P139//3vKsdcegQUaeOBWCFIUXnP/ocSdaoy5 Vhh0FaqF3X9fMZidg00NBiF1zflX4WttYRggcgMquCKLLZ72Vnyk5aUigqV19+F+FOpXInz5 cRcjgBqaKKJ9belIFo/0hXhhQ0DuRmOLUUqZnpNNQhnUlQXamBCJOSZ2FVr0cTgkQ1ViSZ6E QS4V3XRsMtkgmQuZiVuWU9p5J23xiSajWkt6VSeBW6K4Z59ftnmoiTjGWd1RcjXVWaM9Lorm pIqcKUopo0G2ByienXoamZ6NJeodfp8exmRrpg35ImqidXlhqt9liKKQNIlq06oviujqaq6+ aeGJWpo6LLGyhYpqUnOeWWx9mVpZG6cgkVpmtNexWC2z2WoLGoaEjjrpdtoy96yxem0oJ7ZC TpnYtu26S5VrAFrq35/ivuvXvb35mC+//XaaLnoA9yuwv+ryWTDCCQe6LcH8NqxwuH5C/zwx xU8yXDFG42LcF6sQbvwxyH89/KRSmobcrbInY9mxxyq7/LJWI5P8YIQw1+yhzDYvyKrOPfuM L7Es5zys0EP/PFHKRystFM4sSyidak4X3d+0NcvaHdLi8ny00+1O/TXYYYs9Ntllm2300sXu eyqtUK/6ZrNq0htrrnBzybDEP2/NcAB9+/034IELPjjhhRt+OOKJK5442mmbeqmzMCIaadxX O2tfvGg62TidSX/cctCLiz466aWbfnoAnDuOp05dg+vm06CTptutaWUu57uq2+suAKj7/jvw wROu++rrQh73nGGWbOV8mq5pcrAinz099dVbfz3a2Gu/PffYh3QkPPjhi7848cVH2Tq7mFZe 6XjHr1/58rSyLVnv49t/P/7Z478//8ADWn//AihAxZXPfC5am9ziVyTKKYRu2dFVpjRGL0jR b4AWvODwqgJADHLQgv/rIAgHWEADXstTYKLMBkOowvvpb4UuHN8HX4g4kchwhv8k9NkIzeWe 9dSwh/7ToA+DaLoY9q8kgqOhEFGXwxsykS5LzEkSo0g+IEqxioUjYhFT2DctWpFxTfxijSrD xS52sYVkPGPqvifCFLKxfkbcIhLhKMc5xhGDTwQjHjUoHDTy0Yx8tCIWAxjHNgJukACso99Y 1sE75rGRYLkcqP54Rj9KMoqBFGTvtIhIQyaSi4gEISMdWRxbUS5Vx2vZjwQGJc9pqJJlpKIr LalGD2byiBu85SEHCcdbLlKUFEOM3W73vkd1Rpi5WSUruzLGWNaQkszs4SUxObw3drKO1Kzm MgXpS4jFyEx5m8qPNHel54kTXMSs4DOT6Mx0vjCa7FyEYSi3mSfaqUhyuGKUMYGzNTFhJ5nP eWcQ1wnQELpzoL2UJ8K6yR5BUdBt+XSI8qDHNn9ux6DNhKVFVVjQjHoQoQk7C/Q0FidV/cp9 adoLKSGJz3g2kKMuFKhLRTjLmHKQpR4Vzzdn16pd6dQ6PJvamG5kuXsm6nXmoilBMYrUjm4k m0vN/99No7qczLzPNk+tqVKvWsSZ0jJwp0mdU0f3yf3ZVKpmpeAetcrUzKhVpk1l3FjHSjpO +i6s/CvrWc+K1zK11a1s7etW3wrXIwZPrkO0K1nzqtgZlQew2oTXYOcI1slKlq7X9KobDatO rhpuk4XMLFhpiMRrWrO0dMxlJ/9G2sxm8quUnetiY2stzyDWsXXN6gydGlc2TrOQfeRsZw/5 WVa9VrW4/Gxqr0jX5BZ3sqYt3V5lu83oymmuyxztJo8b3F1OEreH02xzqwnX64L2q9j17Wl3 2dohAne7mvQkfI2LXMnOd7mVJeRzYSvd/cYsNrVNZHibS0j59la13YWsWP91q2DEXlaRuwWw el0LXi8Klny1HK6BH8zc+wr3tfYtrjXpO+EM8rfEVPWvWOkr3sHld5rklaN512vg5IrWiCM+ one3q1zCGneMbUQtZlnsxg0TWInt1bEtsZvdGkt4tT8O7Ypdq15sTlm/Jr4yUYwlOu0mOcgB Vu6PXxReXWIzxrdF8JYVbMv5epm5pP2yaHs84xt39si2LSyW89wT6laXgGzeIobdHNYnq7jQ lOVykdmL5vFeNsK8DW02WQtfJft40rmkM4kzdmeo6rnTHeFzn2e4ZiK3uNGJ9nCIH0xoQGOa xTne9O82Cmsje7rWeNHydxss4So7usee5LWvgU0NZCpDmtZ/nXX4ZI1s6PrautkLEs+yxQfT aDO7wtSOtbOz3aQ8XVt40+72FK0NbkVru9zR48x/x53poaRb3V61c7JZS1NQmxtm9A61u6t9 7HyLFd7efrRL711vlQmcS/wmN7sPbuWMCNDU6TWzgGks6S/DcOAWL7hZFL5wpml8y/6W9pLF rOHUlfmNrcazxc2N8Yx3PNz7bnmdxc3CQAdYrqMdtqHvmnKV0wnmBHy1zxP5cf8NGMoAtvmF uQvhk/9w59pe+VqCbsNFSx3HMrffxDFLaSEn+dLtxrbTnQ31qFf9ikCXurKDPvawF2ztECm7 2akOd6Fffe5uZ3u+7p6Subta7nxPu8/1mY533umL71Z/ueEBD3PBD/5iTzL8u/1u96EvvvF6 ZnxLIF/Is6ud8i3HvOWD5puvK/zbaPd8x0Ef+seNXvOqJZojVb96MKqe9AeX/U5wbxzZzb73 ECWO7fmt+6niEYK+P37WWu/6LcKe9ntDPvQbuLrhq4f6netY9LO/Q6XxnvZfBKr2w19VnRl/ uk1sjUTFP3vro/D5omS/vv/UL//xv0xo8oS/xeYffvzbpmjmbyT/6d/GBCDHEEb6MREBiocA al8CgkpUNaB/LWD0QSBv3BQF0pYEQt8Fisx58FO5AGAGHt8GciC1NFBpIJD6TE5GUN8ICkcI +l4L8gXtqI9gMBCQnNMKCkjsvWDvxaAO4Q4NwsgESR+l9MoJBpXtUJQyackQViAPWp4P/uDd 2A0SGol5DOG8yE1JbcaAeMuDiAqhdJ9RQdTYZc+HfGHuReETftoNaQYKXs6rpGCGCJO3SAqZ KOFzZMxtANOsOIY/4WG9YM0C6SEVJt8aVowaBsYU2iAKptT2IYu8TFCvoBshmmB0dOGiZCFR vYoKGOYh7PShRQCiHP8eosMgoFDx1ErZColMiI+YEg7iCq8QCQbmoCWa4HA04ZFA4h2Gkhvm R6N8IRoSVY+MiKDUIScCIzmR4vmYogVWIpecEJw8Ivp4iRbuoiLWIvxgHx9ao1E50LcgSRMq o4Ik4jV6VJYcyyDaEyNSoy6+TTk+4/psYzXCiqGwBgLFiweKo7AwozmGYvk9UA1azdN8hyoO oz0WpBTC4xkahTzeDvrZ4xaiSt3oYwnxI0KRI2DcItWcYCs2DUdGo4yY0uzI4s10IkXu3vc9 4A6eZL1h5DtGjcR8DUzyHng4Xh65JEsaCE7WBZjco5pEZCmFo53sZELmZLMRpROpYEQpZU9/ xg8EAeMDEWRjiKQLgqBRMtDOrOT53YjsLOXr5I2SEGOhzON6aKX8eSE9NRVSviQJ9eTBqGAh 2iJZymEwGmFVkstEQmReYk5A7uPvqWXtMI/7yaT9IWIX1okogsxaztZcStTmFElYwk4y5iPH AAdWss9l9uUoHscV/iGnOORPcv8jN9WjMW5JiMSiHYLHaU7lYkZPa5ZKOsrjAUYjhRSh8S0F Q1GmDFpmIXol+9RjhDwPWkbNSG4mvPzlhFRhUdThWzLlJzrPa/KmVKomQFLnWNLjLxKj++GN /BhQdO4mGXbjl/zjJQbldKJPbgplf5UJ3Ewidr6HEJKnY6rnwLglovjmZNZOfo6h1tCMQBbP dxYlNgaHbxJhUEWmm+xnXIYLugzm3DwoUGZnLz4nxiDG8vgKSjmlJGqolygQ77hOW6pkeFYh FW7OPWJhiYThhialgZJlab5niapngf6SfC6Jn9yoh0SlQOIobiZLgJ7njzJoP1ILj/qoKnZT cTYIWKalkkd+5H8GIoVuoo8WioKmYHIO4oJ+X5BaRk6Zz5bypFlepT59KX4k5gCK6E2KqaeR qSdu2+6ZqZAWn5pSSffUqZ3eKZ5WT8C4aUYiZhmG6Zzu3vJp1J4CIZUKoi0uZIcCZFmsIpaK EaCe5HZmaUYOalJ1ILqYJ3wCZ7NAKIwWYWNCasZwJpyGRKCWKk9aKigVKjzO40PJZpUi6Kdy 4a31qVoKaEi4/83qoWMSnqGqqE7wqeqZ6SA25uWr2ud1fqNoKislJsiinlSiQqsVGmmjOiKl rucxhWrK8aomNiooYomwYhWmZmo76iVXRmI7Ssc07iWtZqWLzud9eCqzto62wuYxaSh1uqJU Hmpz3uQe3gpz9lTMhKsdsWqLeudWNKJ+Iit0GiuKRgqqjmoaruuyklOVGqeXQqO5bixcJhzB rlWK/EaIumu6vmEmrk23lhO6MhZorOgB1qXLxp7Clus+nYvkfSwLGez9+aOLBiajwqgmvuLG RmytsiHEPux9puds6mOw4my/4ZQboumz2Qy2eKO6+qqKKu21kmLTOq3LGQt5sqmjNFmVvQVq B3rtY80T9tFfmlql2XIm2gYWtICoBgFiC4qtHr0t3MZtYs1tl9ZtCYrsOEaq3vYc33Ia2BIt 8wxjj1Lr/BwI3h5n4Y7S4SJueYAp0GqtbQ6uo9htyP9OLvBVbs76S2QmY7U+avU5UVoK7uix 7ugprsqJLta1nbzGqkmlroYEo8De5jfJ3i2Cip8+YdfK7uHVZ3HippH06uPqpMGYq+2i7gce LPJK6yUqKr8SJ0446mUK4PAS7+Z534oQT+ky1Olub/Q+p3tipk+t7LyKlG6qX/d6L91ZJOfG TO1qLsXmX6uWbGYybBKyr8rOqgTGr/ym0dvyCMZma0nyydX2q++SK/+GlP8+b4Ry7AAXsLcV LnXgjP62LgTbIbPua+aurNC+KA8SsPxG7sQUZp58rqGCLg8RnRKhMPgwHbGlrd6ubUr+JQxH 0n3h3J9ZFygh2o0VnQ3rW3lFSurfAmgPF96oEVCwHrEMF9mIZZe4TqdRmuTSqPDgVRrXoRqB bR2qnZfESVp5hViBCZoaq5gVQ5mZiVmxUZyRLvEhcjHT/zTx4z2xrzVZyZFxeq2xxFHxkIGZ lBkaNbUxG8tYorXY97IwHjsOsFaLHSvmFwcxIP+ZH4NxGHPZze1YGh8akG2YFX9SqV1X7MDu I2dLJPMpez6yF2vdnF1aLM8YiBGxKOPSoEVaKH8YIpPcmBGxKT8jKqey6PFH4I5oD79XId9w ITdza3kdsDmzGAMaIe+WIT2zeBEXMztZ1i3z/L4wMZNfZhzhN6Ysf14lDSOZIPXVJIczT+QM P1kn9SZwTqazi9kzzalVO7uztLCby5qu6dIzS+Jz5e4zP+eGP7MvBS+tmBL04Rr0QZvqOOPg ck4vLL6vmjo030J0REtsBLoyBhmjXEd76UenskbHLUePtLOqdAyH9LCydNqkcXRLujTYwXRM 2zQ60fTpyLRNdyVO+7BOI9xPD2DYDnWlBrVQG7Vhri1Pl9tJo21T47QjK/VRITUSUzWN0jFW W4ZVX/VWJ5QWfzV+dPXGifXAmLUYkfXTojVbY9lTe21Ut7Vc/4lae9xc37VsvbXTxjVeQ/c1 x9X1z/m1YD8gYAf2YB/2dBU2hSE2YwOgYk9dY0e2ZE82ZVe2ZV82Zme2Zm82Z3e2Z382aIe2 aI82aZe2aZ82aqcytmqvNmu3tmu/NmzHtmzPNm3Xtm3fNm7ntm7vNm/3tm//NnAHt3APN3EX t3EfN3Int3IuLzdzN7dzPzd0R7d0Tzd1V7d1Xzd2Z7d2bzd3d7d3fzd4h7d4jzd5l7d5V0ZA AAA7 --------------070006030904080705040309-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu Dec 5 22:22:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11731 for ; Thu, 5 Dec 2002 22:22:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB63OeJ13561 for speechsc-archive@odin.ietf.org; Thu, 5 Dec 2002 22:24:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB63Oev13558 for ; Thu, 5 Dec 2002 22:24:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11723 for ; Thu, 5 Dec 2002 22:21:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB63OSv13544; Thu, 5 Dec 2002 22:24:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB63Nav13492 for ; Thu, 5 Dec 2002 22:23:36 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11709 for ; Thu, 5 Dec 2002 22:20:36 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Speechsc] SPEECHSC & usage of SIP Date: Thu, 5 Dec 2002 22:23:26 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2485BA@zoe.office.snowshore.com> Thread-Topic: [Speechsc] SPEECHSC & usage of SIP Thread-Index: AcKb/3j/NEnL3ABVRkiN84f6WORqswA0ioYw From: "Eric Burger" To: "Skip Cave" Cc: "IETF SPEECHSC (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB63Nav13493 Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Although it may look like it, I'm not necessarily fond of SIP as a control protocol. However, it is worth looking at these objections. I don't think any hold. > -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] > A comment on the usage of SIP or RTSP as a speech server > control protocol: > > It is important to realize that in a distributed control > architecture, > the application execution engine may be separate from the telephony > platform. An example of this type of distributed architecture > is shown > in the attached figure. Looking at the picture, it is very likely the application execution environment (a.k.a. telephony application server) understands SIP. How do you think CCXML gets pushed around? Also, if the execution environment understands VoiceXML or SALT, then it by definition is tightly coupled with a media processing entity. That's why people push VoiceXML interpreters into media processing entities :-) > In this example, control commands are sent from the application > execution server (a VoiceXML or SALT browser for example) to the > telephony platform, as well as the ASR, TTS, & Verification > servers. In > this scenario, the controlling entity (application execution > server or > browser) is not co-resident with the telephony platform. In fact, the > browser client does not support media streaming at all, nor > does it need > to. The browser simply sends commands to, and receives status > from, the > ASR, TTS etc. servers. That is the model. > Of course the browser must initially tell the TTS and > telephony servers > where to send their media (RTP) streams to, and tell the ASR & > Verification servers where to get their media streams from, > but in this > distributed architecture, the controlling entity never sources or > terminates media streams. > > I don't believe either RTSP or RTP supports this configuration very > well. RTSP absolutely does NOT assume that the host issuing the RTSP commands touches media. That is why RTSP carries SDP. RTP: now we've got something: yes, RTP assumes media processing. Then again, I don't think RTP is one of the protocols under consideration. It's a media protocol, not a control protocol. > Both of those protocols assume that the entity that > originates the > media/control session will also handle media streams, and as this > example shows, this is not necessarily true. None of the important SIP platforms (proxies, location servers, redirect servers, applications servers) have a media stream. I don't get the point of the statement "the controlling entity never sources or terminates media streams." That is the definition of the application server: it doesn't touch media. > In order to allow for these types of architectures, the > server control > protocol needs to completely separate the control & media > pieces of the > protocol. Within the overall SpeechSC architecture there should be a > SpeechSC control protocol, and a SpeechSC media protocol. I > would assume > that RTP could be the media protocol. > > The SpeechSC control protocol needs to have commands that > will tell the > servers where to send media strams, but the "send stream" command > shouldn't much different than a "play media" or "start recognize" > command. It should be pretty straightforward to define the sets of > commands to set up media streams, just like the set of commands to > control an ASR. The ITEF's SDP protocol (RFC2327) is great > for this type > of thing, and SDP doesn't assume that the controller has to > handle the > media. SDP, despite its name, is not a protocol. It gets pushed around by SIP and RTSP. > Another key architectural issue is the registration and discovery of > server entities by the controlling entity, and whether this > functionality should be part of the SpeechSC purview. > Registration/Discovery functionality will be required for a robust > distributed Speech system, but SpeechSc may not want to deal > with this > complexity, although there are several protocol standards > that have been > defined to deal with these issues already. THe SpeechSC group > may only > need to specify which one to use. Out of scope. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Dec 6 14:39:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21423 for ; Fri, 6 Dec 2002 14:39:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6JfcI16156 for speechsc-archive@odin.ietf.org; Fri, 6 Dec 2002 14:41:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6Jfbv16153 for ; Fri, 6 Dec 2002 14:41:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21416 for ; Fri, 6 Dec 2002 14:38:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6JfOv16138; Fri, 6 Dec 2002 14:41:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6JeLv16101 for ; Fri, 6 Dec 2002 14:40:21 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21384 for ; Fri, 6 Dec 2002 14:37:24 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB6Jdn0J026293; Fri, 6 Dec 2002 11:39:49 -0800 (PST) Received: from ORANLT.cisco.com ([161.44.238.36]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id EEX00631; Fri, 6 Dec 2002 11:40:29 -0800 (PST) Date: Fri, 06 Dec 2002 14:39:55 -0500 From: "David R. Oran" To: speechsc@ietf.org cc: Scott Bradner , Allison Mankin , Eric Burger Message-ID: <109631651.1039185595@ORANLT.cisco.com> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Speechsc] Revision of draft-ietf-speechsc-reqts based on IESG feedback Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have produced an update to the Speech Services Control Requirements based on the helpful feedback from the IESG. This revision addresses most of the comments. Some comments, such as those suggesting we get review from certain communities, are still pending, so this should be considerd an interim version not yet ready for formal reconsideration by the IESG. The authors are soliciting WG feedback to ensure these changes are in keeping with the established WG consensus on the requirements. The revision, in draft-ietf-speechsc-reqts-03.txt, should be available in the archives shortly. Please contact me if you want an advance copy; I'll email it to you. Note also that I got sick and tired of fighting with MS Word for producing I.D.s, and have converted this document to XML and produced the output using the xml2rfc tool. It is possible that errors were introduced in this process that escaped my proofreading. It would be helpful if some of the WG members looked over the entire document carefully as a quality control check on the conversion. IESG comments and responses (with corresponding changes to the document as needed) follow. Cheers, Dave Oran Comment set 1: - Title uses unknown (at least to me) acronyms. Response: There is a tradeoff betwen using acronyms and entering the contest for the longest title of an RFC/internet draft. For this version I have attempted to strike a balance by retaining the acronyms in the title, but ensuring that the acronym and its expansion is prominent in the Abstract. IF this does not do the trick, I'm perfectly happy to enter the longest-title contest. - Sect 2 talks about: OPEN ISSUES: This document highlights questions that are, as yet, undecided as "OPEN ISSUES". Id did not find any such opern issues anymore (which is good), So the note can be removed I think Response: correct, and the note on open issues has been removed. - I see a number of places where a notation of: ?some text? is used Is that normal practice? And what does it mean? See sections 5.8, 6.2.3, 6.3... others Response: all removed - I see normative references to "work in progress" Response: first, I've updated the references to the most recent versions. More to the point, we have our fingers crossed that the normative ones will be completed by the time the RFC editor is ready to publish these requirements. Specifically: . SSML is in W3C last call which closes 15 Jan 2003. . SRGS is now a "candidate recommendation", which is roughly equivalent to proposed standard. I would hope the RFC editor will consider this past the "work in progress" stage. - you should remove the reference to 2026 in the boilerplate since that will go away when it becomes an RFC and the RFC Ed will have to renumber all references - better you do that (or, better yet, don't use numbered references) Response: Removed. Kept numbered references since that is what xml2rfc does. - The framework drawing is confusing. Why is SPEECHSC on two lines? There needs to be more explanation of the protocol role in its two invocations. Give an example as well of using SPEECHSC in a SIP application, since this document is the first appearance of SPEECHSC and is setting up its role in the community. Response: The paragraphs describing the framework drawing have been modified to attempt to be moe illuminating. On the specific issue of the protocol appearing twice, this is now explicitly addressed by pointing out that either the media processing entity or the application server (if present) may be the client in the protocol exchanges. The idea of including a more complete example employing SIP could be quite useful, as long as it does not overly bias the reader in understanding and evaluating the requirements themselves (examples can be over-intepreted fairly easily). I'd like WG feedback on the desirability of including such an example, and solicit specific text if anyone want to take a crack. This aspect of the IESG comment I still consider PENDING. - The requirement of the VCR-like control is not for all use - and it clearly treads on RTSP as described in 6.5 - the section needs a qualifier that it is for uses of SPEECHSC where there is streaming material that can be controlled, not for realtime-produced media. I have some difficulty addressing this comment. Few if any of the requirements are "for all use" in terms of being employed under all circumstances. The controls are oriented toward the TTS usage, and that is why they appear in the TTS section of the requirements. There are some cases of very simple TTS where such controls can be eliminated, but generality and flexibility argues for their presence for all TTS usages. The fact that such controls "tread" on RTSP is not coincidental - the functions needed are a close match to what RTSP does for streaming media. I'd like some clarification on just what sort of qualification is needed on these requirements. The SSML framework in the W3C, for example, makes no useful distinction between "streaming material" and "realtime-produced" media, since many TTS systems freely intermix pre-recorded material with realtime computed material. I need some help here - so this comment is still PENDING. - Delete mention of msuri - it was not accepted as a SIP proposal on several tries Response: correct. This has been supplanted by draft-burger-sipping-netann-03. The text and reference have been updated. This is an informative reference and is not critical to the discussion, so if there are objections to the presence of the revised material, it can be easily removed. - Reference RFC 3351 (SIPPING Deaf Requirements) and consider what are specific needs here - solicit review by Arnoud van Wijk, the editor of RFC of RFC 3351 and Rohan Mahy. This should actually be generalized to handicapped needs, which Rohan can give pointers for; an example is under VCR-like control, where there needs to be superfast TTS playout for a blind user. Response: I have launched a query to the editors/authors of 3351 and Rohan Mahy. I have also added the reference and a general requirement to address the needs of handicapped users. This is PENDING until I get feedback from the community. - SI/SV: Is there adequate support for the the apps to deal with their needs to handle false positive identifications, beyond the MUST for offline analysis, since network noise and error will undoubtedly complicate the situation, and we should understand what purposes these functions will be serving. There should be very good timestamps and other features - privacy etc because of the abusability of SI/SV noise. Response: Agree with this observation, however since the applications themselves are out of scope (the protocol only provides the necessary control machinery), it is not clear just how to craft a comprehensive requirement for this. The point about timestamping the recording is an excellent one, and I have added text to this effect to the requirement. Suggestions for what additional text to add would be greatly appreciated. For example a false positive can be ascertained and acted on only by ex-post facto auditing using data not available at the time of verification. At that point it is not clear what beyond the recorded input, its timestamp, and the resultant verification output (which could easily be a probability ranking for candidates rather than a unique individual) would be valuable. [end of comments and responses] _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Dec 6 15:09:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22563 for ; Fri, 6 Dec 2002 15:09:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6KCGr17804 for speechsc-archive@odin.ietf.org; Fri, 6 Dec 2002 15:12:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6KCGv17800 for ; Fri, 6 Dec 2002 15:12:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22552 for ; Fri, 6 Dec 2002 15:09:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6KC6v17785; Fri, 6 Dec 2002 15:12:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6KBLv17727 for ; Fri, 6 Dec 2002 15:11:21 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22501 for ; Fri, 6 Dec 2002 15:08:23 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 6 Dec 2002 15:11:13 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2485C7@zoe.office.snowshore.com> Thread-Topic: Draft Minutes Thread-Index: AcKdUHa4Bkeg2zn+R/eRUkMiP8N7Pg== From: "Eric Burger" To: "IETF SPEECHSC (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB6KBLv17728 Subject: [Speechsc] Draft Minutes Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Please make comments to me or the list by next Wednesday (December 11). Speech Services Control WG (speechsc) Thursday, November 21 at 1530-1730 =================================== CHAIRS: Eric Burger D. Oran SCRIBES: Mary Barnes Joerg Ott AGENDA: Agenda Bashing Requirements Document Status (chairs) Protocol Analysis Document Open Issues Next Steps, Design Team Formation Agenda Bashing ============== Requirements Document Status (chairs) ===================================== Requirements Document: o Have submitted original requirements doc, under IESG review (not currently reflected by draft tracker). o two references #5. Protocol evaluation o Considerable work needs to be done Protocol Analysis Document Open Issues: ======================================= Beep (Jerry Carter) ------------------- o Jerry provided an overview of basic BEEP functionality. Intended to provide a common framework in which you develop other protocols. o To use BEEP: - Would need to define security. - And specific messages that would need to be supported. - Open Issues: - Resource acquisition - Extensions for request grouping - Extensions for service location and load balancing - Mapping session and RTP channels - Mechanisms for grammar naming and storage - Mechanism for storing and retrieving input - State preservation for multiple utterance SI/SV - Extensions for duplexing and parallel operations - How would SpeechSC integrate with BEEP security? - High level concerns: . Not a lot of knowledge about spec. . BEEP appears to be efficient, but not sure how effective it might be for this. Discussion: Carl: RTP? Eric: this is control protocol Jerry: the reference to beep was the logical mapping of channels. SIP (Rajiv Dharmadhikari) ------------------------- o Suggests that SIP is already being used for sessions, so can also be used for controlling resources. o SIP for MRCP had been previously proposed. o Would like feedback on requirements. Proposing the use of URIs. o Work needing to be done: o Summary. o Grammar sharing o State for multiple utterances Discussion: o Radika: SIP for mid session control, but SIP is not for media control. o How to do grammar sharing? o How to preserve state across multiple training sessions? o SIP not intended for mid-session control; had you considered using SIP for establishing the control channel and then another mechanism for the actual control? RTSP (Brian Wyld) [won't be in Atlanta] (discussed by Dave Oran) ---------------------------------------------------------------- High-order bits o RTSP is excellent semantic match for the problem domain o Fundamental problem domain is control of media servers o Many constructs that can be used directly (e.g. Play method) o State machines either match or would be very similar. o RTSP is proven and deployed. o No "magic-bullet" for barge-in control problem. No concept of asynchronous notification o May need new development, no matter what protocol. Things needed over base RTSP o Ways to express speechsc-specific constructs o Grammars o Session parms o Input capture o Methods for recognition and SI/SV needed o Record not a perfect semantic match o Method of doing barge-in control Discussion: o Joerg: Record may not stay that long in RTSP; removed this morning. o Jerry: Would any of the extensions violate the core aspects of RTSP. o Dave: it's a judgment call; there may be issues with tunneling. o Sarvi: it (tunneling) was ugly, but it worked. Didn't have to deal with extending RTSP. May be some roadblocks when dealing with RTSP itself. MRCP (Sarvi Shanmugham) ----------------------- Overview of MRCP: o MRCP was designed with the specific goal of being extensible in the future to address SI/SV. o Depends upon RTSP or SIP for setting up the media session. Chose to tunnel over RTSP rather than extending either. o Core methods, headers are independent of being tunneled over RTSP. o Ugly, but works o It already supports parallel usage. o Multiple interoperable implementations. Issues: o MRCP section of the compliance document needs to be updated to make the evaluation consistent with other sections. o Need to create or adopt a session level protocol capable of creating a control pipe and a media pipe, and then extend it with MRCP messages (to remove need for tunneling). o Need to add support for global or shared grammars to MRCP o Need to add MRCP resource extensions for SI/SV. o Consider how resources like the recognizer can be modularized and chained. o MRCP doesn't handle "sub-modules" Discussion: o Radika: SIP and RTSP would be good. Do you want one or do you want a new protocol? o Sarvi: MRCP by itself addresses the core of recognition commands. Looking for a protocol to establish a control session between client and server and be able to negotiate media pipe. o Radika: setting up of session, if either (SIP or RTSP) are suitable, suggest to allow both. o Sarvi: One could take RTSP or SIP as baseline and work from there to define the necessary extensions Web Services (Stephane Maes) ---------------------------- Overview: o Looks at the problem from a higher level. o Speech engines can be considered web services programmed by SOAP, WSDL (built on top of SOAP), WSFL and discovered via UDDI. o SOAP is bound to underlying protocol (HTTP, TCP, SIP, BEEP...) (per existing proposals) o Audio sub-systems and speech engines defined by WSDL interfaces: o Web services programmed with WSDL o Combined/composed with WSFL o Discovered by UDDI o Additional events and messages via SOAP and a la WSXL (coordination among web services) o Security can be provided by ws-security. Conceptual view o various engines are independent components o accessible through aforementioned interface o Each need to be associated with parallel streams of audio, etc. Issues: o Web services don't have syntax and semantics for speech control, however, it was designed to control any component. o There is no syntax and semantics associated to the control of speech engines (can be inspired from MRCP or other speech APIs) o The framework can be bound to numerous transports o Additional features are available today through tools and middleware offering rather than standard specs. o The evaluation assumes these characteristics are exploited: o IF no change is required and only syntax and semantics must be defined, then it's a T. The evaluation can be done such that most are Ts, with P+s being satisfied. o web services: generic framework and extensible o no syntax and semantics predefined o can be taken from existing syntax (e.g. MRCP) o works with multiple transport protocols o additional tools available through tools and middleware o nothing needs to be changed in web services o can satisfy all the requirements defined above Finalization of web services involves: o Integration of the web service framework o Specification of syntax and semantics o Optional selection of recommended transport product. Discussion: o Dave O: the architectural model shows the media being carried in separate RTP channels. Is there any support in web services for setting up and tearing down sessions. Or would this have to be recast in web services framework? o Stephane: it would have to be recast inside the web services model. o Dave O: glaring missing piece for asynchronous notification for barge control. o Stephane: XML event exchange on SOAP gives you interaction (asynchronous), but may still have the problem with delay, race conditions. o ? on RTP. How do you synchronize event timing? o Stephane: it's the same answer. The engines are characterized by sink/source ports and this work would need to be done in the IETF. o Has Web service been used at the protocol control level? Is latency a concern? o Stephane: web services for controlling is being done by Parlay. There will likely be the same race conditions as other protocols for the asynchronous notification for barge control. o Radika: Basic problem, setup and negotiation of session and this proposal still doesn't address how you could do that? o Dave O: only a small subset of the requirements deal with session setup. The majority of the requirements are about command and control within a session. o Stephane: nothing prevents using SIP for negotiation and the use SOAP for command and control. Definitely won't use web services for negotiation. o Joerg: You've explained the framework, but there would be a lot to be done to get the necessary functionality. If one was developing a protocol from scratch, what would be the difference. o Stephane: syntax and semantic of the programming of the engine (API) would be the work. o Joerg: Is this approach a bug or a feature? Any further questions? o Radika: We have the solutions for everything, we just need a control protocol. o Karl: About 5 years ago, did IP TV and used RTSP for control. Lots of issues with interacting with RTP and users. Can't start anywhere in an RTP stream. Many receivers need to the message to get a timestamp. How do deal with starts and stops? Users are used to mechanical things; there appear to be lots of user concerns. o Dave O: Requirements is in the hands of the IESG; if there are additional comments, please provide. o Markus: RTP synchronization; RTSP synchronization needs some work to get it to work properly. o Dave O: in the requirements, there is a specific synchronization requirement (must almost instantaneously stop). IF there are other syncs needed, these need to be provided. o SIP is intended to initiate sessions. It's not a good control protocol or a good transport protocol. Could perhaps use to set up audio in parallel. o Sarvi: not talking about tunneling MRCP over RTSP or SIP. SIP is good at setting up and modifying a session (RTP pipes and negotiating params). If SIP were extended to solve recognition and TTS problems, it would complement SIP. o SIP is fine for session associations. You don't need to add MRCP stuff to SIP. o Sarvi: if we were take MRCP and make it a protocol, need a way to setup a session (pipe) and negotiate a media stream. Believes MRCP is Complimentary to SIP. o ?: SOAP sessions over SIP (Ubiquity draft). o Peter : Importance of fast response to any user interaction o Eric: SIP is good at setting up a session, RTSP is okay at doing that. It's all the commands that come after setting up the session that is really the issue. o IF you need to negotiate media parms, RTSP is not good for that. AD left to go get a projector, which had died. Next Steps, Design Team Formation ================================== o Need consistent analysis framework: T is right now. o Date for completion Discussion: o Stephane: agrees in principle. o Dave O: have combined 2 approaches under one umbrella. o You can evaluate as an existing protocol which can modify or extend. . (MRCP, RTSP, SIP) o Framework of choice for new protocol. . Web services & BEEP. Proposes that criteria for framework would have to be different. Document was not intended to cast something in stone and give guidance to protocol development. Evaluation helps them to look at tradeoffs for various starting points. o Jerry: It is true that any protocol can be made to appear to work. Something like web services depends upon what messages you create. o UDP could do anything. Same applies to BEEP or web services. o How much needs to actually be done. o Sarvi: In the context of framework, MRCP analysis - SIP also falls under framework category. o Rajeev: Job to get right Ts, Fs, Ps; what are the things that we don't want done? o Stephane: protocol vs. framework is a good one. What's the outcome of the evaluation. Some overlap where things are complimentary. o Dave: keep in mind end goal. o Karl: one aspect of protocol choice; it will be implemented o ..... o Discussion around doing further work to detail the syntax and protocol impacts. There is general support, but it's a lot of work. . Mary Barnes: MIDCOM experience o counting P+ and other marks o people arguing about which marks to get o not much consistency in the end o numbers could not really be compared . Really clear usage scenario(s) needed. Identifies these so that we have a target. . Worthwhile thing to do this. Upside: educates the community. Downside: more difficult to step back for those involved. Four out of five analyses will be thrown away. . C: Good idea. Helps to identify how much work is needed. . C: In principle, a good idea. But this is much work. Shouldn't this be part of the design process. . C: May educate, but may not help the evaluation. Will cause more time to be spent. o Scott B: motherhood stuff is okay, but it seems like the idea of tossing it to design team isn't a win. Need a little bit more evaluation. o Jerry: 2 tiers of problems: 1. existing protocol 2. new protocol (i.e. with framework). The framework ones are more work. o Dave O: Framework vs existing protocol issue; with protocol, wouldn't you end up with a sub-optimal solution. o Scott: Bob Braden; the strength of the internet, we didn't optimize things, but made them flexible. o Dave O: the intent wasn't to focus on efficiency, we want to maximize flexibility. . o Scott: in the SIP world; a reasonable argument can't be made for ability to extend. o Rajeev: vendor perspective; we have to be pragmatic; timing is critical and skill set is different o Stephane: rapidly available should be a priority. o Michael: agrees with flexibility of web services model; is there a liaison to that community? o Dave O: have already established liaisons. o Scott: Friendly reception from base control could be an issue. Footprint might be an issue. o Stephane: some of these are captured in requirements. Web services doesn't necessarily take a big footprint. If you follow one of the approaches that is carried by the industry and there are significant work, you may have a better chance to address all those issues. o If you look at it practically, most of the industry from which is being borrowed (media servers and speech recognition vendors). Will these vendors be ready to do web services? There are metrics available today. o .... o Stephane: lots of mis-conceptions about web services. o Sarvi: requirements about server to server communication? VXML browser running on a gateway or a small PDA or a phone and you access to a TTS-type resource, thus it's not server-server, but rather client-server. Terminals, as well, need to be considered. o Stephane: didn't see this restricted to server-server. o In the end, protocol needs to be lightweight. Going forward: o Does group feel it can start with a protocol while finishing evaluation? o One team or more than one team? Discussion: o Stephane: believes this could be done. Concern over evaluation. o Scott B: One team only! Conclusion: General hum vote support for this. Revisit milestones: =================== Completing document: o Task 1: Recast the document into 2 categories (framework vs. protocol) o Task 2: align ratings. o Task 3: consistency due to multiple authors. o Task 4: make sure each protocol sections has a summary that makes clear the strong points and weak points. After that (2-3 weeks), WG chairs will decide if it's ready for design team. Discussion: o Scott: don't necessarily need to publish as an RFC, but could be useful input to design team (per experience with MIDCOM protocol evaluation document). o Scott: output from a design team has no more weight than anyone else's opinion. o Dave: why is doc still not in waiting state? o Scott: still watching (and not yet looking) o Dave: propose "gazing" state. Conclusion: Hum vote in support of path going forward. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Dec 6 15:16:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22803 for ; Fri, 6 Dec 2002 15:16:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6KIjr18121 for speechsc-archive@odin.ietf.org; Fri, 6 Dec 2002 15:18:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6KIjv18118 for ; Fri, 6 Dec 2002 15:18:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22777 for ; Fri, 6 Dec 2002 15:15:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6KIev18081; Fri, 6 Dec 2002 15:18:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6KBPv17743 for ; Fri, 6 Dec 2002 15:11:25 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22510 for ; Fri, 6 Dec 2002 15:08:27 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 6 Dec 2002 15:11:14 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2485CD@zoe.office.snowshore.com> Thread-Topic: Speechsc Jabber Summaries Thread-Index: AcKdVuXxGcGjA4QXQRiVSsa+aoCUyg== From: "Eric Burger" To: "IETF SPEECHSC (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB6KBPv17744 Subject: [Speechsc] Speechsc Jabber Summaries Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Dec 6 16:04:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24340 for ; Fri, 6 Dec 2002 16:04:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6L7Ck20761 for speechsc-archive@odin.ietf.org; Fri, 6 Dec 2002 16:07:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6L7Cv20758 for ; Fri, 6 Dec 2002 16:07:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24321 for ; Fri, 6 Dec 2002 16:04:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6L77v20634; Fri, 6 Dec 2002 16:07:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6L66v20347 for ; Fri, 6 Dec 2002 16:06:06 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24289 for ; Fri, 6 Dec 2002 16:03:09 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 6 Dec 2002 16:06:00 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2485D7@zoe.office.snowshore.com> Thread-Topic: Supplemental Web Pages Thread-Index: AcKda0Krzq16gAT9Rn+VWHcZTfXSbw== From: "Eric Burger" To: "IETF SPEECHSC (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB6L66v20348 Subject: [Speechsc] Supplemental Web Pages Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Incomplete, of necessity. Please send comments & suggestions directly to me. http://flyingfox.snowshore.com/i-d/speechsc/ _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Sat Dec 7 17:36:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08948 for ; Sat, 7 Dec 2002 17:36:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB7McSw06459 for speechsc-archive@odin.ietf.org; Sat, 7 Dec 2002 17:38:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB7McSv06456 for ; Sat, 7 Dec 2002 17:38:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08926 for ; Sat, 7 Dec 2002 17:35:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB7McHv06444; Sat, 7 Dec 2002 17:38:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB7Mbqv06424 for ; Sat, 7 Dec 2002 17:37:52 -0500 Received: from gbnewp0915s1.eu.ubiquity.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08922 for ; Sat, 7 Dec 2002 17:34:52 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 7 Dec 2002 22:37:13 UT Received: from gbnewp1014m ([192.168.1.100]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.4905); Sat, 7 Dec 2002 22:37:46 +0000 From: "Neil Deason" To: "Skip Cave" Cc: "IETF SPEECHSC \(E-mail\)" Subject: RE: [Speechsc] SPEECHSC & usage of SIP Date: Sat, 7 Dec 2002 14:37:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <4A3384433CE2AB46A63468CB207E209D2485BA@zoe.office.snowshore.com> X-OriginalArrivalTime: 07 Dec 2002 22:37:46.0411 (UTC) FILETIME=[439B4FB0:01C29E41] Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Skip Cave [mailto:skip.cave@intervoice.com] > > A comment on the usage of SIP or RTSP as a speech server > control protocol: > > It is important to realize that in a distributed control > architecture, the application execution engine may be > separate from the telephony platform. An example of this > type of distributed architecture is shown in the attached > figure. A reference model for SPEECHSC is shown in the requirements draft. +-------------+ | Application | | Server |\ +-------------+ \ SPEECHSC SIP or whatever / \ / \ +------------+ / \ +--------+ | Media |/ SPEECHSC \---| ASR | | Processing |-------------------------| and/or | RTP | Entity | RTP | TTS | =====| |=========================| Server | +------------+ +--------+ This is probably a better model to use as it makes no judgement over the use of CCXML, SALT, HTTP etc. The key point is there: SPEECHSC needs to support a usage model where either a Media Processing Entity or an App Server outside of the media stream controls the ASR/TTS Server. > In this example, control commands are sent from the > application execution server (a VoiceXML or SALT browser > for example) to the telephony platform, as well as the ASR, > TTS, & Verification servers. In this scenario, the > controlling entity (application execution server or > browser) is not co-resident with the telephony platform. In > fact, the browser client does not support media streaming > at all, nor does it need to. The browser simply sends > commands to, and receives status from, the ASR, TTS etc. > servers. > > Of course the browser must initially tell the TTS and > telephony servers where to send their media (RTP) streams > to, and tell the ASR & Verification servers where to get > their media streams from, but in this distributed > architecture, the controlling entity never sources or > terminates media streams. > > I don't believe either RTSP or RTP supports this > configuration very well. Both of those protocols assume > that the entity that originates the media/control session > will also handle media streams, and as this example shows, > this is not necessarily true. As already noted - RTP no, but then RTP is not a candidate SPEECHSC protocol. RTSP can support separation of the media control session. > In order to allow for these types of architectures, the > server control protocol needs to completely separate the > control & media pieces of the protocol. Within the overall > SpeechSC architecture there should be a SpeechSC control > protocol, and a SpeechSC media protocol. I would assume > that RTP could be the media protocol. The WG is only looking for a control protocol for distributed speech processing of audio streams. RTP can reasonably be expected to be the commonly used media protocol. > The SpeechSC control protocol needs to have commands that > will tell the servers where to send media strams, but the > "send stream" command shouldn't much different than a "play > media" or "start recognize" command. It should be pretty > straightforward to define the sets of commands to set up > media streams, just like the set of commands to control an > ASR. The ITEF's SDP protocol (RFC2327) is great for this > type of thing, and SDP doesn't assume that the controller > has to handle the media. I am not convinced that SDP is an optimal solution to meet the SPEECHSC requirements for playback controls. After all RTSP uses SDP to describe the media sessions being streamed (encodings, network addresses, content information etc.) but defines its own methods for playback control. This is one of the reasons why I think that SIP alone is not right for SPEECHSC. SIP does not have such playback primitives itself and as it is not intended as a control protocol such extensions would probably be inappropriate. SDP payloads, while readily carried by SIP, are not ideal for playback control either. Furthermore even if you define a more appropriate payload format, e.g. MRCP, SIP is not an efficient data transport protocol to carry it. However, SIP does have a great fit with the reference model for both modes of operation and is widely used for setting up RTP audio streams. At the same time as the audio streams are established the SPEECHSC control session could be established. Which still leaves what is the control session - it could be MRCP/HTTP, SOAP/HTTP|SIMPLE, RTSP,... To act as the SPEECHSC controller an App Server would be a SIP B2BUA, that modifies the SDP as it passes through it such that: 1. The audio stream is established directly between the Media Processing Entity and the TTS/ASR Server. 2. The SPEECHSC control session is established between the App Server itself and the TTS/ASR. Here is an example of what the SIP INVITE could be like if SOAP/SIMPLE was used for the SPEECHSC control protocol. App Server -> TTS/AS Server INVITE sip:autoattendant@mediaserver.ubiquity.net SIP/2.0 To: sip:reception@ubiquity.net From: 8dsf4i13@appserver.ubiquity.net Call-ID: fd835c@195.217.169.6 Via: SIP/2.0/TCP 195.217.169.6:5060 CSeq: 1 INVITE Content-Type: application/sdp Content-Length: ... v=0 o=appserver 2890844526 2890842807 IN IP4 appserver.ubiquity.net s=AutoAttendant Service t=0 0 m=audio 5004 RTP/AVP 0 c=IN IP4 131.160.1.112 a=rtpmap:0 PCMU/8000 m=message 49172 cpim/tcp application/soap+xml c=IN IP4 195.217.169.6 a=direction:both a=wsdl:http://schemas.ietf.org/speechsc.wsdl Here the the INVITE requests the TTS/AS to participate in an audio session with a media processing entity hosted at 131.160.1.112 and a SPEECHSC control session with the app server at 195.217.169.6. Purely for illustrative purposes SOAP is used and so a URL to the WSDL document defining the standardised SPEECHSC messages is added as an attribute within the SDP. A different proctol could similarly be used for the control session. > Another key architectural issue is the registration and > discovery of server entities by the controlling entity, and > whether this functionality should be part of the SpeechSC > purview. Registration/Discovery functionality will be > required for a robust distributed Speech system, but > SpeechSc may not want to deal with this complexity, > although there are several protocol standards that have > been defined to deal with these issues already. THe > SpeechSC group may only need to specify which one to use. While not within scope any additional benefits that the final solution delivers here would be a good thing. The application layer routing and session negotiation of SIP may be of interest here. As I would guess could be the larger Web Service frameworks of UDDI and WSDL. Cheers, Neil. -- Neil Deason 3 Lagoon Drive ndeason@ubiquity.net Suite 345 Ubiquity Software Corporation Redwood City, CA http://www.ubiquity.net USA _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Dec 9 08:06:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07678 for ; Mon, 9 Dec 2002 08:06:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9D9Bl32491 for speechsc-archive@odin.ietf.org; Mon, 9 Dec 2002 08:09:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9D9Bv32488 for ; Mon, 9 Dec 2002 08:09:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07624 for ; Mon, 9 Dec 2002 08:06:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9D93v32437; Mon, 9 Dec 2002 08:09:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9D6Pv31662 for ; Mon, 9 Dec 2002 08:06:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07414; Mon, 9 Dec 2002 08:03:29 -0500 (EST) Message-Id: <200212091303.IAA07414@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: speechsc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 09 Dec 2002 08:03:29 -0500 Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-reqts-03.txt Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Speech Services Control Working Group of the IETF. Title : Requirements for Distributed Control of ASR, SI/SV and TTS Resources Author(s) : E. Burger, D. Oran Filename : draft-ietf-speechsc-reqts-03.txt Pages : 19 Date : 2002-12-6 This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR) , speaker recognition - which includes both speaker identification (SI) and speaker verification (SV) - and text-to- speech (TTS). Other IETF protocols, such as SIP and RTSP, address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-reqts-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speechsc-reqts-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speechsc-reqts-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-6145627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speechsc-reqts-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speechsc-reqts-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-6145627.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 10 06:02:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03647 for ; Tue, 10 Dec 2002 06:02:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAB4ba20986 for speechsc-archive@odin.ietf.org; Tue, 10 Dec 2002 06:04:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAB4bv20983 for ; Tue, 10 Dec 2002 06:04:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03642 for ; Tue, 10 Dec 2002 06:01:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAB1Hv20901; Tue, 10 Dec 2002 06:01:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAB08v20863 for ; Tue, 10 Dec 2002 06:00:08 -0500 Received: from slap.mg2-lyon.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03587 for ; Tue, 10 Dec 2002 05:57:12 -0500 (EST) Received: from jpl (jpl.mg2-lyon.fr [132.147.160.27]) by slap.mg2-lyon.fr (Postfix) with SMTP id 19CFB10F11 for ; Tue, 10 Dec 2002 13:05:29 +0100 (CET) From: "Jean Philippe Longeray" To: "IETF SPEECHSC (E-mail)" Date: Tue, 10 Dec 2002 11:53:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01C2A042.B9597AD0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Subject: [Speechsc] SPEECHSC vs 3GPP Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0097_01C2A042.B9597AD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229 Rel5) architecture. It looks like SPEECHSC is very closed from Mp interface (H.248). Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net ------=_NextPart_000_0097_01C2A042.B9597AD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Do you = ever compare=20 SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229=20 Rel5) architecture.
 
It = looks like =20 SPEECHSC  is very closed from Mp interface=20 (H.248).
 
Could = SPEECHSC works=20 with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org),  MWIF (www.mwif.org)?
 
Regards.
 
Jean-Philippe=20 LONGERAY 
R&D = Director - Service=20 NODE
 
NetCentrex 
 
Jean-philippe.longe= ray@netcentrex.net
+ 33 4 72 53 61 = 33 - + 33 4=20 72 53 61 30
Mobile: + 33 6 = 76 48 34=20 95
http://www.netcentrex.net<= /DIV>
 
 
------=_NextPart_000_0097_01C2A042.B9597AD0-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 10 07:27:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04882 for ; Tue, 10 Dec 2002 07:27:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBACUJA25402 for speechsc-archive@odin.ietf.org; Tue, 10 Dec 2002 07:30:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBACUJv25399 for ; Tue, 10 Dec 2002 07:30:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04878 for ; Tue, 10 Dec 2002 07:27:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBACR4v25278; Tue, 10 Dec 2002 07:27:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBACQFv25252 for ; Tue, 10 Dec 2002 07:26:15 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04797 for ; Tue, 10 Dec 2002 07:23:19 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gBACQCfm019726 for ; Tue, 10 Dec 2002 04:26:12 -0800 (PST) Received: from stealth-10-32-254-179.cisco.com (stealth-10-32-254-179.cisco.com [10.32.254.179]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id EPE00015; Tue, 10 Dec 2002 04:26:34 -0800 (PST) Date: Tue, 10 Dec 2002 07:26:07 -0500 From: David Oran To: speechsc@ietf.org Message-ID: <429185866.1039505167@[10.32.254.179]> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Speechsc] FWD: Comments on Speech Services Control Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ------------ Forwarded Message ------------ Date: Tuesday, December 10, 2002 12:24 AM -0800 From: Karl Auerbach To: oran@cisco.com, eburger@snowshore.com Subject: Comments on Speech Services Control Below are some thoughts/comments I had on Speech Services Control from the meeting that was held at the recent IETF in Atlanta. Sorry for taking so long to get this written. I attended the meeting out of curiousity, so please bear with me if I repeat things that others may have mentioned or simply miscomprehended some basic notions. Some of these comments derive from the work I did on IP/TV, an RTP/RTCP based audio/video application. Since I'm not on the mailing list, I have sent these comments to you directly. If these make sense, you may wish to forward them to the discussion list. REFERENCE TIMING The matter of time is one that is important to any multimedia application - and I include speech services under the rubric of multimedia because what may seem to be a simple speech stream may actually be accompanied by other streams, such as written transcripts (imagine a "follow the bouncing ball" kind of application) or other tracks, such as a commentary, language translation, or powerpoint-like slide show. In all of these cases, there needs to be a time reference that can coordinate all of these streams. In RTP/RTCP a time reference to GMT is established by RTCP. But many applications have taken short-cuts and don't bother with RTCP. It is my suggestion that any speech services control efforts emphasize the need to actually use RTCP to create a believable reference to GMT for media streams. And I'd also suggest that any derived items - like words or phrases from a speech stream - have RTP media timestamps that are consistent with the timestamp of the stream from which they were taken. In other words, when a stream is broken into parts, the parts should bear timestamps showing where they came from in the original stream and not simply always start at zero. On an ancillary point - some RTP receiver implementations (particularly those that have to synchronize multiple RTP/RTCP streams, e.g. audio and video streams) do not even try to begin to render their output (whether that be audio or video) until they have heard an initial RTCP packet. This can mean a rendering delay of several seconds, which can be very frustrating to a user. TIMING - NTP REPRESENTATION IN RTP RTP/RTCP carries timestamps in an NTP format. It isn't easy to write fast and correct code to convert these NTP formats to the seconds/microseconds (or seconds/nanoseconds) formats used in operating systems and the language libraries. As is done in the IP checksum RFCs, it may be worthwhile to publish source code for these conversions. MEDIA FORMATS/CODECS Some media encodings use forward and backwards interpolations from base of key samples. (This may be more prevalent in video than in audio.) Such encodings are dificult to pick-up and play-out from arbitrary points - often playout must begin from a base or key sample. (In such cases, muting plus accellerated playout possibly can be used to hide the leading synchronization from the user.) When using codecs of this nature, it may be difficult to split spoken speech into discreet words without prepending sufficient codex synchronization context information to each word as well as an indication of when the actual word begins. In other words, raw media files for each word may not be sufficient; some additional wrapper will be needed to indicate the where (and when) in the sample the actual word sound begins and where/when it ends. There is an ancillary issue - there might be a temptation to transcode from original formats to encodings that are more easily chopped into discreet words. However, transcoding often causes loss of quality and comprehensibility. HUMAN INTERFACES Humans are used to buttons and knobs that have instantaneous effect. In a multimedia/speech control application, when the user says "stop", the stream must stop, and stop right now. When the actual source of the material is a remote computer and there is a non-zero transit time across the network, there can easily arise some ambiguities about where/when a stream has been stopped and what should happen when the stream is resumed. It may be necessary to require the receiving application to buffer a reasonable amount of traffic-in-flight that is received after the user stops a stream. (This can be made more difficult by the matter mentioned previously in which certain codecs can not be started at arbitrary points.) [This gets far more complex in multicast cases.] Arbitrary jumps through a stream can become quite a burden on the sender - some encodings may require the sender to read through the sending file to find the desired new start point. We found that it was sometimes quite useful to preprocess certain media files to build indices that could be used to accellerate jumps. --karl-- ---------- End Forwarded Message ---------- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 10 10:17:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10066 for ; Tue, 10 Dec 2002 10:17:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAFJoG05497 for speechsc-archive@odin.ietf.org; Tue, 10 Dec 2002 10:19:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAFJov05494 for ; Tue, 10 Dec 2002 10:19:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10048 for ; Tue, 10 Dec 2002 10:16:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAFGTv05103; Tue, 10 Dec 2002 10:16:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAFF7v04994 for ; Tue, 10 Dec 2002 10:15:07 -0500 Received: from slap.mg2-lyon.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09773 for ; Tue, 10 Dec 2002 10:12:08 -0500 (EST) Received: from jpl (jpl.mg2-lyon.fr [132.147.160.27]) by slap.mg2-lyon.fr (Postfix) with SMTP id 7D89E10F11; Tue, 10 Dec 2002 17:20:24 +0100 (CET) From: "Jean Philippe Longeray" To: "David R. Oran" Cc: "IETF SPEECHSC (E-mail)" Subject: RE: [Speechsc] SPEECHSC vs 3GPP Date: Tue, 10 Dec 2002 16:08:10 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <438690964.1039514672@[10.32.254.179]> Content-Transfer-Encoding: 8bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sure David, Find bellow a long URL to 3GPP Multimedia Call Model http://www.3gpp.org/ftp/Specs/2002-09/Rel-5/23_series/23218-520.zip and all others int www.3gpp.org/ftp/Specs/200-09/Rel-5 Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: mardi 10 décembre 2002 16:05 To: Jean Philippe Longeray Subject: Re: [Speechsc] SPEECHSC vs 3GPP Could you send a long a URL pointing to the doc so folks in the WG can take a look-see? Thanks, Dave. --On Tuesday, December 10, 2002 11:53 AM +0100 Jean Philippe Longeray wrote: > > Hi, > > Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229 > Rel5) architecture. > It looks like SPEECHSC is very closed from Mp interface (H.248). > > Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , > 3G.IP (www.3gip.org), MWIF (www.mwif.org)? > Regards. > > Jean-Philippe LONGERAY > R&D Director - Service NODE > > NetCentrex > > Jean-philippe.longeray@netcentrex.net > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > Mobile: + 33 6 76 48 34 95 > http://www.netcentrex.net > > ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu Dec 12 21:15:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20765 for ; Thu, 12 Dec 2002 21:15:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBD2Hcr02754 for speechsc-archive@odin.ietf.org; Thu, 12 Dec 2002 21:17:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD2Hcv02751 for ; Thu, 12 Dec 2002 21:17:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20756 for ; Thu, 12 Dec 2002 21:14:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD2EJv02665; Thu, 12 Dec 2002 21:14:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD2DQv02642 for ; Thu, 12 Dec 2002 21:13:26 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20725 for ; Thu, 12 Dec 2002 21:10:22 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Speechsc] SPEECHSC vs 3GPP Date: Thu, 12 Dec 2002 21:13:17 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D24860F@zoe.office.snowshore.com> Thread-Topic: [Speechsc] SPEECHSC vs 3GPP Thread-Index: AcKgPRVXQp7/bTsdT8ipmPPgTROLfQAHNzhg From: "Eric Burger" To: "Jean Philippe Longeray" Cc: "IETF SPEECHSC (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBD2Dfv02643 Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit The Mp interface is (1) not the right concept and (2) is itself (IMHO) not the correct choice for 3GPP's needs, either. With respect to (1), Mp is trying to be an analog to the MGC/MG decomposition for a media server, where the MRFC is a "media server controller" and the MRFP is a "media server [processor]". The types of resources are bearer packet processors (e.g., tone detection, prompt playing, and recording). The protocol is a low-level device control protocol (e.g., allocate a resource, allocate a RTP port, connect the port to the resource, wait for a signal, etc.). speechsc is a higher-level protocol, concerned with things like 'establish session' and 'recognize speech'. In fact, early in the days of MRCP/speechsc, people wanted to extend the speechsc scope to do device control. The answer has consistently been to use H.248 for device control. With respect to (2), AFAIK, no one has ever built a MRFC. I believe this is because unlike a media gateway, where there are definite decomposition benefits, there are really few if any benefits to decomposing the MRF. In fact, there are clear benefits to using the native application interface (SIP), rather than the native gateway interface (H.248) for interfacing the AS and CSCF to the MRF. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 10, 2002 5:53 AM To: IETF SPEECHSC (E-mail) Subject: [Speechsc] SPEECHSC vs 3GPP Hi, Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229 Rel5) architecture. It looks like SPEECHSC is very closed from Mp interface (H.248). Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Dec 13 02:34:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17307 for ; Fri, 13 Dec 2002 02:34:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBD7bYs31026 for speechsc-archive@odin.ietf.org; Fri, 13 Dec 2002 02:37:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD7bYv31018 for ; Fri, 13 Dec 2002 02:37:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17298 for ; Fri, 13 Dec 2002 02:34:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD7YJv30438; Fri, 13 Dec 2002 02:34:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD7XFv30350 for ; Fri, 13 Dec 2002 02:33:15 -0500 Received: from slap.mg2-lyon.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17175 for ; Fri, 13 Dec 2002 02:30:07 -0500 (EST) Received: from jpl (jpl.mg2-lyon.fr [132.147.160.27]) by slap.mg2-lyon.fr (Postfix) with SMTP id B55E210F1F; Fri, 13 Dec 2002 09:19:09 +0100 (CET) From: "Jean Philippe Longeray" To: "Eric Burger" Cc: "IETF SPEECHSC (E-mail)" Subject: RE: [Speechsc] SPEECHSC vs 3GPP Date: Fri, 13 Dec 2002 08:25:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <4A3384433CE2AB46A63468CB207E209D24860F@zoe.office.snowshore.com> Content-Transfer-Encoding: 8bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Thanks Eric for this analyze, I agree. H.248 doesn't seems to be the right answer for MRFC/MRFP, even if special packages can be provided. For my opinion, SIP is the correct answer for transport layer (since it's used everywhere in 3GPP and 3GPP2), and SPEECHSC could (should?) be used for resource control. Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing Protocols", I would like to add some remarks: In case of you would like to insert a routing mechanism (a SIP soft-switch) between Media Processing Entity / Application server and Resource server (ASR, SI/SV, TTS, Announcement server), I could be interesting to have a single transport protocol, like SIP, instead of several incompatible protocols (RTSP for example) for the closes functionalities. I think it is easier to add some redundancy, rather than conserving "old" protocols like RTSP. It seems to be very important to make distinctions between each layers of model. Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC, could be an answer. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: vendredi 13 décembre 2002 03:13 To: Jean Philippe Longeray Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] SPEECHSC vs 3GPP The Mp interface is (1) not the right concept and (2) is itself (IMHO) not the correct choice for 3GPP's needs, either. With respect to (1), Mp is trying to be an analog to the MGC/MG decomposition for a media server, where the MRFC is a "media server controller" and the MRFP is a "media server [processor]". The types of resources are bearer packet processors (e.g., tone detection, prompt playing, and recording). The protocol is a low-level device control protocol (e.g., allocate a resource, allocate a RTP port, connect the port to the resource, wait for a signal, etc.). speechsc is a higher-level protocol, concerned with things like 'establish session' and 'recognize speech'. In fact, early in the days of MRCP/speechsc, people wanted to extend the speechsc scope to do device control. The answer has consistently been to use H.248 for device control. With respect to (2), AFAIK, no one has ever built a MRFC. I believe this is because unlike a media gateway, where there are definite decomposition benefits, there are really few if any benefits to decomposing the MRF. In fact, there are clear benefits to using the native application interface (SIP), rather than the native gateway interface (H.248) for interfacing the AS and CSCF to the MRF. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 10, 2002 5:53 AM To: IETF SPEECHSC (E-mail) Subject: [Speechsc] SPEECHSC vs 3GPP Hi, Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229 Rel5) architecture. It looks like SPEECHSC is very closed from Mp interface (H.248). Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Dec 13 13:36:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01223 for ; Fri, 13 Dec 2002 13:36:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDIdMs03279 for speechsc-archive@odin.ietf.org; Fri, 13 Dec 2002 13:39:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDIdMv03276 for ; Fri, 13 Dec 2002 13:39:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01215 for ; Fri, 13 Dec 2002 13:36:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDIdEv03268; Fri, 13 Dec 2002 13:39:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDIcAv03244 for ; Fri, 13 Dec 2002 13:38:10 -0500 Received: from mail2.intervoice-brite.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01208 for ; Fri, 13 Dec 2002 13:35:06 -0500 (EST) Received: from 172.16.16.64 (gwsmtpsrv.intervoice.com [172.16.16.64]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with SMTP id MAA02862 for ; Fri, 13 Dec 2002 12:51:38 -0600 Received: from INTERVOICE-Message_Server by 172.16.16.64 with Novell_GroupWise; Fri, 13 Dec 2002 12:38:01 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 13 Dec 2002 12:37:41 -0600 From: "Skip Cave" To: , Cc: Subject: RE: [Speechsc] SPEECHSC vs 3GPP Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_9FC35519.ED8CDE12" Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_9FC35519.ED8CDE12 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jean, Eric, I don't think SIP will support the separated media/control requirements I = posted earlier. You will need a control protocol, and a separate media = protocol. I expect that it will take a new protocol to meet these = requirements. Skip Cave Sr. Principal Engineer Intervoice Inc.=20 >>> "Jean Philippe Longeray" = 12/13/02 01:25AM >>> Thanks Eric for this analyze, I agree. H.248 doesn't seems to be the right answer for MRFC/MRFP, even if special packages can be provided. For my opinion, SIP is the correct answer for transport layer (since it's used everywhere in 3GPP and 3GPP2), and SPEECHSC could (should?) be used = for resource control. Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing Protocols", I would like to add some remarks: In case of you would like to insert a routing mechanism (a SIP soft-switch)= between Media Processing Entity / Application server and Resource server (ASR, SI/SV, TTS, Announcement server), I could be interesting to have a single transport protocol, like SIP, instead of several incompatible protocols (RTSP for example) for the closes functionalities. I think it is easier to add some redundancy, rather than conserving "old" protocols like RTSP. It seems to be very important to make distinctions between each layers of model. Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC, could be an answer. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: vendredi 13 d=E9cembre 2002 03:13 To: Jean Philippe Longeray Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] SPEECHSC vs 3GPP The Mp interface is (1) not the right concept and (2) is itself (IMHO) not the correct choice for 3GPP's needs, either. With respect to (1), Mp is trying to be an analog to the MGC/MG decomposition for a media server, where the MRFC is a "media server controller" and the MRFP is a "media server [processor]". The types of resources are bearer packet processors (e.g., tone detection, prompt playing, and recording). The protocol is a low-level device control protocol (e.g., allocate a resource, allocate a RTP port, connect the port to the resource, wait for a signal, etc.). speechsc is a higher-level protocol, concerned with things like 'establish session' and 'recognize speech'. In fact, early in the days of MRCP/speechsc, people wanted to extend the speechsc scope to do device control. The answer has consistently been to use H.248 for device control. With respect to (2), AFAIK, no one has ever built a MRFC. I believe this = is because unlike a media gateway, where there are definite decomposition benefits, there are really few if any benefits to decomposing the MRF. In fact, there are clear benefits to using the native application interface (SIP), rather than the native gateway interface (H.248) for interfacing = the AS and CSCF to the MRF. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net]= Sent: Tuesday, December 10, 2002 5:53 AM To: IETF SPEECHSC (E-mail) Subject: [Speechsc] SPEECHSC vs 3GPP Hi, Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229 Rel5) architecture. It looks like SPEECHSC is very closed from Mp interface (H.248). Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --=_9FC35519.ED8CDE12 Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: quoted-printable
Jean, Eric,
 
I don't think SIP will support the separated media/cont= rol=20 requirements I posted earlier. You will need a control protocol, and a = separate=20 media protocol. I expect that it will take a new protocol to meet these=20 requirements.
 
Skip Cave
Sr. Principal Engineer
Intervoice Inc.


>>> "Jean Philippe Longeray"=20 <jean-philippe.longeray@netcentrex.net> 12/13/02 01:25AM=20 >>>
Thanks Eric for this analyze,

I agree. H.248 = doesn't=20 seems to be the right answer for MRFC/MRFP, even if
special packages = can be=20 provided.

For my opinion, SIP is the correct answer for transport = layer=20 (since it's
used everywhere in 3GPP and 3GPP2), and SPEECHSC could = (should?)=20 be used for
resource control.

Concerning SPEECHSC, 3.3 "Avoid=20 Duplicating Existing Protocols", I would
like to add some remarks:
In=20 case of you would like to insert a routing mechanism (a SIP=20 soft-switch)
between Media Processing Entity / Application server = and=20 Resource server
(ASR, SI/SV, TTS, Announcement server), I could be=20 interesting to have a
single transport protocol, like SIP, instead of = several=20 incompatible
protocols (RTSP for example) for the closes functionalities= . I=20 think it is
easier to add some redundancy, rather than conserving = "old"=20 protocols like
RTSP.

It seems to be very important to make=20 distinctions between each layers of
model.
Something like UDP/SIP/SPE= ECHSC=20 or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC,
could be an=20 answer.



Regards.


Jean-Philippe LONGERAY
R&= D=20 Director - Service=20 NODE

NetCentrex

Jean-philippe.longeray@netcentrex.net
<= mailto:Jean-philippe.= longeray@netcentrex.net>
+=20 33 4 72 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 = 95
http://www.netcentrex.net


-----Original=20 Message-----
From: Eric Burger [mailto:eburger@snowshore.com]Sent:=20 vendredi 13 d=E9cembre 2002 03:13
To: Jean Philippe Longeray
Cc: = IETF=20 SPEECHSC (E-mail)
Subject: RE: [Speechsc] SPEECHSC vs 3GPP


Th= e Mp=20 interface is (1) not the right concept and (2) is itself (IMHO) not
the= =20 correct choice for 3GPP's needs, either.

With respect to (1), Mp = is=20 trying to be an analog to the MGC/MG
decomposition for a media server, = where=20 the MRFC is a "media server
controller" and the MRFP is a "media = server=20 [processor]".  The types of
resources are bearer packet processors= =20 (e.g., tone detection, prompt
playing, and recording).  The = protocol is=20 a low-level device control
protocol (e.g., allocate a resource, = allocate a=20 RTP port, connect the port
to the resource, wait for a signal, = etc.). =20 speechsc is a higher-level
protocol, concerned with things like = 'establish=20 session' and 'recognize
speech'.

In fact, early in the days = of=20 MRCP/speechsc, people wanted to extend the
speechsc scope to do = device=20 control.  The answer has consistently been to
use H.248 for = device=20 control.

With respect to (2), AFAIK, no one has ever built a = MRFC. =20 I believe this is
because unlike a media gateway, where there are = definite=20 decomposition
benefits, there are really few if any benefits to = decomposing=20 the MRF.  In
fact, there are clear benefits to using the native=20 application interface
(SIP), rather than the native gateway interface = (H.248)=20 for interfacing the
AS and CSCF to the MRF.

-----Original=20 Message-----
From: Jean Philippe Longeray [mailto:jean-philippe= .longeray@netcentrex.net]
Sent:=20 Tuesday, December 10, 2002 5:53 AM
To: IETF SPEECHSC (E-mail)
Subject= :=20 [Speechsc] SPEECHSC vs 3GPP


Hi,

Do you ever compare = SPEECHSC=20 and MRFC/MRFP interface in 3GPP (TS 24.229
Rel5) architecture.

It= =20 looks like  SPEECHSC  is very closed from Mp interface=20 (H.248).

Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2=20 (www.3gpp2.org) ,
3G.IP (www.3gip.org),  MWIF=20 (www.mwif.org)?

Regards.

Jean-Philippe LONGERAY
R&D=20= Director - Service=20 NODE

NetCentrex

Jean-philippe.longeray@netcentrex.net
+ = 33 4 72=20 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 95
http://www.netcentrex.net

___= ____________________________________________
Speechsc=20 mailing list
Speechsc@ietf.org
https://www1.ietf.= org/mailman/listinfo/speechsc
--=_9FC35519.ED8CDE12-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Dec 16 03:17:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28770 for ; Mon, 16 Dec 2002 03:17:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBG8KYg04373 for speechsc-archive@odin.ietf.org; Mon, 16 Dec 2002 03:20:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBG8KYv04370 for ; Mon, 16 Dec 2002 03:20:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28757 for ; Mon, 16 Dec 2002 03:17:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBG8KRv04360; Mon, 16 Dec 2002 03:20:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBG8Jkv04295 for ; Mon, 16 Dec 2002 03:19:46 -0500 Received: from slap.mg2-lyon.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28748 for ; Mon, 16 Dec 2002 03:16:33 -0500 (EST) Received: from jpl (jpl.mg2-lyon.fr [132.147.160.27]) by slap.mg2-lyon.fr (Postfix) with SMTP id 0A5E010EFD; Mon, 16 Dec 2002 10:05:52 +0100 (CET) From: "Jean Philippe Longeray" To: "Skip Cave" , Cc: Subject: RE: [Speechsc] SPEECHSC vs 3GPP Date: Mon, 16 Dec 2002 09:11:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C2A4E3.22E8D190" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C2A4E3.22E8D190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi Skip, Nice to have some news from Intervoice... I agree. SIP will never provide multimedia control functionnalities, but I'm sure it's a great protocol from transport (and mandatory for 3G). WG has to define a couple of protocols, like MRCP/RTSP. What do you think of SPEECHSC/SIP, which can be very closed from MRCP/SIP. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: vendredi 13 décembre 2002 19:38 To: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Jean, Eric, I don't think SIP will support the separated media/control requirements I posted earlier. You will need a control protocol, and a separate media protocol. I expect that it will take a new protocol to meet these requirements. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Jean Philippe Longeray" 12/13/02 01:25AM >>> Thanks Eric for this analyze, I agree. H.248 doesn't seems to be the right answer for MRFC/MRFP, even if special packages can be provided. For my opinion, SIP is the correct answer for transport layer (since it's used everywhere in 3GPP and 3GPP2), and SPEECHSC could (should?) be used for resource control. Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing Protocols", I would like to add some remarks: In case of you would like to insert a routing mechanism (a SIP soft-switch) between Media Processing Entity / Application server and Resource server (ASR, SI/SV, TTS, Announcement server), I could be interesting to have a single transport protocol, like SIP, instead of several incompatible protocols (RTSP for example) for the closes functionalities. I think it is easier to add some redundancy, rather than conserving "old" protocols like RTSP. It seems to be very important to make distinctions between each layers of model. Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC, could be an answer. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: vendredi 13 décembre 2002 03:13 To: Jean Philippe Longeray Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] SPEECHSC vs 3GPP The Mp interface is (1) not the right concept and (2) is itself (IMHO) not the correct choice for 3GPP's needs, either. With respect to (1), Mp is trying to be an analog to the MGC/MG decomposition for a media server, where the MRFC is a "media server controller" and the MRFP is a "media server [processor]". The types of resources are bearer packet processors (e.g., tone detection, prompt playing, and recording). The protocol is a low-level device control protocol (e.g., allocate a resource, allocate a RTP port, connect the port to the resource, wait for a signal, etc.). speechsc is a higher-level protocol, concerned with things like 'establish session' and 'recognize speech'. In fact, early in the days of MRCP/speechsc, people wanted to extend the speechsc scope to do device control. The answer has consistently been to use H.248 for device control. With respect to (2), AFAIK, no one has ever built a MRFC. I believe this is because unlike a media gateway, where there are definite decomposition benefits, there are really few if any benefits to decomposing the MRF. In fact, there are clear benefits to using the native application interface (SIP), rather than the native gateway interface (H.248) for interfacing the AS and CSCF to the MRF. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 10, 2002 5:53 AM To: IETF SPEECHSC (E-mail) Subject: [Speechsc] SPEECHSC vs 3GPP Hi, Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229 Rel5) architecture. It looks like SPEECHSC is very closed from Mp interface (H.248). Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------=_NextPart_000_0008_01C2A4E3.22E8D190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi = Skip,
 
Nice to have some = news from=20 Intervoice...
 
I agree. SIP  = will never=20 provide  multimedia control functionnalities, but I'm sure it's a = great=20 protocol from transport (and mandatory for 3G).
WG has to define a = couple of=20 protocols, like MRCP/RTSP. What do you think of SPEECHSC/SIP, which can = be very=20 closed from MRCP/SIP.
 
Regards.
 
 
Jean-Philippe=20 LONGERAY 
R&D = Director - Service=20 NODE
 
NetCentrex 
 
Jean-philippe.longe= ray@netcentrex.net
+ 33 4 72 53 61 = 33 - + 33 4=20 72 53 61 30
Mobile: + 33 6 = 76 48 34=20 95
http://www.netcentrex.net<= /DIV>
 
-----Original Message-----
From: Skip Cave=20 [mailto:skip.cave@intervoice.com]
Sent: vendredi 13 = d=E9cembre 2002=20 19:38
To: jean-philippe.longeray@netcentrex.net;=20 eburger@snowshore.com
Cc: = speechsc@ietf.org
Subject: RE:=20 [Speechsc] SPEECHSC vs 3GPP

Jean, Eric,
 
I don't think SIP will support the separated = media/control=20 requirements I posted earlier. You will need a control protocol, and a = separate media protocol. I expect that it will take a new protocol to = meet=20 these requirements.
 
Skip Cave
Sr. Principal Engineer
Intervoice Inc.


>>> "Jean Philippe Longeray"=20 <jean-philippe.longeray@netcentrex.net> 12/13/02 01:25AM=20 >>>
Thanks Eric for this analyze,

I agree. H.248 = doesn't=20 seems to be the right answer for MRFC/MRFP, even if
special = packages can be=20 provided.

For my opinion, SIP is the correct answer for = transport layer=20 (since it's
used everywhere in 3GPP and 3GPP2), and SPEECHSC could=20 (should?) be used for
resource control.

Concerning SPEECHSC, = 3.3=20 "Avoid Duplicating Existing Protocols", I would
like to add some=20 remarks:

In case of you would like to insert a routing = mechanism (a SIP=20 soft-switch)
between Media Processing Entity / Application server = and=20 Resource server
(ASR, SI/SV, TTS, Announcement server), I could be=20 interesting to have a
single transport protocol, like SIP, instead = of=20 several incompatible
protocols (RTSP for example) for the closes=20 functionalities. I think it is
easier to add some redundancy, = rather than=20 conserving "old" protocols like
RTSP.

It seems to be very = important=20 to make distinctions between each layers of
model.
Something = like=20 UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC,
could be = an=20 answer.



Regards.


Jean-Philippe = LONGERAY
R&D=20 Director - Service=20 = NODE

NetCentrex

Jean-philippe.longeray@netcentrex.net
&l= t;mailto:Jean-philipp= e.longeray@netcentrex.net>
+=20 33 4 72 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 = 95
http://www.netcentrex.net

<= BR>
-----Original=20 Message-----
From: Eric Burger [mailto:eburger@snowshore.com]<= BR>Sent:=20 vendredi 13 d=E9cembre 2002 03:13
To: Jean Philippe Longeray
Cc: = IETF=20 SPEECHSC (E-mail)
Subject: RE: [Speechsc] SPEECHSC vs = 3GPP


The=20 Mp interface is (1) not the right concept and (2) is itself (IMHO) = not
the=20 correct choice for 3GPP's needs, either.

With respect to (1), = Mp is=20 trying to be an analog to the MGC/MG
decomposition for a media = server,=20 where the MRFC is a "media server
controller" and the MRFP is a = "media=20 server [processor]".  The types of
resources are bearer packet = processors (e.g., tone detection, prompt
playing, and = recording).  The=20 protocol is a low-level device control
protocol (e.g., allocate a = resource,=20 allocate a RTP port, connect the port
to the resource, wait for a = signal,=20 etc.).  speechsc is a higher-level
protocol, concerned with = things=20 like 'establish session' and 'recognize
speech'.

In fact, = early in=20 the days of MRCP/speechsc, people wanted to extend the
speechsc = scope to do=20 device control.  The answer has consistently been to
use H.248 = for=20 device control.

With respect to (2), AFAIK, no one has ever = built a=20 MRFC.  I believe this is
because unlike a media gateway, where = there=20 are definite decomposition
benefits, there are really few if any = benefits=20 to decomposing the MRF.  In
fact, there are clear benefits to = using=20 the native application interface
(SIP), rather than the native = gateway=20 interface (H.248) for interfacing the
AS and CSCF to the=20 MRF.

-----Original Message-----
From: Jean Philippe Longeray = [mailto:jean-philip= pe.longeray@netcentrex.net]
Sent:=20 Tuesday, December 10, 2002 5:53 AM
To: IETF SPEECHSC = (E-mail)
Subject:=20 [Speechsc] SPEECHSC vs 3GPP


Hi,

Do you ever compare = SPEECHSC=20 and MRFC/MRFP interface in 3GPP (TS 24.229
Rel5) = architecture.

It=20 looks like  SPEECHSC  is very closed from Mp interface=20 (H.248).

Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2=20 (www.3gpp2.org) ,
3G.IP (www.3gip.org),  MWIF=20 (www.mwif.org)?

Regards.

Jean-Philippe = LONGERAY
R&D=20 Director - Service=20 = NODE

NetCentrex

Jean-philippe.longeray@netcentrex.net
+ = 33 4=20 72 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 95
http://www.netcentrex.net

_= ______________________________________________
Speechsc=20 mailing list
Speechsc@ietf.org
https://www1.iet= f.org/mailman/listinfo/speechsc
------=_NextPart_000_0008_01C2A4E3.22E8D190-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Dec 16 09:27:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06000 for ; Mon, 16 Dec 2002 09:27:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBGEUHA23918 for speechsc-archive@odin.ietf.org; Mon, 16 Dec 2002 09:30:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGEUHv23915 for ; Mon, 16 Dec 2002 09:30:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05979 for ; Mon, 16 Dec 2002 09:27:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGEUBv23901; Mon, 16 Dec 2002 09:30:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGETxv23853 for ; Mon, 16 Dec 2002 09:29:59 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05956 for ; Mon, 16 Dec 2002 09:26:56 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Speechsc] SPEECHSC vs 3GPP Date: Mon, 16 Dec 2002 09:29:55 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D0975EA@zoe.office.snowshore.com> Thread-Topic: [Speechsc] SPEECHSC vs 3GPP Thread-Index: AcKk2+LWickvBfTVQTiyYFM5raYYRgAM1Ubw From: "Eric Burger" To: "Jean Philippe Longeray" , "Skip Cave" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBGETxv23854 Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit From a personal perspective, the MRCP over SIP proposal was what pushed me over the edge to fix MRCP. I would be hard pressed to try to convince the IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, ... We need to pick the one that makes the most sense. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Monday, December 16, 2002 3:12 AM To: Skip Cave; Eric Burger Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Hi Skip, Nice to have some news from Intervoice... I agree. SIP will never provide multimedia control functionnalities, but I'm sure it's a great protocol from transport (and mandatory for 3G). WG has to define a couple of protocols, like MRCP/RTSP. What do you think of SPEECHSC/SIP, which can be very closed from MRCP/SIP. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: vendredi 13 décembre 2002 19:38 To: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Jean, Eric, I don't think SIP will support the separated media/control requirements I posted earlier. You will need a control protocol, and a separate media protocol. I expect that it will take a new protocol to meet these requirements. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Jean Philippe Longeray" 12/13/02 01:25AM >>> Thanks Eric for this analyze, I agree. H.248 doesn't seems to be the right answer for MRFC/MRFP, even if special packages can be provided. For my opinion, SIP is the correct answer for transport layer (since it's used everywhere in 3GPP and 3GPP2), and SPEECHSC could (should?) be used for resource control. Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing Protocols", I would like to add some remarks: In case of you would like to insert a routing mechanism (a SIP soft-switch) between Media Processing Entity / Application server and Resource server (ASR, SI/SV, TTS, Announcement server), I could be interesting to have a single transport protocol, like SIP, instead of several incompatible protocols (RTSP for example) for the closes functionalities. I think it is easier to add some redundancy, rather than conserving "old" protocols like RTSP. It seems to be very important to make distinctions between each layers of model. Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC, could be an answer. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: vendredi 13 décembre 2002 03:13 To: Jean Philippe Longeray Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] SPEECHSC vs 3GPP The Mp interface is (1) not the right concept and (2) is itself (IMHO) not the correct choice for 3GPP's needs, either. With respect to (1), Mp is trying to be an analog to the MGC/MG decomposition for a media server, where the MRFC is a "media server controller" and the MRFP is a "media server [processor]". The types of resources are bearer packet processors (e.g., tone detection, prompt playing, and recording). The protocol is a low-level device control protocol (e.g., allocate a resource, allocate a RTP port, connect the port to the resource, wait for a signal, etc.). speechsc is a higher-level protocol, concerned with things like 'establish session' and 'recognize speech'. In fact, early in the days of MRCP/speechsc, people wanted to extend the speechsc scope to do device control. The answer has consistently been to use H.248 for device control. With respect to (2), AFAIK, no one has ever built a MRFC. I believe this is because unlike a media gateway, where there are definite decomposition benefits, there are really few if any benefits to decomposing the MRF. In fact, there are clear benefits to using the native application interface (SIP), rather than the native gateway interface (H.248) for interfacing the AS and CSCF to the MRF. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 10, 2002 5:53 AM To: IETF SPEECHSC (E-mail) Subject: [Speechsc] SPEECHSC vs 3GPP Hi, Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229 Rel5) architecture. It looks like SPEECHSC is very closed from Mp interface (H.248). Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Dec 16 14:55:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15757 for ; Mon, 16 Dec 2002 14:55:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBGJvd410616 for speechsc-archive@odin.ietf.org; Mon, 16 Dec 2002 14:57:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGJvcv10613 for ; Mon, 16 Dec 2002 14:57:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15749 for ; Mon, 16 Dec 2002 14:54:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGJsIv10500; Mon, 16 Dec 2002 14:54:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGJkpv10252 for ; Mon, 16 Dec 2002 14:46:51 -0500 Received: from mail2.intervoice-brite.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15402 for ; Mon, 16 Dec 2002 14:43:46 -0500 (EST) Received: from 172.16.16.64 (gwsmtpsrv.intervoice.com [172.16.16.64]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with SMTP id OAA02953 for ; Mon, 16 Dec 2002 14:00:28 -0600 Received: from INTERVOICE-Message_Server by 172.16.16.64 with Novell_GroupWise; Mon, 16 Dec 2002 13:46:45 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 16 Dec 2002 13:46:33 -0600 From: "Skip Cave" To: Cc: , Subject: RE: [Speechsc] SPEECHSC vs 3GPP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_336FFDB5.0263304F" Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_336FFDB5.0263304F Content-Type: multipart/alternative; boundary="=_336FFDB5.3D5C0F70" --=_336FFDB5.3D5C0F70 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Eric, Jean, It's good that we agree. I believe that there has been some confusion in = the past that SpeechSC is a media streaming protocol. We need to list the = basic issues to make sure that we clear up that misconception:=20 1) SpeechSC is NOT a media streaming protocol. 2) The SpeechSC protocol is strictly a command/response protocol, carrying = commands and returning responses from application servers to speech = servers. The SpeechSC protocol will never be a media transport protocol, = and will never carry any type of media.=20 3) Even though the SpeechSC protocol is not a media transport protocol, = the SpeechSC protocol can be used to COMMAND speech servers to set up = streaming with another server using some type of streaming protocol (like = SIP). Which streaming protocol is used will be determined as part of the = SpeechSC's work. For example, in my attached architecture diagram, the SpeechSC protocol = allows an Application Server commanding an ASR server to set up a SIP = session between the ASR server and a telephony platform (see attached = figure). Note that there is a SpeechSC command/control session between the = Application Server and the ASR Server, but there is no streaming media = going betweeen the Application & ASR Servers. There IS a standard SIP = session between the Speech server and the Telephony platform, that was set = up by commands given in the SpeechSC protocol. This SIP session does NOT = carry any commands other than standard SIP setup/teardown commands.=20 An example of the command/response sequence in a SpeechSC Command stream = would be: Request from Application server to Directory Services for an ASR server Reply from Directory Services To Application Server giving info on = specific ASR Server Command from Application Server to ASR Server to set up a specific = command/ response session for a call (one command session per call = context) Response from ASR Server to Application Server acknowledging the completion= of the session set-up. Command from Application Server to selected ASR server to set up SIP = session with a specific Telephony Server. The App Server gives the ASR = server the addresses of the Telephony Server so the App Server can set up = the SIP session.=20 (ASR Server sets up SIP Session to Telephony Server)) Response from ASR Server indicating successful SIP session setup. Command from Application Server to ASR Server to set up grammars and start = recognition on ASR Server. Response from ASR Server to Application Server reporting a grammar match = or timeout from ASR Server. etc.=20 Again, this is shown in mu attached diagram. Skip Cave=20 Sr. Principal Engineer Intervoice Inc. >>> "Eric Burger" 12/16/02 08:29AM >>> From a personal perspective, the MRCP over SIP proposal was what pushed me = over the edge to fix MRCP. I would be hard pressed to try to convince the = IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, ... We need = to pick the one that makes the most sense. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net]= Sent: Monday, December 16, 2002 3:12 AM To: Skip Cave; Eric Burger Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Hi Skip, Nice to have some news from Intervoice... I agree. SIP will never provide multimedia control functionnalities, but = I'm sure it's a great protocol from transport (and mandatory for 3G). WG has to define a couple of protocols, like MRCP/RTSP. What do you think = of SPEECHSC/SIP, which can be very closed from MRCP/SIP. Regards. Jean-Philippe LONGERAY=20 R&D Director - Service NODE NetCentrex=20 Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: vendredi 13 d=E9cembre 2002 19:38 To: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Jean, Eric, I don't think SIP will support the separated media/control requirements I = posted earlier. You will need a control protocol, and a separate media = protocol. I expect that it will take a new protocol to meet these = requirements. Skip Cave Sr. Principal Engineer Intervoice Inc.=20 >>> "Jean Philippe Longeray" = 12/13/02 01:25AM >>> Thanks Eric for this analyze, I agree. H.248 doesn't seems to be the right answer for MRFC/MRFP, even if special packages can be provided. For my opinion, SIP is the correct answer for transport layer (since it's used everywhere in 3GPP and 3GPP2), and SPEECHSC could (should?) be used = for resource control. Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing Protocols", I would like to add some remarks: In case of you would like to insert a routing mechanism (a SIP soft-switch)= between Media Processing Entity / Application server and Resource server (ASR, SI/SV, TTS, Announcement server), I could be interesting to have a single transport protocol, like SIP, instead of several incompatible protocols (RTSP for example) for the closes functionalities. I think it is easier to add some redundancy, rather than conserving "old" protocols like RTSP. It seems to be very important to make distinctions between each layers of model. Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC, could be an answer. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: vendredi 13 d=E9cembre 2002 03:13 To: Jean Philippe Longeray Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] SPEECHSC vs 3GPP The Mp interface is (1) not the right concept and (2) is itself (IMHO) not the correct choice for 3GPP's needs, either. With respect to (1), Mp is trying to be an analog to the MGC/MG decomposition for a media server, where the MRFC is a "media server controller" and the MRFP is a "media server [processor]". The types of resources are bearer packet processors (e.g., tone detection, prompt playing, and recording). The protocol is a low-level device control protocol (e.g., allocate a resource, allocate a RTP port, connect the port to the resource, wait for a signal, etc.). speechsc is a higher-level protocol, concerned with things like 'establish session' and 'recognize speech'. In fact, early in the days of MRCP/speechsc, people wanted to extend the speechsc scope to do device control. The answer has consistently been to use H.248 for device control. With respect to (2), AFAIK, no one has ever built a MRFC. I believe this = is because unlike a media gateway, where there are definite decomposition benefits, there are really few if any benefits to decomposing the MRF. In fact, there are clear benefits to using the native application interface (SIP), rather than the native gateway interface (H.248) for interfacing = the AS and CSCF to the MRF. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net]= Sent: Tuesday, December 10, 2002 5:53 AM To: IETF SPEECHSC (E-mail) Subject: [Speechsc] SPEECHSC vs 3GPP Hi, Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229 Rel5) architecture. It looks like SPEECHSC is very closed from Mp interface (H.248). Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --=_336FFDB5.3D5C0F70 Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: quoted-printable
Eric, Jean,
 
It's good that we agree. I believe that there has been some confusion = in=20 the past that SpeechSC is a media streaming protocol. We need to list the = basic=20 issues to make sure that we clear up that misconception:
 
1) SpeechSC is NOT a media streaming protocol.
2) The SpeechSC protocol is strictly a command/response protocol, = carrying=20 commands and returning responses from application servers to speech = servers. The=20 SpeechSC protocol will never be a media transport protocol, and will never = carry=20 any type of media.
3) Even though the SpeechSC protocol is not a media transport = protocol, the=20 SpeechSC protocol can be used to COMMAND speech servers to set up = streaming with=20 another server using some type of streaming protocol (like SIP). Which= =20 streaming protocol is used will be determined as part of the SpeechSC's=20 work.
 
For example, in my attached architecture diagram, the SpeechSC = protocol=20 allows an Application Server commanding an ASR server to set up a SIP = session=20 between the ASR server and a telephony platform (see attached figure). = ;Note=20 that there is a SpeechSC command/control session between the Application = Server=20 and the ASR Server, but there is no streaming media going betweeen the=20 Application & ASR Servers. There IS a standard SIP session = between=20 the Speech server and the Telephony platform, that was set up by commands = given=20 in the SpeechSC protocol. This SIP session does NOT carry any commands = other=20 than standard SIP setup/teardown commands.
 
An example of the command/response sequence in a SpeechSC = Command=20 stream would be:
 
Request from Application server to Directory Services for an ASR=20 server
Reply from Directory Services To Application Server giving info on = specific=20 ASR Server
Command from Application Server to ASR Server to set up a specific = command/=20 response session for a call (one command session per call context)
Response from ASR Server to Application Server acknowledging the = completion=20 of the session set-up.
Command from Application Server to selected ASR server = to set=20 up SIP session with a specific Telephony Server. The App Server gives the = ASR=20 server the addresses of the Telephony Server so the App Server can set up = the=20 SIP session.
(ASR Server sets up SIP Session to Telephony Server))
Response from ASR Server indicating successful SIP session setup.
Command from Application Server to ASR Server to set up grammars and = start=20 recognition on ASR Server.
Response from ASR Server to Application Server reporting a grammar = match or=20 timeout from ASR Server.
etc.
 
Again, this is shown in mu attached diagram.
 
Skip Cave
Sr. Principal Engineer
Intervoice Inc.


>>> "Eric Burger" <eburger@snowshore.com> = 12/16/02=20 08:29AM >>>
From a personal perspective, the MRCP over SIP = proposal=20 was what pushed me over the edge to fix MRCP.  I would be hard = pressed to=20 try to convince the IESG that there is a need for MRCP/RTSP, MRCP/SIP, = MRCP/foo,=20 ...  We need to pick the one that makes the most=20 sense.

-----Original Message-----
From: Jean Philippe Longeray = [mailto:jean-philippe= .longeray@netcentrex.net]
Sent:=20 Monday, December 16, 2002 3:12 AM
To: Skip Cave; Eric Burger
Cc:=20 speechsc@ietf.org
Subject: RE: [Speechsc] SPEECHSC vs 3GPP


Hi= =20 Skip,

Nice to have some news from Intervoice...

I agree. = SIP =20 will never provide  multimedia control functionnalities, but I'm sure = it's=20 a great protocol from transport (and mandatory for 3G).
WG has to = define a=20 couple of protocols, like MRCP/RTSP. What do you think of SPEECHSC/SIP, = which=20 can be very closed from MRCP/SIP.

Regards.


Jean-Philippe= =20 LONGERAY
R&D Director - Service NODE

NetCentrex=20

Jean-philippe.longeray@netcentrex.net
+ 33 4 72 53 61 33 - + 33 = 4 72=20 53 61 30
Mobile: + 33 6 76 48 34 95
http://www.netcentrex.net

---= --Original=20 Message-----
From: Skip Cave [mailto:skip.cave@intervoice.com]<= /A>
Sent:=20 vendredi 13 d=E9cembre 2002 19:38
To: jean-philippe.longeray@netcentrex.= net;=20 eburger@snowshore.com
Cc: speechsc@ietf.org
Subject: RE: [Speechsc]= =20 SPEECHSC vs 3GPP


Jean, Eric,

I don't think SIP will = support=20 the separated media/control requirements I posted earlier. You will need = a=20 control protocol, and a separate media protocol. I expect that it will = take a=20 new protocol to meet these requirements.

Skip Cave
Sr. = Principal=20 Engineer
Intervoice Inc.


>>> "Jean Philippe = Longeray"=20 <jean-philippe.longeray@netcentrex.net> 12/13/02 01:25AM=20 >>>
Thanks Eric for this analyze,

I agree. H.248 = doesn't=20 seems to be the right answer for MRFC/MRFP, even if
special packages = can be=20 provided.

For my opinion, SIP is the correct answer for transport = layer=20 (since it's
used everywhere in 3GPP and 3GPP2), and SPEECHSC could = (should?)=20 be used for
resource control.

Concerning SPEECHSC, 3.3 "Avoid=20 Duplicating Existing Protocols", I would
like to add some remarks:
In=20 case of you would like to insert a routing mechanism (a SIP=20 soft-switch)
between Media Processing Entity / Application server = and=20 Resource server
(ASR, SI/SV, TTS, Announcement server), I could be=20 interesting to have a
single transport protocol, like SIP, instead of = several=20 incompatible
protocols (RTSP for example) for the closes functionalities= . I=20 think it is
easier to add some redundancy, rather than conserving = "old"=20 protocols like
RTSP.

It seems to be very important to make=20 distinctions between each layers of
model.
Something like UDP/SIP/SPE= ECHSC=20 or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC,
could be an=20 answer.



Regards.


Jean-Philippe LONGERAY
R&= D=20 Director - Service=20 NODE

NetCentrex

Jean-philippe.longeray@netcentrex.net
<= mailto:Jean-philippe.= longeray@netcentrex.net>
+=20 33 4 72 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 = 95
http://www.netcentrex.net


-----Original=20 Message-----
From: Eric Burger [mailto:eburger@snowshore.com]Sent:=20 vendredi 13 d=E9cembre 2002 03:13
To: Jean Philippe Longeray
Cc: = IETF=20 SPEECHSC (E-mail)
Subject: RE: [Speechsc] SPEECHSC vs 3GPP


Th= e Mp=20 interface is (1) not the right concept and (2) is itself (IMHO) not
the= =20 correct choice for 3GPP's needs, either.

With respect to (1), Mp = is=20 trying to be an analog to the MGC/MG
decomposition for a media server, = where=20 the MRFC is a "media server
controller" and the MRFP is a "media = server=20 [processor]".  The types of
resources are bearer packet processors= =20 (e.g., tone detection, prompt
playing, and recording).  The = protocol is=20 a low-level device control
protocol (e.g., allocate a resource, = allocate a=20 RTP port, connect the port
to the resource, wait for a signal, = etc.). =20 speechsc is a higher-level
protocol, concerned with things like = 'establish=20 session' and 'recognize
speech'.

In fact, early in the days = of=20 MRCP/speechsc, people wanted to extend the
speechsc scope to do = device=20 control.  The answer has consistently been to
use H.248 for = device=20 control.

With respect to (2), AFAIK, no one has ever built a = MRFC. =20 I believe this is
because unlike a media gateway, where there are = definite=20 decomposition
benefits, there are really few if any benefits to = decomposing=20 the MRF.  In
fact, there are clear benefits to using the native=20 application interface
(SIP), rather than the native gateway interface = (H.248)=20 for interfacing the
AS and CSCF to the MRF.

-----Original=20 Message-----
From: Jean Philippe Longeray [mailto:jean-philippe= .longeray@netcentrex.net]
Sent:=20 Tuesday, December 10, 2002 5:53 AM
To: IETF SPEECHSC (E-mail)
Subject= :=20 [Speechsc] SPEECHSC vs 3GPP


Hi,

Do you ever compare = SPEECHSC=20 and MRFC/MRFP interface in 3GPP (TS 24.229
Rel5) architecture.

It= =20 looks like  SPEECHSC  is very closed from Mp interface=20 (H.248).

Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2=20 (www.3gpp2.org) ,
3G.IP (www.3gip.org),  MWIF=20 (www.mwif.org)?

Regards.

Jean-Philippe LONGERAY
R&D=20= Director - Service=20 NODE

NetCentrex

Jean-philippe.longeray@netcentrex.net
+ = 33 4 72=20 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 95
http://www.netcentrex.net

___= ____________________________________________
Speechsc=20 mailing list
Speechsc@ietf.org
https://www1.ietf.= org/mailman/listinfo/speechsc
______________________________________= _________
Speechsc=20 mailing list
Speechsc@ietf.org
https://www1.ietf.= org/mailman/listinfo/speechsc
--=_336FFDB5.3D5C0F70-- --=_336FFDB5.0263304F Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="SpeechSC Architecture1.GIF" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODdhvwPPAvcAAAAAAADMmf///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAC/A88C QAj/AAUIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMN+ BUBWIACVZM8yTMu2rNi3cOPKnUu3LtO0BN2aVau3YN+BfwGr3ZvQLV6/g/OyVYxYQF+9fwMTtku5 suXLmDMTlay5c8+2oEOLHk26tOnTqFOrXs26tevVnmPLnk27dkkAAXLr3s27t+/fwIMLH068uPHj yJMrX847se3n0KNLh46bufXr2LNr3849ufPp4MPXTHzMGeL3iOUdOz8svmv17vDjy59PH/v59vjz k0w/WXB/9f8FFhlf9/3HWIAE+gegggdClhh5+nn0nnZpwUcWdxfWF0CGuXGo4YcFRij84ojUgUbi Z9lNqJuHG06YoYcwuvgeix3OaGNzN+72ooy/qdhijT36+KOKNP44X4gnJqnkkkyCJOSHUEYp5ZTE IdnklVhmqaVBT1Lp5ZdgHrnlmFjy91hh56UnYGN5AcamWW4eCGebcca5npVkHtRlmHz26edxeOYp 6HSSDTbgd4UuxNl6c/rlaJqO9gdhgJEO2tBrmGaq6aacdurpa5aGKuqopEI1WqmopqrqqmQGyuqr sMYqa2yu6pnmrYreN+CsvPbq668cnWoerlwiuWitwCar7LLMNuvss9B2tOef1FZr7bXYZutdtNx2 y6W218bYXZHgpjhtuehuh6y3/+zKem66K+pIJI9ArkhvvUYCVyG++LJ4obhBNtfbvvKCli+O8tqL ML9D3quvv6ExnK+NBh8Mr3Drtqvxqu9ePBy5Fnss8sgkx5fxxiiT2nHJLLfs8sv1nZzyzIOuHJy/ CxNMsJEc7ugbWz22SKTFIA/sc43/VrdjjvwqrXC9S+NWtL3nKi3k1E/ffLTQUluNdNYHO92v11yH /DPZPDMtn8w0t72lzR93CXTBMvo4N9d1J60z1RWW9jDENN4tsI4C71w20nUHfTjiOPZNWuOGGw24 3ZF3OHi8ht8teOV8Ny65xNex7fboTcIN8+mop676z6S3nuqnsMcu++y012777ZK4596p67ynLJpW v9sW/HNt2YRosRAeZljxBi4mGHvML6jYnXuJ3vv16IllPWXbZ9Y9Rsc6Lz2D448f/fKG8oUgg5Ni 776Tb33PpYHV00l++Z+NZ+ytD+4k//sAPNH/kPK/QpEnfW+qn1AGWBEz8e9++TMesSzCn1wF8IIm YeBRNEgXDtbGgw5JFPkQyL4HIap/9P/DoAo1AsKiyMyA4GNbBVniQRheZIZo+kkLV+it8oivedA7 C3smM8TnNQh96BvJDjfTQEiNcIQkpN+ZUjgTDYqQUuvLopwcA0GgLDGHGcEhD0uEEBNB0XnKM+EW HaTFLkqLe0z6onjk6EAoEkaMY8wjReTIxJDgUSF/1GFKAllGPkZQjwG0IQVlyEdD9tFJ+7MjgAjJ ky/WMYtloaRVHAlG+CHSe07EovmiiL8p4k8knBxKKueySun4cFcKCt7vjrVFI7qxkJ98XysXqCea aPJS4ymjL2uoFFf9Mpi5FF73julJ71FRPdSLZWiqVzxadnGIeGRmGJ9ZxEnJcprWTCFWNmulTVUm E2WXHOUdd9kozTAqhOxkofHqtJZ4bjMu9jznGPMZFH7KxZ+t+qE+8QPQSnpGWFoa3vUKOlCjCOid z8SlrewHSDXVcnkJLMwHS8VQHa4uWx3/bSgF7aKrfn4UpCgx3Uk1ZD2VKqdinYvbyEIq0gjRVE8r DVdKc1qtlnqpZwvLWs+u5tK11TQpFfyjRc0HxD2qUZ30fNRN88LTnu60qn7yKVb7NNWjYmWH6lvg VrN61bGCSatm/VJXvUqdDaY1THQsjsOklrB4hU1uDvMYWqs0NLAl7Wx1FaqLxga2sNUVYC9la7TW WhjkqI1uZ2uLXCMnrsANtmlds09ZATWtIlFOcYH17JP+FdigWmevb5USYxVLq2KmVq2bfS2UUCtb lrKWWasFZG2nFNfdzhZ8UdoZ5YYqNLx9jXEK45xRb5us3OrWt789SVGhCyjgzpa4dNuaOtEkp7Pp npa5v3KuoqgLotiS10LWPe9ywTsr8Y5XvWKSru7mS1/TxLC++M1vOdkbR6no97/4xYx7vaL/UP7u U1AFriWbuvnUS21vv/6L1YAN/LZRhSiaFIWmnGaIYS22T3qw5GUTLVisSgHylOiZsK4UeUNSNpDC AlRZcxdJ4oz6cKJrTJAkRenLenIxo+JssKRWPOQ37erDMGYlqiasZFgxOclJevJViJVOxESvoh0+ 1JUV+GEIS/chXY4iG2+ZxAwDDy0uhrKopDzlGcPzlijG4Z1IGeISLyjMVQTm/drHZxdbs8rTE+gc C/RDLTNmnAq08oINPUdWsTl+EjZw+IIYaAfpGKpF9vCWaYNQGcuXxZgGsnsireaFkjq8Mili+aYp zKkMUNBI9iYJ8eyuR5cRvie19YmBpeuvUZbax0amc/r6h8JB4vqjvW71rqX5wFw9NJpBTKOGbalg Eb8q2b9Gz7FXB2D6AruNY7YVojOdaSGecMcunEidTRnnYje4zwoWspc3skRs2hjaQtseXbdVs23V YRtaLyxTBsPd1Bpne4/9Tt2/Y5JUckLayQcHi3cTblVXvnvWF7fzVjr96VGmMdpXfAqepnrMeZdp 36gJ2Hafhl2o0QuxGwrtyy+rcswKtrA4Y/ln/So3aKL850APOspdgkQiYpSLZTbzXQyO6TpfE98b zneITZ5IKmHNZLVdeMTxuXUCU/x0Wu+69lbCYTAvVOij+TrMwi52id9G3jqG5UPbfim1vwzteM+7 3vfO976DaoN017bdW8b2wBv+WRMfPFwPz/jGi9vvkA+64ydP+cpb/vJOmM+85jfP+c57/vOgD73o R0/60pv+9KhPvepXz/rWu/71sI+97GdP+9rb/va4z73ud8/7ZdnbP6qGNYNlfeEOU3N6P0Z+oikN cuQVvvfQ2re4sC/t8wOCHO6dTHT1L51xEEvbylqmevTHT35nJV7x/i6/+ueIfvU+f/3w30/7z/v+ +O9n5ATK/9EtbW5mw/nP4TZmizGA/Wd0H0d9HDV/5FV/9jdwquZzgXZ8GiZoEPg8/MNqEVg/B0iA hzKBByiBS6YuhWVzd1VaLRdzE/NYMCJzpcVdpqVdTcNzZqMuDViDsnF+k1VzCvhTNtiD7rSD0MWA PghHIYRBOAiELCOEQwhJJjZJr+RUijI/ytZOTSh3xpd87oKEu6WES9iF7bFpXhiG5DeAoiaG8WbY ey90PrBhXxx3hm7oVZGhfd9WbYAGZ294h4oFhni4h1VxhFr4h4DYHHwIh4FYiIaoWYNYU37IVTN4 Wkd4dfaxiMwBiY54OQrIhYlIUGAHWH5lgi9IMXbVchDjiSWog3aFgnc1WHtDgkQzV6xoWil4WaKF isUVipK4eJnYULd4iLw4eJiYi+HhXZVDiZG4c8f1OS2oNchmNXj1MM5IWCvnW7vYIcA4UDhIWrAo ikT1MaCTIyq4Mog1iiwYc9jIN2gDixjjOYSTjJCINeE4L0H1IkMCOeeYjMoYjeg4LtWoT9PYi/7Y b7+4j9HRj/9YkO7/J5COR4Gb9ICzoZANiYEtYUYWqG4Q5ZBQiJDKRCcMKXKGAYK00pHV1hnsBhOQ UYZzt2dpBnx+tpJthJEPFxYgtD9htX0bqRPsxIaloXwAFZAuKXAvGSwQKW6LJl75VIfI4xM8SZE9 6U7/NCJJyXBVZCVWGHUXBXVLeRlPSYVLIX4j5R4hlZWDaF/OtkhMBpZa+WZMd3TktmpWeRNWJJVt 6X1VuWjWdpVUAWpUqXFyWUKNQWstZJZnaVPXRkPFp39xZyh2qUR0VJPBQoRLApj9pJgIxYGG+YGJ uRmGBJlRJS2FSU2HuZmAJ19Y5plGB5oEdplbCZd0yZcouZpfZhlvMjmZeIFGrGaRdQlJsplJG2iZ Eid1ZEdoEHVKToeaSOVMFdZexkdww6aRZwI9OzZ1oRSS/8RpTsYZalgomhJFT6DGlWaHbtc5cNmH hdv5fJq5fmqCRJ8ZmGhxUAXHmo3ye/bmnJoWbL2kl0THlvRZJ/DZnCU5n3nZhBHVh9OJEzl5fLRp RrapRK1VM7xzhQPakKAEktP2mO/EmNzShok5nKKGlwG6ZxnWn9oJoBr1kRYaRwnKPQa5IWh4blIo nNlZhvYZh8z5nCNnUinaWwVJW7xYnva3WgS5gOa1o+kVXAMTWfi4OMiFi7s3Qd9pnc/WbHaolFJq owaJo/+oo9dVczAnWeb4ozfDe4viRhgWcuN2TXOYY3rGnRKSoioqXTc6pP7Io2PoVm/qplUKp/do iaHjh1TEGF8PGmF06liziHPw+IygUy5WahxTAzKC8zfG2DCcaDml2Kc9gqcy9agjWIo3F40nmIII A3OO9ac26VpyFam0+IqLyqnbuF2Fmo+haqc5aqmHKKf/YLqVbJqovYilRyKPW0WrufdoXhqEQTqr sspSoNqNM5KpjRgzoopMd3Grw2qIulqIvmp7uhas0hit1Fqs29qsJBkV2LqFAuZkJeqtvoZg5cpR qqI8HmmuZxZQYQVrVLSRSDaiJ4lJlnZEROmV0pkT1bqU/0p2jwd+iFmBnmlCjGaBw1aARsR/GZhu I1ZRY7kW8fZUtIafzopjUYVRBKh9B3RE5Pax/sc8atqj6sprpyaxhVR0EYig4zRnE8qbBnugAZuH S6ax80pkdBicJVtMKeuuWVGz96mXDBlOaSlsimYnGIemt6my3KSzYhpOHXtnYmZultmzekaxzKRN GtpuKzD6kKQxsU4ltKnGMW7mbC+7sNaXVO3qgU+qaLUps0M7ogkEb+7JVC9atFD/65RM+p91S30E R7UgCx7sSm2hUm9Sl5wz2aGb9LOah7X6oYdrlkFE66AiOhZEF5wYK039SkBAybS6qGJsyieFR7b+ mrl/+7VB25j52Z75ebHkWmN9ZiKQi1Oje1bnmrXgWrsfYbrf6pLhers6chdFe7R+K5x9q5Z76brL C7HqhpSiw7tF2HHJR7sJdqKGF7zCS42pma5TeLhT6p9Ph7OCe7dOF7h5hmaKq7uYp73b67tXAr9z i5DuK7zya2IBCLhpJr0kCaLeC5Tyo3X3m0vJ2okYI4z1yzCdaoqUSoMrO8D0BpPYy5lzqbzrZJ9L 57TgFpKm1H1ruSbeCV6jtaqqM6qD2tWpJ5w4B5yn2viJn/qox7oiDwzBiSSgFHuHCTy6NFx+O5xH OQytQOu5b7d8S3u3jEjbdj9cp0Fsk8XrgB43bdE2oSjWeEl8p0vMxP+biVUcq1fcxQy3vTzoxWI8 xmRcxmZ8xmicxmq8xmzcxm78xnAcx3I8x3Rcx3ZHfMd4nMd6vMd83Md+/MeAHMiCPMiEXMiGfMiI nMiKvMiM3MiO/Db5Bp5oGaWPXMlRea/lW5oqaT/1qrCYnEkUZbEeLEqdbMnJgMyiUGW0USudsRZJ TWW3q2zKsty5s1zLlrzFYIyItmyGuJzL37XLvOzLawfMwSzMLtPDxEwzvWzM25LMxfRgyPxVzEx4 zgxmfSsRJVd85PtJyzzNilrNDnamyjvOqKzJL3q8XDbKSRtq/MtpFmIhMVyJJsOrYAfO4dyieJvK kZzP5xmjVfu0rQu7CSiCZqM3CUNZebU5mrPQyKhzeEVzSdowFSNc3VWLGGLP41qfykwhEePCmqqp jJpZCvyNr/g3ympZp1jQ0xjNtRjdQ5FopFQzNvW4pQxt0bz6jjII06lY0abapYdKIS3dg9hKLg1s zCwd1IvlzSVz1EiNeEpNMkzd1M3SzU+NMVLNdM2bs8rnfI93RRKpn5tWsJxcaVEtf1WtV1etwdcp ods8yeEJnEq3lpkcZO111mid1uescQ9ISUsV12tNt625uerJMXZ9MWU9hjkpkV9NmliWtmjkfGRI sMEXPmTdzr9m2Xid2YMkuZrd2Q6FoZ4d2l50uaKVXdoOZdqoXZw0ZmfyJp7uZrmpjdeai7ZBGaBG i9mxzcdhOyxtbZRTnNudvdjAPdwEetjEfW2FndyvZdzJTNXK/dzrddx14dzQXd0OLN3Tbd3anWvY TVLcJolFrS8ggqlEaqzHeIndnd0KN9JbMzfiaNFpA42peFh6A4Mt6Ir0rXM5Pd8ObVyNqFxHAzR/ tY7xXTbhXXH/6f1PqNOqrEjT47hyKEzS8bysIzio+BjhhPrRBH6MRL2qj6WsSZjgrHR3mePeXQOP JR41BeM53cWMeRNTjYo3EdPiL77ikMPfCj1UKl6kSBpTPY6sOk7dzSzicCHkGDKMyrXdxErkRa7k Tl7PTB4/WWXkOXirVD7MUa49L83jqgXRlhM4raioV85Zeoo5I1zleZp1/cjcxHx+QHXfTCNaMOWq zGiLrmqqGP7g+/LhovHTBzxa7Ngx7ngv7y3fe17hHU2Mfd7hzJrlMKkudHXhMlfAwqWnOXfehY6s G47SKW3TK2iLsmgzhU7CEsPpaZ5XhmXj8B3qoc5ZqvjmFK7LIo7udU/+zjosMmwOzGNe67wuiLM+ Fr0e7Hf96+4h7MaOLrndTuS4/RLL3hTN7uxZTOwkGu1IxdnuJNxgu9uEqdExRMHS7skT/MwJJpLa zmmFm2o8K8qV27o/lr9167fP7sewncEbK7Qj2Vb4zOxChMFSlLjjK9eBS86pHZAszebJHts8WUO3 vb6j/buU0trW2WPfzp4/ybpTTIG1jZT6g9UTqfETD5tc90Yxuu6U7JbDxPHlDKj+irD3dJHp/ZRl ffDc3r/3vIEhO5uHmZLDnZWHLfPfu+3G23T+PrjYDZbG7fPLlrl7nbYgiPNv2/HSbfQtttVd6fIZ y4SG+2IRq/L/H9+4TYbN+JfO3+d9ummAJS+wvRv2UEybJVT2VKvzp4vREM/xvC3EX59i4qy/3jmV ce/tai3wLcn3TVvc94yaLObum2y+xTbXyqmg031fBmR9Ta+bT9+2Eo+bkY+w+tewky35pw303U6c HCrX4pvVbg9EYEVS/TWYmy276o70ksZJqa/6q++4WP+fsnb2wF2ercRh1+qWaj92XX9ItH/7Uy9y rR9GZgn7qCeyN7TaKQXyfuTK+tykdj/ETpv7gMn8oef7Yq+WDrt/6Ov4laHweo20WX39inn+kjT+ mCv2v6myk0313D/Vqkn0zXu+CEj+5Z9QACFA4ECCBQ0eRJhQmOFChg0dPoQYUaIAAAAMVrR4EaPA igQ7UszIMeNHkCIHYhwZEqTKkywXkpwYU+ZMmjVt3sSZU+dOnihdrlSJUiTJjUILGh36sydPpk0h KnUaVWpUqFOtXsWKECbFo0SDptT6c2tLjyFZbiz5cGxWtm3dvoUbV+5ch1Xp3uWKV29bu3v93oWZ kmhJtGXHIh1qWPDIpGELd/0b/1nyZMqVLTPse9nq2bKJ2a4lu1KjYY+AL3YW/bnqx8cmWwbVrLAv 4tgna9/GnVv308yg42bevRNsV7FoAw937dU10OWpIasFTrW5Z+LI0x5fztqs8a/FeQeXGB38ePLl zdP0HTH9W/HnY1rP+zp0cqVrQWPnSHz6y/ZNLW49S7nQ7vPuIPzi82y959xrqD8GH4QwwtjWE5A+ BOVyUELM5suLto5aY646/V5bLL8QNQJxP7j+g+1Ek0CkzUXnQjSqRANjVFHD03TksUcf/TpsOw61 49CtDH/c8SjMUpwwshZlY1KzIzUUC0krr8Qyy5e0lGlKLqXy8ssHbRSzTDPP3NItTB1dYhPNFVFz M0Kf5owyTjvvxHOzPBWjc08w6azTT/d8ErRQQ+uCs8jjkKsQwPoEqw5A25Q0EdFD+zyUqjkzPSkA Tz8FNVRRRyW1VFNPRTVVVVdVVU1OX80qSEpzTIjA0mpV0ELUHG0Q1kBhxSnXOwFgtVhjj0U2WWUD cBVYZ52SFVf1HrVUviSnIzLRWqVctltvvwXX1GYbDLdcc89lNUxi0WW33XbHfTZenbwCNEgmNyVR QTKT8pDAAKvk1l2BB/4W3pcIRjjhYtVVuGGHSTX/WF6JgxU0Yqoexjhji7XKuGOFGU64olHX9Zjd jSdGOeVbJyy5ZYFPvshlmc8FOWSSPb2ZWVBF/pRnZm9e1+efNVa5aCNrRJE1oLhj2jeh8P3tQsty nrnqZWE+ymqtr66JaoJFplrooXEmWWyyZcbaaLWdppVNxgxMqzReuyyMUBJlk5oyr7fmO9W0O+07 8Fa7FrzwU/9WW2V928MxPqWxzdDWIrWi9a+9DccccYow5zzUmjvnXPPEU37M7Sf3a+2rBSGfPF8h O0RqsEovuxz0vjWv3XatP9ddcNFHB77JzX4PtvfQscrdeLQJP9wnzzE6VuyyoQ/X7JeDxz77SXNL /155l3FvtV6wxQea59yp795q3g8XNWzqh37ffOfP3vn9n+NHqWf3yyc7fYi1B+DoiDcvZNUOffqj U/iC1jnwGct69RuZ0C5nv/1N7373k9/0JEgs+y2MeavyWc6sN0L+QZB+ERxbCk8oPQ6WMHoBhGHR BpgT//XshAjc2fN0WCoKtg9/GMzfBRFowQ6CEHnRO1/yigixDaLQhza8oQm5hh4kMjGIJJTiDec3 th/qTIUhDJoLHRhDMkpshjRMVwJ5yML+LayJT9yhF6M4xzFepYb6a14ELWhFPNbvihOsIBi9tT7v qa+MhwTWGdHoN6/hb499xCEfozgnOqpwiPLrVggDC8k3Qm5yed6IBKWhFLlIT25Nk6WsWidR6bFR htKVtCPPHVeJsFPOsmWqNNcbbbmzV/bSTq0s3i4/uRlhfu+DXytiE7EIxTc+8Hq+hGaZgBnMYpas ltV8GC7L5T5IZhGCYvQmLaM5Ti1Nk5rYJJod0dkxba7TXeYkZzyRdx5ZurN6R7Snw9qZT5rJ0588 gudN6snPTOKToOKk4kER+k+GMiigAlVoyAwa0Xcek6Ima2hGzfNQiF70mXniqJ9CqlGSBmekCfXo u0SqUaiV1KWvOmmWYnqphorvpTcVpS9b6lDVDeqfnNH/Fk6FiqaZ/simp5Hc9li3IWFBaU0lLepQ pYohVwJ1SEElzXOa2tMhva45FaqcZBjn1Q+R9XW/CmtdorotO5qORfNa61SNFlcrQaVAiuLqjK7V VTgdKG5/patSw2MXf6lHRQfSznZ6itbPSGuvM2mqWuU6WfTEM7B4mhKFAGYtygUVP34F61/pQliz RKoodxVtaFGEV9b6lbIkvaxRpxo5u5mWUo2TUW2Zs6i4IQa3VOWP1Eon2q8GiLOM8mpxb+Xa19ZU nrH9JVSbO926+hO1iDUrVuljVcxKl7rffap1b6Rd4i51teNtTLYaxaKmpRVI3gVvfMf0U/SWt3X2 3Wvdk/KKX/XmNbKmkax2k3pY7v6XntCxiYHrC9jsKle+4qUvn7qj2NLptrMxOq29/rW0xO5ragjG b44wxR/j4nWnqQHtNIEDHwbvKrEutut+BVziB48Tule6sZuiw9sFk3d1vd3vcIHsYPfqaUvawm5f k2tf1c5YgImajZcUjMgcV1eqVcZSjB2l37Lqp8OKwZVvuVzh3/+izD6LTW62dPVVJbvYxyLlLoSH 9zYOcxhGjA0vS2s8lzOH5b6f5ercAE26o1p2zisz75pD3CMs43jPEJpyL09MTuKljsZ4k+ZvIIVk /943lsJ53KNFHaxGI+lv+v3x4sykyCjN7c9yomFg8vUiev1LQFweNctSastSb+jKb8pqojsroY1V mNNOVXOLXRrpgO16lb0+8lDPuK9NTdrT5RkXqgdEXKi9WNlFjmZ6mmYd9V7bP86eJbQxLW345noy muWriMvMlIGi+3aM7lVlmL1ofbfb3UAq9NPae7f84JmA9i4llvUVXCifbsClnU+SJ+ffHEuZ2Pv2 z7+pjPCEb7RhpaRdXWj7PBo3RzzINMY4cMOj1TNH2V4spzBYyEzyvZz65KmmM7g1XnOOe7LXgDKs nL/TcNbS/Njfdq2rU76Uto483kbfua577r1GLz3CgyW6ycMscaQzJlrf1supje5qtv9GnXtTL6S6 42txGKrd7LRDO9XnavW8Zdnfb8deveNuTDN3edZL+/us8C342dkY7wHU+96tObGkv5Xbjn/zmArN lyg/BdbVkrzbLXtJNa5R70tEZueFGL1uftSpcG7MdcrtbUSb2trS0bqiVUv3sPt6QC1f0sth/Pey dgfqh6c3Ez0PziCejYJhbCQbLzg/0FtSkJeEPiX9+E1Mjr75zDKt5nGj/WkNkOvJnr3bQZ711KK2 6Fwv/4JoD3wDCR+O739gM12ofF2aL49r1OHzu8lGs+nSkrx0nfVjvzPRvsp7uiFzjO8LNK9zmwMc QOFwPx8qvg2awOr7ovl7JOdTIgNU2qMuCqM4ssD9AycAPL0HNEHBWrcTvJSGcaZcur5q4j4V1J4Y lMHfULzeocEaBJ5Ka5YcpK7Eu8F00sEhJLzhWZKhI0I+C0Lb8cEkVJypYC4Ue5QGdnRCG1xCBqpC vFu4P2kz2VsyfstCaLlCLAxDLfy48WhCygLCMfyYMjTD13PDTFlDNlyoOHQ3AbRDaaJDw0nDPPTD P5SNPSycPgTEQjTEORTEijLERWREYkvEwCHERpTESaTESrTES8TETNTETeTETvTETwTFUBQ/xVEk xVI0xVNExVRUxVVkxVZ0xVeExViUxVmkxVq0xVvExVzUxV3kxV70xV8ExmAUxmEkxmI0xmNExmRU xmVkOMZmdMZnhMZolMZppMZqtMZrxMZs1MZt5MZu9MZvBMdwFMdxJMdyNMdzRMd0VMd1ZMd2dMd3 hMd4apTHeaTHerTHe8THfNTHfeTHfvTHfwTIgBTIgSTIgmxFPDTIhJQr1kOeHZMxhYTIK4szIwww c4vIi2SpliO3jcwO5Eq2kKPCUAM0jtyt4Rg0jETJYSG7DquRPnm4GCOwajM/v+vIHwvASEyWyZzM L7D6yNZ5Scd6vARcMppEwD/DSZ1Eyh7jSc6CHdioGwdsON+zDYdrEfRzDsVqvaTUyvDqF72Skdxa FA+rM4I7EfZKGhH5shERka1kS2k6yraESxkyuF9ExEc8nrjEy5ixS3t6y7z0xbrcy0H0y8HcnMBc p74kTF0ETMO8t8TEy8VkTFNyzMeMTGxCzMm0RciszFTC/0y41MzNHKbO1MrPBM1bEk22JM3SZKXT 1DekWRF/GbHIG8DUVE0hZM33+r1pQY/VMB07pM3azKbbBLiyo47t4hda2zAfS6qwtDXIGLfdK07r As5nE86a640u9EK4iT0/q6/1IjKlS7OHtLFBHMGr+c2Oq068ULWSy06cq5zlNC7w+0LCCE/ZrKpt gswWJL2BySCfS8+wq4+lOknUKTFxu64GS72iK0qwe67q+b9Mqkv9LBgR8s//VE9Zw86ThLwM5U2b vDWW1Lbbq0+LfKUInaM/6p8PlKLjox/9o0ATQh8UlSQ4yqAWcj4YbaHxySULLVHtvENwGUH5y6L6 S6IMTDUh+ivP5ykf6eu/svEj55FQZblMHh2tNtG4ORQhbuoj/yNS99O/FcpSLdqbLFXR94PRcHpQ IMOl0otcw+SLIzmSoDcFIyc9UiPlUhGMwBaN0wcFGyXNoShNlildU1NMvOJLUSJSJhaq0embPkdK 0SeFVAwamUdVUg1yUz1Cvs8U1EElxfOsJECdTlTZVE4VRU81VEoNVSkl1YT01FTlz1U1yFZ1VUWE 1YGU1VnFqFq1VVyVO10VyFvl1R311YAE1mC9p2GNFfIZS8BLmpzLza+cHRyZMMeg1rV8qWI11oJB VsrzUUkZNuWkQq/0yNvCyu1EQHq51mzVnVGo5UdvjTigfKzIc9exA0pBuzQSHU91BR123Ueg45MS 1M1oKzzBW42jIzsUzChs1VdV3dZkJTyGtM9nRUG7KkLBslcPxSmFXdgCaliH1U4es8mBJa/NKsIA 9dFofVhp29i77FiKxE6mLE4DzL7/uJHYvMmVsVIE8ddj5NeW9dnX7NmfFdo5Q8ihNdpfgsOjVdpn mbyldVqmbcmifdqpXRPZyUqqxdphidescOVaOezar00ksBVbmoKsAvFO7ySysVVbKCzbHgurAQPD tZVbyNpaty0veFPKoJ1biBRP7gxZvG1Wqd3br0WaecMqp/PbkB3cxd3Nna3Iwx0/iWXcyZ0IxyWx Mas1jWROvaVcVjXczgVd8JjL0CXd7Svh3XAkn9RV3dVl3dZ13deF3diV3dml3dq13dvF3dzVXdk9 XV9Z2d+NKM7t3VoB3uLlJ+Ed3vYz3uVFJ+RN3qxh3ugVJud9XsCR3utFJeqt3sLE3u5Nu+0tFI31 3vEdJPCtmGdzwSQN1Agln1vKT/ujQ+2tXvFNXxesnt8cIX2iTf+7Qvl9Xvp10P8bnzBNJuI7Pkf6 0jba0haUniFCVUmNVOurUSMdPS5yph6qVOpj0jnlnxcUTPPdEwAumNK7QDw14S8C09LbUz1F00Pt IPjF0xXu0iHF0RZ+YDE9UaDB4TRd/1cQDuFNAhQ5zUAupWA8SuAjtlESVmEnQtP4w0AQJGD1ZdRP 1VI4HVMR1lYfxqy0Y+IS3uEvXqY6heL8U9/4syHle9MhtdM19uL2gb8rRqEkBdUP1uJforrk0yAx LdMvBqIF7kAw3uML1tIw5TzogyQZDeQOlGMkrsA8dWElxsE6HpbDBCTyLU3/TV4sfplKtuTNxOTh 1eROFuXDkWQ7HuVTbsxSJipUZuXdUWUda+VYDs1XFpN6kz4HFlVb3mDo2SIJzFEP9mAmhOFJ9WUS Eh8JVM1P7l0gzF+bSeNTVWBI7uK0K2Mn5iEaNlOCmuMXouVVGyQ3RuZnfmHQG+YzDi0bDQShHCXj JY3UP0I+OYJg45NQDAbnML4/cVFnDZ5iCHbnNlrSDgbUU63AYOb/2G7WQwj1nIQ+4T3l30ryIoYm ZEZa0XM+ZDFaIGYqoW2OZ3Dm0/SZ5ydW6BTeP5zJIS+e40QtaR7OYoP+EiylUxV+JHsePmLmIphO 54kW5y2t6UOFZI2OpCeF5oDeQJz2pudLYkstYpXOZiqmVZYuJyDloGx20UvFvxPdZzROaTW2aTXO YyeyZhAyU6qmoyquapHe6mgm5z224WlmapVyai5h3wgk4gNmUT+FokmKaCpO5DcWYhAsZLz2vBO+ 6ryW5khqaCQu6pe+ZawuZqQ+U58Wl7eGa1kO1OkM5ciWbJmibAeybDLMbBzb7NAOzs8GbdE27Tok bR+57NP2XmU+Fd3VZm3sde3She3Ylt7ZJt3atm3mxfXt1E5BUzMzQvPtHRRcsSpu1T5uRkta0XWr uAWxz7YwgPrcEI5uX2la1TA/usFXgfVty6WS5Yaz6uYUZdW0k91NuBpufpluNPTuS6mXeHkaAH1Y kzytGQFZ1avJ4kKzxWAxyiUU9spB8oapokjQAT8dDIG4mw1KBdWsoXTwtO3cnE3u8laqCR+UBDej iXxN4aIWkFS/Dhe5B2fQ165bSJOXnD3xb93w3pyUr0s/6kAuBQUsqKTtlp6r7GklpxkzMMMXMdsw XHMRHxfL3LbxG8fx9PbaIqe3DtWrKHw3PssutFU9jurtt77MYmOyODtYvbFOhks1seJC8pWq5YzL cpjcbvWUb4ANtn4Lc60dc6Z7z2ixcBpKc3itWVhqcx3LNOHA2DVvsg8DjMhtvdE1ktY0Dk2r8noU VIOZyUu7bzyvUi8/OkDHTcVFwspNdHpc9FjbMtkR8rAUHkRPkZ0acjYPdOJs8k1j1t5bc+cG5VXb wao6ddtbUJ5E8T83303N9N8uI2Baz9t72YPtSR/W9eDZ9QSD8gsr0AWcdEXT4lE9dlQHpVESsu2U uA3Nb1evcQLMu3DLc4Aiqq5xTfaYc8zzj3E/mpiK9sFl18yy24B9DyqHPUt/bkyn//Rv96lwt3cV tzQYb0n73nIAAzVU7/er/PeZi1g+K+V9K3c4h/V9F1hbh0pmt5wlz7dsr/Vbn88nX1spV3OsM6k4 oa0jZM+Md09tn6eekNn2ZNCLrY11r0YDY/gq49cjuQ8BpXhhG3aBR++PXfZgv9edN3XKw63Fgfkw lJwUQ86NlM/EsBuGxJqaL9sD9/hbW/AFrblzp3oEPderx/V7Vw2BOvos1NwQBTr0C3GwCzUy13MA Gnt6OxovZ720/EfE/fAFk3jWUfq6o3ORRzzY4tYS1FCCxL3tQdeppErygx1Oi3o3d/u70xS53++3 18FJE3IwQ07Mv/zU8xC2ja6/XzC2turWERX6wSx3sft80A99LiS/AUV5nVzvxjWy1H/8m6L8YdVb i3k9o3eopms1l3v/eHzPesdXebHv/YY0fm4Xfp73+3OXfH8v8DRBfsFXdbovJ7l9ekRvrO5yfuov OWjDncgdfOUH2+wG+XiPlRCGFvGf/OOHQvaHsZ69fWJkm1af+4N/dAsX3pOxD3MFCAAABAgQSNAg wYQKFzJs6PAhxIgSB0qsWBHhQooFNWLceJBiR4siR5IsabIgyo0gT7JUGVHgSoYwEXJsafMmzpw6 d/Ls6fOnz5AONXr8qBBjR6FEkRIFetQp1KgZnYZMynEpSKxStx7cWlWr0YQ0wXIta5JsUbNCxaJN mbFpU7Ny59Kta/fuxbgy4WY9etXv28BpperFa7hh4cOKvS5u7NgivN+lgGHuVUrZr9WPWCWHRSzz MejQokerLdwX8GCmqNkKXgs0MWm5sGPThlz7dt21M/eizpx6YFLWwtl+HekaN/Lkyhdf7rpa9XCa gztDZ7xc7fXsnrVzx3nc5fCirnWbbks8/MTZ3dezb++e6vvX8ZWrn+++Ku/O4ssj5h89/3RiAWgf gQUaeKBzCNpUn4J4MdggfZuxltVpmjWnUnMzocXUX5g9tR2EIYo4omgPkijgiY2ZmCJpD16o3Yos /8o4I40ixXhiXBK6xdWLlSWImXQ/OggieDcu+F2R/V1WE3cMIlmbkTVKOaWUUYrImX5PBpWYbygK 5uVdcK0WIGFctqUXfg1aSSWbbboJ2pohMnkemAb1uNtbX/l2IZ/offhnmGCC96OdlhkaGVh8Bqff VI0qGOebkUoam4ZmpgdpT5g+yqiFA47Vm1aL/pYnX8Zp2lKFQHqa6qcTYtllp2OmJ+ektdrKnpZ5 PXbqgan6GF6rA/qZZXkdQsYrS8DBpiioQ6HpH6eaDftQru8heyu22UKFJHQZUngtSeAS6GuOxu7n bH/o/vfleMLmNl25wPo67HhkxRvtjvgiKK62/ZD6m+xs1Z2br138zmeutx7+hqeFHMLKIXp9Ejmk VQgHi2HF3jIbncCDEizklf+KPDJd3Foc62EGx4elruupHC7IEFVLKY0vk3yzyLpx3CyZsmWb47Hd 2VzSnC8NvS2VpuG8NNOmfpnWnuZhh+3Rt1bd9E+lYr011wZe7XLXqIa9nI5jm302fdp+XevaaIvN sNv/ccu9q9pz2+ao3YZV2mPeffuN9KSi9mz3VW3/jXGlhyu+OE+GJ7ebsjNjjWfkjjOOuOWXa56z 1XtnPqPnkm/+2uejM16555UFGTplrJsZk6q/yn535xqevre/ruu+O++9+/478MGXbjqLWuP9LKGv Ar3qc9V1We3wuNmueeL9AhAA9tlrvz333Xv/Pfjhiz8++eWTHz3xI95bJ5fpuh+ztIK2pnVxF1kv utt823q9+f37/z8AAyhA9KUPQoeCm+TqNT1q6e9P9avfS/5FwKRJUIAWvCAGM3i+AubNMsdbUb0A JbPjnIlc9Zmgs4SnwhWysIUuLIsLYyjDGdIwTvzTdCAOc6hD/6GQg15bX6Pa5S594Y1TaDpeEYci vR0ysYlO3N7RbvjEKVLRgjasIhaz2L8e+rBAEJQXy54mKwaaC3NzWt6OhAglLbKxjd+LohvjGMcr yrGOWeRiF8f1piPeRop2/KMT4QjIQTKRjoQUn0AOOT48/+ZRj1NS2hIVKUkMCnKSlvyfIakIk+4l 8pJWbCQoQxZJT5JygzwqJSrDl0lN+hF7rUylKUMpy14h55WwhGUlb6nLVbISilDk3yZd2UlhErOY w3QjI2epTLHVUpfOdCUMn7nLm9jyicP04zEDcM0bZlOYlZJjMpcpzruF8yjSnOYpz5lKXlYxka3M 5jaz101tVrON5Rzn48pGrMIJS38vwt9ETgLQMKkTl9EsaCnZ2ctXHlOK2+SmN7VXzyneE59QQl60 vnhEpcALWQBtYGgmitBB5nKkk1RoL703k182tJsrrWNFLdoi9cwMblP5Z0cBRh36tW+gJTMpKUsK 1EOidIKodoypTEtE0xiRMH4p+aKpqgcrahFxV0a1pFCv+seiahWZSb3Zk2qKrw6V8aPQGtyHfDoX kXaVjVlt6xypCVeSfhWsfMzoZ8aoT6ii1alPLRsk1SqbudI1nYSFqVwPi9i64myBqttMxr51Rtu5 jk5KiozCqFNVqyp2sV7pLDgTC1p7/zK2tGdhDFLZOtpCHnS1WuSqNd+5yXkOULU4RKppZ4nbgriW tIbtbTtFq8p50paH3LQt+JDbxN3mtpHMVS5wL/jW6O4QtvJkqAaLC0DtYpG5ze3ic6nb3dYO97rm jWcx6RnRNwKTu1gVLiKx+UtirrSTwUwvPR3a3vSid73GdOdL3fvG7xK4YDASb3B/Wz7uEle+KnUw OlG1RYhKdG/q5V5L54tfTvaXv9i8Xoa3W+AR+yw70L0wh/2LX/faV8BEJe+CJ0rb+w63mi3OL4j3 K1HzXri+J4bmgoyrTQwztMgV1jCKNdxhFMMzx0cWMYmjTJgDbzHJPJYnkjec5SHfcv+6yZUxmFVL Yxz7OMWuvO43rQxlCU+YyxV2qJqT3GQ0Y5nJx81yQ1f8Y21Kuc/yobL5dMxS9j75yzbeb5nh+WQA A3jNhMEkmDk5aEm/+cqFVrKlLx1A6xKZvS1uMqOD+VIV57fU6x01jtHcXhdj2M+ublyTqpzpSitZ uWP2nJqv+WYNxXmLMD5fpDut6Uw/dMczBjGtz9xrXwcZwdZ8NbS9E+sFb/nD+p01hicd5wYrW8vL XvCvazxmb96a3Mk1N5E/bcsGP3TP8oSvs3Xo3Wj3bd68PZ+ZNxxiUlf7uHDmtrWN7W4gfzbey4W3 wbNL74UTTWiLvHWA0U3ulhJX4rsPtji2U63xTYc74ZREuMel7svwkdPOxCGvbsdPzvFmqzyD9ib5 2V4+8JZDMeU0Zzabb/5JmPM8r9PW+c4LDvSV5zyl4+7qy3vOtaTPHOheHjoiQV5dCM816UqfHK6g PkCbaz25Up/6oek7W0F3+8apZvXHr95zpnfd0VFp+s05nUOIf5PbZbfwtwOpdp5bHe5x53rbOfn1 uWvb7sK+c75fu3eY9z3wPAS84yU6+Nt+mM5YPrabTa1stN928SRvfOTBreDQD5jlFMU4ulE97I2r PsGep7fV7036qI9+9q02ve0F/3rY3yf3qoQ86eUe+djvvm69933phY78muN++QSpL76fie93mj/d 9sJ3PPGhbzVrOV/3yu8+n5vv/OxrP3ArAz/zv9/96wee/OWPVPan3/Lqz579bXf/+90Uf/RLXlL4 92L+BaC0nR//PZ/+yRJICaACyszBFKABtsn/HYxNLSAFMiABFmAE5kQG3kf1VKAHTszibOCm5FHo fKAJipDiJKBzkSDrnKAJiqD0TKBugRdSjJELBiAMXpRjgWCeJEgJGgc1TRXYIP/gDd5gDlJK6qSQ ujAKXynhkdASERbhC15OZeUVeYRRE1ohZvmVSwihCo7GEeKKFE5hCNZgxEwLhlzWF7qFBwHLmAiO YL1LVJWg7iiMiwSh1IDhGH5gGPbRCHWgEwrHFyahvBTiztggzQChG24IsRyLDXlXudiUDM6KA62h jfThHpZM+rRPPzEPGsbMw5zMIX5iiaBKwDxLGClRgGiMh3hhHGYNA/GgQPHKK2ai8ZnOWVnWoECV P6Eix3RLwoxiLZmi0ZCRk9CLvbwhy9TiTiyLzxHHXwRjB+oJZBVOx3jMWGCiLQpUAWnjyhDjCF2K 0QBiI46KMPbVWoUjoGQGech7isBUSMfAIat44zYqIvHQ432AYyw+o75glCGGYsSgzykKSjt64jlO RlklpDnWI/x1Y1JZickoCRpeYfO0CsM8DwEtFcEU5NNAEEfGo0IKIUM+EgfhY3uYZNpQ4mPNy0Lu EzCSVTkOzGaNZIqgpB7KlE0OI01CX06G1EPO/+BO7l5P+iSQ7GAd/iAZwU9DRmFQet5Qwsn7aJYb MqE/tuQBMmVT7t1T0k0/5WJASqSXTE+hWCOpkBXEPA5QZqXabSVXluV3hNAnTuBURY0gbkhMnRAh NgzuIKUT2iRbqmXNgJf7gBRchgtAIqJRXIxItsglsssbfqVBoqMjldwsllFe4E5R7mVeAqaM/KVj VCUJeaUqNo87Qoti5uFNtsy0FGZGiYpYRg40lmVd8pNiuIhgxaFHPiZVcibokGBUesxqOsk7rsQB meU8ImYpOuIkjhVqpmFHGo9MniZyTk1AdRRtnsc1JmAWsqZk8qbX+CZONiZwihEpBqJVvqWyxH1k d05Zda4iIwojamLmEj6ndxbPCoZn0EykaILgcJLnTqknMy7IpRilvRQoZOYHYe7n7TwhVpbkT+an LganI/6je14khQBo6QRMVGIkae7mhlrKb06OsYTVmgRo/tynRXlmcs6nZTnMbB5nP26hf66nXRkm g4KSin7mg4ZSjv8uDVz2534EC+UkSjYKKUtSDT86KH7yaD1e4WtC45DyzH9KaZDuoNoUjWB6xYWW pm7S6GTiaJNWZYd6IodS6cXYlZ2gzD1qaRHxIozWZFpmIkWiyFk6h2vaZSWCSipeqXw6pJaC6IEm kfrEqRSSI8ogELNozLfETqxYqIniSJ/6KQy1IZQ2VW+GSZAgjhlF4v/1aEl6KhguJy5ahy5mIQrC aW6UkBhl6kySTeNsqfxQoKiyIKjWJpsq44xeZckITk6ZqfudSpq0an3KTa0yh3UgKuRY6XQakIPw jUYpqNC8qmm2zmk4D+o0arESaw1tK7d2q7ey0AimaG26qf0A4JZVQCc1yqV0lmdWyp8DYlK44pPh AJGpxqq1NGMPqufgWCSeIqCyCmtIvatnfeeSrhVI5iq7wkgzGs9cLgow4qoyPepnCmxo7cuOgqlO LGoPqqueYA62Sv9szA1kWNyJogDHWlFsXFlswaLosPYVkI7Knr4dynqVylKmtUAiodZnRMakk66N u87sIsWrBTKmPrpqg+rsXb3szqoF0LqV0IYonJQozh6tdz6rIeqlVDJt097R0z7nkhApiL5kw0xp GvJrc9KGDXnRBGUrH24t1wrNWxYjxPaqfz6QgQYq1EwtNyaiTrVly+6L246Xy1ipyF5tE3LkyN6t hx6kThJNMqkVyArorf4TuirP315E4Loe3GJm4WLoqe7iVC6kK66j3joNlJZjAxlp/DzpThVK4p6t HL6dmHCpr17uS2SuJnFgpO6jcyLrUnFq7DiqczKqmqKl49Ln4tproN2OKd2SrYrwSGiuKiTZLrXg LkWd5L+25yaeReXibWvOD/OSK8DCkGxQql5yIvVWr/Xq3eZiCtuS7/HObWoEIsIYrnnII1SyZ6lC 52imr/quL2s1iZQZiYsOrwGbp5oOKcRwLKL4LVV077L/+u9EAPDBSfDn2uyJsqfvjmWCWvBQUHAA e/DHwMzcvG8F/iwIm7BKUlOV5KwIOxwIy1vXaMkdXiqTvvDxxXDnLZ1Giieq3jAOZ50O73BjwerD HmTkhtQytk0tZqAKLyAKU/ATyy+dKNAQ/VCazuq2nJCNmCsGY+9IRjEAT/HVDszyIuy4bGb5rjAb n+QX62jR2qLfcZ6wYZW7td6zFfGYrqt7ksjulolTHbHzjq8fyu1M3eg2Ip6dxZcVifHDXZqLVZ63 VXBS7o/rYmc2YjLsqq0lLqzynmmEemkh8y7GoG705u3qRmnrpmeQRvALPlib1RZMSXLe6Zsje91K ng7oTCQxKdNlr5qvG6uj/datmPJxw7ILGVMNLJtZh5ldgPkb2X3axIkdnBFaofXXks1ZqSXaM5ud 9/Gl3+QkEyuuMQNRMJOy6PLv99auvnr/ZDJbzTKzFK/ZWZqF2L5p8z0Dk7hBHIcpsp7Nl0tdW8aF HzgH8bkuTJEs8GJGqzB7rr1mSOiWqREtcRjH8+otcuJ5M0bzWD53m0XXcY/5s5xVXkBDso2t5Dsv XqeqpAJDljiSSvCyIgPDdJN+tIoJGo1Fs6Xtm5vx9NFtGZJhMy2vmJb59Ekbo0FLDxRqb1LDSbod 3aihmlTnGDRb3FSr244ZGlTf19j5G5npV7tdnMbhcfgxdVPXmz2etYq41S1nG3CltFoDTlyTzWv9 tLzRsVHB9VzD4l7TxxATcV+PamA301+73GCvaWkAa1O3debq9WFroMG28dC+MGMHrmM/KTYL/+nC FKk13pUIV7bbXjZmM9Pb7fGbArMEg/bWivZo7+0WcykoX7IrgetsYRt2a+uy7Jo2z5pzatd22t22 2RDm5H5tKndFJguq/6p207I2cGdmkhotDis30DJ3c1fqkghwUkv3zFJ3dZ8vL3d30fm224G3iGox eTuIeAfdeTONea+33qT31rm3j8p3H8E30dE3fheYdqMsd+e3f6O3fcPrfw94ae03xfY3gUMneO0F OO0puIOLk4ELLII/OIVnCoM/XoVnuHNdOM5puId/OIiHuIiPOImXuImfOIqnuIqvOIu3uIu/OIzH uIzPOI3XMriN3ziO57iO7ziP97iP/ziQB7mQDzmRF7mRHzmSJ7mSLzmTN7mTPzmUR7mUTzmVV7mV Ll85lme5lm85l3e5l385mIe5mI85mZe5mZ85mqe5mq85m7e5m785nMe5nDd3QAAAOw== --=_336FFDB5.0263304F-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 02:41:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08318 for ; Tue, 17 Dec 2002 02:41:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBH7iOi24639 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 02:44:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBH7iOv24635 for ; Tue, 17 Dec 2002 02:44:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08311 for ; Tue, 17 Dec 2002 02:41:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBH7iFv24616; Tue, 17 Dec 2002 02:44:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBH7f8v24527 for ; Tue, 17 Dec 2002 02:41:08 -0500 Received: from slap.mg2-lyon.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08248 for ; Tue, 17 Dec 2002 02:37:54 -0500 (EST) Received: from jpl (jpl.mg2-lyon.fr [132.147.160.27]) by slap.mg2-lyon.fr (Postfix) with SMTP id 0DC8A10EFD; Tue, 17 Dec 2002 09:27:21 +0100 (CET) From: "Jean Philippe Longeray" To: "Skip Cave" , Cc: Subject: RE: [Speechsc] SPEECHSC vs 3GPP Date: Tue, 17 Dec 2002 08:33:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C2A5A6.EA1082E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C2A5A6.EA1082E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi skip, You're right, I didn't say something different. Like MRCP, SPEECHSC is a media command protocol. SIP is not only a streaming protocol, It can be used as a transport protocol, like HTTP, X.224, ... If SIP transports SDP, it becomes a streaming protocol, but what don't you thing it's not possible to transport SPEECHSC messages in SIP Content. In your document, something is missing: You need something to find an Resource Server (ASR, SVI, TTS), and I propose to use SIP softswitching, This softswitch could be inserted between your Application Execution Server and all others voice resource (It could be ASR, TTS, SVI, but also Audio/Video streaming, conferencing, ....) I think that draft-robinson-mrcp-sip-00 is a great example that I want to say. Do you agree Eric? Best regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: lundi 16 décembre 2002 20:47 To: speechsc@ietf.org Cc: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Subject: RE: [Speechsc] SPEECHSC vs 3GPP Eric, Jean, It's good that we agree. I believe that there has been some confusion in the past that SpeechSC is a media streaming protocol. We need to list the basic issues to make sure that we clear up that misconception: 1) SpeechSC is NOT a media streaming protocol. 2) The SpeechSC protocol is strictly a command/response protocol, carrying commands and returning responses from application servers to speech servers. The SpeechSC protocol will never be a media transport protocol, and will never carry any type of media. 3) Even though the SpeechSC protocol is not a media transport protocol, the SpeechSC protocol can be used to COMMAND speech servers to set up streaming with another server using some type of streaming protocol (like SIP). Which streaming protocol is used will be determined as part of the SpeechSC's work. For example, in my attached architecture diagram, the SpeechSC protocol allows an Application Server commanding an ASR server to set up a SIP session between the ASR server and a telephony platform (see attached figure). Note that there is a SpeechSC command/control session between the Application Server and the ASR Server, but there is no streaming media going betweeen the Application & ASR Servers. There IS a standard SIP session between the Speech server and the Telephony platform, that was set up by commands given in the SpeechSC protocol. This SIP session does NOT carry any commands other than standard SIP setup/teardown commands. An example of the command/response sequence in a SpeechSC Command stream would be: Request from Application server to Directory Services for an ASR server Reply from Directory Services To Application Server giving info on specific ASR Server Command from Application Server to ASR Server to set up a specific command/ response session for a call (one command session per call context) Response from ASR Server to Application Server acknowledging the completion of the session set-up. Command from Application Server to selected ASR server to set up SIP session with a specific Telephony Server. The App Server gives the ASR server the addresses of the Telephony Server so the App Server can set up the SIP session. (ASR Server sets up SIP Session to Telephony Server)) Response from ASR Server indicating successful SIP session setup. Command from Application Server to ASR Server to set up grammars and start recognition on ASR Server. Response from ASR Server to Application Server reporting a grammar match or timeout from ASR Server. etc. Again, this is shown in mu attached diagram. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Eric Burger" 12/16/02 08:29AM >>> From a personal perspective, the MRCP over SIP proposal was what pushed me over the edge to fix MRCP. I would be hard pressed to try to convince the IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, ... We need to pick the one that makes the most sense. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Monday, December 16, 2002 3:12 AM To: Skip Cave; Eric Burger Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Hi Skip, Nice to have some news from Intervoice... I agree. SIP will never provide multimedia control functionnalities, but I'm sure it's a great protocol from transport (and mandatory for 3G). WG has to define a couple of protocols, like MRCP/RTSP. What do you think of SPEECHSC/SIP, which can be very closed from MRCP/SIP. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: vendredi 13 décembre 2002 19:38 To: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Jean, Eric, I don't think SIP will support the separated media/control requirements I posted earlier. You will need a control protocol, and a separate media protocol. I expect that it will take a new protocol to meet these requirements. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Jean Philippe Longeray" 12/13/02 01:25AM >>> Thanks Eric for this analyze, I agree. H.248 doesn't seems to be the right answer for MRFC/MRFP, even if special packages can be provided. For my opinion, SIP is the correct answer for transport layer (since it's used everywhere in 3GPP and 3GPP2), and SPEECHSC could (should?) be used for resource control. Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing Protocols", I would like to add some remarks: In case of you would like to insert a routing mechanism (a SIP soft-switch) between Media Processing Entity / Application server and Resource server (ASR, SI/SV, TTS, Announcement server), I could be interesting to have a single transport protocol, like SIP, instead of several incompatible protocols (RTSP for example) for the closes functionalities. I think it is easier to add some redundancy, rather than conserving "old" protocols like RTSP. It seems to be very important to make distinctions between each layers of model. Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC, could be an answer. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: vendredi 13 décembre 2002 03:13 To: Jean Philippe Longeray Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] SPEECHSC vs 3GPP The Mp interface is (1) not the right concept and (2) is itself (IMHO) not the correct choice for 3GPP's needs, either. With respect to (1), Mp is trying to be an analog to the MGC/MG decomposition for a media server, where the MRFC is a "media server controller" and the MRFP is a "media server [processor]". The types of resources are bearer packet processors (e.g., tone detection, prompt playing, and recording). The protocol is a low-level device control protocol (e.g., allocate a resource, allocate a RTP port, connect the port to the resource, wait for a signal, etc.). speechsc is a higher-level protocol, concerned with things like 'establish session' and 'recognize speech'. In fact, early in the days of MRCP/speechsc, people wanted to extend the speechsc scope to do device control. The answer has consistently been to use H.248 for device control. With respect to (2), AFAIK, no one has ever built a MRFC. I believe this is because unlike a media gateway, where there are definite decomposition benefits, there are really few if any benefits to decomposing the MRF. In fact, there are clear benefits to using the native application interface (SIP), rather than the native gateway interface (H.248) for interfacing the AS and CSCF to the MRF. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 10, 2002 5:53 AM To: IETF SPEECHSC (E-mail) Subject: [Speechsc] SPEECHSC vs 3GPP Hi, Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229 Rel5) architecture. It looks like SPEECHSC is very closed from Mp interface (H.248). Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------=_NextPart_000_0044_01C2A5A6.EA1082E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi = skip,
 
You're right, I = didn't say=20 something different.
 
Like MRCP, SPEECHSC = is a media=20 command protocol. SIP is not only a streaming protocol, It can be used = as a=20 transport protocol, like HTTP, X.224, ... If SIP transports SDP, it = becomes a=20 streaming protocol, but what don't you thing it's not possible to = transport=20 SPEECHSC messages in SIP Content.
 
In your document, = something is=20 missing: You need=20 something to find an Resource Server (ASR, SVI, TTS), and I propose to = use SIP=20 softswitching,
This softswitch = could be=20 inserted between your Application Execution Server and all others voice = resource=20 (It could be ASR, TTS, SVI, but also Audio/Video streaming, = conferencing,=20 ....)
 
 
I think=20 that draft-robinson-mrcp-sip-00 is a great example that I want to = say. Do=20 you agree Eric?
 
Best=20 regards.
 
Jean-Philippe=20 LONGERAY 
R&D = Director - Service=20 NODE
 
NetCentrex 
 
Jean-philippe.longe= ray@netcentrex.net
+ 33 4 72 53 61 = 33 - + 33 4=20 72 53 61 30
Mobile: + 33 6 = 76 48 34=20 95
http://www.netcentrex.net<= /DIV>
 
-----Original Message-----
From: Skip Cave=20 [mailto:skip.cave@intervoice.com]
Sent: lundi 16 d=E9cembre = 2002=20 20:47
To: speechsc@ietf.org
Cc:=20 jean-philippe.longeray@netcentrex.net;=20 eburger@snowshore.com
Subject: RE: [Speechsc] SPEECHSC vs=20 3GPP

Eric, Jean,
 
It's good that we agree. I believe that there has been some = confusion in=20 the past that SpeechSC is a media streaming protocol. We need to list = the=20 basic issues to make sure that we clear up that misconception:
 
1) SpeechSC is NOT a media streaming protocol.
2) The SpeechSC protocol is strictly a command/response protocol, = carrying commands and returning responses from application servers to = speech=20 servers. The SpeechSC protocol will never be a media transport = protocol, and=20 will never carry any type of media.
3) Even though the SpeechSC protocol is not a media transport = protocol,=20 the SpeechSC protocol can be used to COMMAND speech servers to set up=20 streaming with another server using some type of streaming protocol = (like=20 SIP). Which streaming protocol is used will be determined as part = of the=20 SpeechSC's work.
 
For example, in my attached architecture diagram, the SpeechSC = protocol=20 allows an Application Server commanding an ASR server to set up a SIP = session=20 between the ASR server and a telephony platform (see attached=20 figure). Note that there is a SpeechSC command/control session = between=20 the Application Server and the ASR Server, but there is no streaming = media=20 going betweeen the Application & ASR Servers. There IS a = standard SIP session between the Speech server and the Telephony = platform,=20 that was set up by commands given in the SpeechSC protocol. This SIP = session=20 does NOT carry any commands other than standard SIP setup/teardown = commands.=20
 
An example of the command/response sequence in a SpeechSC = Command=20 stream would be:
 
Request from Application server to Directory Services for an ASR=20 server
Reply from Directory Services To Application Server giving info = on=20 specific ASR Server
Command from Application Server to ASR Server to set up a = specific=20 command/ response session for a call (one command session per call=20 context)
Response from ASR Server to Application Server acknowledging the=20 completion of the session set-up.
Command from Application Server to selected ASR = server to=20 set up SIP session with a specific Telephony Server. The App Server = gives the=20 ASR server the addresses of the Telephony Server so the App Server can = set up=20 the SIP session.
(ASR Server sets up SIP Session to Telephony Server))
Response from ASR Server indicating successful SIP session = setup.
Command from Application Server to ASR Server to set up grammars = and=20 start recognition on ASR Server.
Response from ASR Server to Application Server reporting a = grammar match=20 or timeout from ASR Server.
etc.
 
Again, this is shown in mu attached diagram.
 
Skip Cave
Sr. Principal Engineer
Intervoice Inc.


>>> "Eric Burger" <eburger@snowshore.com> = 12/16/02=20 08:29AM >>>
From a personal perspective, the MRCP over SIP = proposal was what pushed me over the edge to fix MRCP.  I would = be hard=20 pressed to try to convince the IESG that there is a need for = MRCP/RTSP,=20 MRCP/SIP, MRCP/foo, ...  We need to pick the one that makes the = most=20 sense.

-----Original Message-----
From: Jean Philippe = Longeray [mailto:jean-philip= pe.longeray@netcentrex.net]
Sent:=20 Monday, December 16, 2002 3:12 AM
To: Skip Cave; Eric Burger
Cc: = speechsc@ietf.org
Subject: RE: [Speechsc] SPEECHSC vs = 3GPP


Hi=20 Skip,

Nice to have some news from Intervoice...

I agree. = SIP  will never provide  multimedia control = functionnalities, but=20 I'm sure it's a great protocol from transport (and mandatory for = 3G).
WG=20 has to define a couple of protocols, like MRCP/RTSP. What do you think = of=20 SPEECHSC/SIP, which can be very closed from=20 MRCP/SIP.

Regards.


Jean-Philippe LONGERAY =
R&D=20 Director - Service NODE

NetCentrex=20

Jean-philippe.longeray@netcentrex.net
+ 33 4 72 53 61 33 - = + 33 4=20 72 53 61 30
Mobile: + 33 6 76 48 34 95
http://www.netcentrex.net

-= ----Original=20 Message-----
From: Skip Cave [mailto:skip.cave@intervoice.com= ]
Sent:=20 vendredi 13 d=E9cembre 2002 19:38
To: = jean-philippe.longeray@netcentrex.net;=20 eburger@snowshore.com
Cc: speechsc@ietf.org
Subject: RE: = [Speechsc]=20 SPEECHSC vs 3GPP


Jean, Eric,

I don't think SIP will = support=20 the separated media/control requirements I posted earlier. You will = need a=20 control protocol, and a separate media protocol. I expect that it will = take a=20 new protocol to meet these requirements.

Skip Cave
Sr. = Principal=20 Engineer
Intervoice Inc.


>>> "Jean Philippe = Longeray"=20 <jean-philippe.longeray@netcentrex.net> 12/13/02 01:25AM=20 >>>
Thanks Eric for this analyze,

I agree. H.248 = doesn't=20 seems to be the right answer for MRFC/MRFP, even if
special = packages can be=20 provided.

For my opinion, SIP is the correct answer for = transport layer=20 (since it's
used everywhere in 3GPP and 3GPP2), and SPEECHSC could=20 (should?) be used for
resource control.

Concerning SPEECHSC, = 3.3=20 "Avoid Duplicating Existing Protocols", I would
like to add some=20 remarks:

In case of you would like to insert a routing = mechanism (a SIP=20 soft-switch)
between Media Processing Entity / Application server = and=20 Resource server
(ASR, SI/SV, TTS, Announcement server), I could be=20 interesting to have a
single transport protocol, like SIP, instead = of=20 several incompatible
protocols (RTSP for example) for the closes=20 functionalities. I think it is
easier to add some redundancy, = rather than=20 conserving "old" protocols like
RTSP.

It seems to be very = important=20 to make distinctions between each layers of
model.
Something = like=20 UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC,
could be = an=20 answer.



Regards.


Jean-Philippe = LONGERAY
R&D=20 Director - Service=20 = NODE

NetCentrex

Jean-philippe.longeray@netcentrex.net
&l= t;mailto:Jean-philipp= e.longeray@netcentrex.net>
+=20 33 4 72 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 = 95
http://www.netcentrex.net

<= BR>
-----Original=20 Message-----
From: Eric Burger [mailto:eburger@snowshore.com]<= BR>Sent:=20 vendredi 13 d=E9cembre 2002 03:13
To: Jean Philippe Longeray
Cc: = IETF=20 SPEECHSC (E-mail)
Subject: RE: [Speechsc] SPEECHSC vs = 3GPP


The=20 Mp interface is (1) not the right concept and (2) is itself (IMHO) = not
the=20 correct choice for 3GPP's needs, either.

With respect to (1), = Mp is=20 trying to be an analog to the MGC/MG
decomposition for a media = server,=20 where the MRFC is a "media server
controller" and the MRFP is a = "media=20 server [processor]".  The types of
resources are bearer packet = processors (e.g., tone detection, prompt
playing, and = recording).  The=20 protocol is a low-level device control
protocol (e.g., allocate a = resource,=20 allocate a RTP port, connect the port
to the resource, wait for a = signal,=20 etc.).  speechsc is a higher-level
protocol, concerned with = things=20 like 'establish session' and 'recognize
speech'.

In fact, = early in=20 the days of MRCP/speechsc, people wanted to extend the
speechsc = scope to do=20 device control.  The answer has consistently been to
use H.248 = for=20 device control.

With respect to (2), AFAIK, no one has ever = built a=20 MRFC.  I believe this is
because unlike a media gateway, where = there=20 are definite decomposition
benefits, there are really few if any = benefits=20 to decomposing the MRF.  In
fact, there are clear benefits to = using=20 the native application interface
(SIP), rather than the native = gateway=20 interface (H.248) for interfacing the
AS and CSCF to the=20 MRF.

-----Original Message-----
From: Jean Philippe Longeray = [mailto:jean-philip= pe.longeray@netcentrex.net]
Sent:=20 Tuesday, December 10, 2002 5:53 AM
To: IETF SPEECHSC = (E-mail)
Subject:=20 [Speechsc] SPEECHSC vs 3GPP


Hi,

Do you ever compare = SPEECHSC=20 and MRFC/MRFP interface in 3GPP (TS 24.229
Rel5) = architecture.

It=20 looks like  SPEECHSC  is very closed from Mp interface=20 (H.248).

Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2=20 (www.3gpp2.org) ,
3G.IP (www.3gip.org),  MWIF=20 (www.mwif.org)?

Regards.

Jean-Philippe = LONGERAY
R&D=20 Director - Service=20 = NODE

NetCentrex

Jean-philippe.longeray@netcentrex.net
+ = 33 4=20 72 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 95
http://www.netcentrex.net

_= ______________________________________________
Speechsc=20 mailing list
Speechsc@ietf.org
https://www1.iet= f.org/mailman/listinfo/speechsc
__________________________________= _____________
Speechsc=20 mailing list
Speechsc@ietf.org
https://www1.iet= f.org/mailman/listinfo/speechsc
------=_NextPart_000_0044_01C2A5A6.EA1082E0-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 03:47:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09455 for ; Tue, 17 Dec 2002 03:47:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBH8oJL28288 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 03:50:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBH8oIv28285 for ; Tue, 17 Dec 2002 03:50:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09449 for ; Tue, 17 Dec 2002 03:47:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBH8oBv28275; Tue, 17 Dec 2002 03:50:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBH8mxv28193 for ; Tue, 17 Dec 2002 03:48:59 -0500 Received: from ahuumrelay3.ams.ops.eu.uu.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09435 for ; Tue, 17 Dec 2002 03:45:45 -0500 (EST) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay3.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id gBH8men29613; Tue, 17 Dec 2002 08:48:41 GMT Received: from polo (polo.hq.eloquant.com [192.168.0.131]) by weasel.hq.eloquant.com (Postfix) with SMTP id 23FD23B727; Tue, 17 Dec 2002 03:43:19 -0500 (EST) Reply-To: From: "Brian Wyld" To: "'Jean Philippe Longeray'" , "'Skip Cave'" , Cc: Subject: RE: [Speechsc] SPEECHSC vs 3GPP Date: Tue, 17 Dec 2002 09:46:40 +0100 Message-ID: <016d01c2a5a8$d22034d0$8300010a@hq.eloquant.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016E_01C2A5B1.33E49CD0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_016E_01C2A5B1.33E49CD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Messieurs Some interesting discussion here - to ease the job of the protocol eval doc editor :-) perhaps someone would like to do a protocol analysis section for 3GPP H.248 (maybe just to rule it out?) - Jean-Philippe perhaps? My 2c on the SPEECHSC/whatever - I think there is a first question to resolve in my mind Q1: what is the best model for SPEECHSC: - a layer OVER a media signalling protocol (SIP, RTSP, etc, depending on this lower layer for media and session control, just like MRCP/RTSP currently does) -> in which case what is the encapsulation mechanism - RTSP has ANNOUNCE messages, what does SIP provide for this sort of bundling? -> and what is the "best" protocol to layer over - an extension to an existing media signalling protocol (eg, add MRCP "verbs" as new ones in RTSP, or add as new SIP commands...) - a new protocol incorporating both media signalling, session control and resource control (eg Web services extensions) As for the identification and resolution of resource servers, this is for me a separate functionality to SPEECHSC itself, and there are already multiple mechanisms existing (SLP, UDDI, etc) for service location and discovery. Brian -----Message d'origine----- De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la part de Jean Philippe Longeray Envoyé : Tuesday, December 17, 2002 08:33 À : Skip Cave; speechsc@ietf.org Cc : eburger@snowshore.com Objet : RE: [Speechsc] SPEECHSC vs 3GPP Hi skip, You're right, I didn't say something different. Like MRCP, SPEECHSC is a media command protocol. SIP is not only a streaming protocol, It can be used as a transport protocol, like HTTP, X.224, ... If SIP transports SDP, it becomes a streaming protocol, but what don't you thing it's not possible to transport SPEECHSC messages in SIP Content. In your document, something is missing: You need something to find an Resource Server (ASR, SVI, TTS), and I propose to use SIP softswitching, This softswitch could be inserted between your Application Execution Server and all others voice resource (It could be ASR, TTS, SVI, but also Audio/Video streaming, conferencing, ....) I think that draft-robinson-mrcp-sip-00 is a great example that I want to say. Do you agree Eric? Best regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: lundi 16 décembre 2002 20:47 To: speechsc@ietf.org Cc: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Subject: RE: [Speechsc] SPEECHSC vs 3GPP Eric, Jean, It's good that we agree. I believe that there has been some confusion in the past that SpeechSC is a media streaming protocol. We need to list the basic issues to make sure that we clear up that misconception: 1) SpeechSC is NOT a media streaming protocol. 2) The SpeechSC protocol is strictly a command/response protocol, carrying commands and returning responses from application servers to speech servers. The SpeechSC protocol will never be a media transport protocol, and will never carry any type of media. 3) Even though the SpeechSC protocol is not a media transport protocol, the SpeechSC protocol can be used to COMMAND speech servers to set up streaming with another server using some type of streaming protocol (like SIP). Which streaming protocol is used will be determined as part of the SpeechSC's work. For example, in my attached architecture diagram, the SpeechSC protocol allows an Application Server commanding an ASR server to set up a SIP session between the ASR server and a telephony platform (see attached figure). Note that there is a SpeechSC command/control session between the Application Server and the ASR Server, but there is no streaming media going betweeen the Application & ASR Servers. There IS a standard SIP session between the Speech server and the Telephony platform, that was set up by commands given in the SpeechSC protocol. This SIP session does NOT carry any commands other than standard SIP setup/teardown commands. An example of the command/response sequence in a SpeechSC Command stream would be: Request from Application server to Directory Services for an ASR server Reply from Directory Services To Application Server giving info on specific ASR Server Command from Application Server to ASR Server to set up a specific command/ response session for a call (one command session per call context) Response from ASR Server to Application Server acknowledging the completion of the session set-up. Command from Application Server to selected ASR server to set up SIP session with a specific Telephony Server. The App Server gives the ASR server the addresses of the Telephony Server so the App Server can set up the SIP session. (ASR Server sets up SIP Session to Telephony Server)) Response from ASR Server indicating successful SIP session setup. Command from Application Server to ASR Server to set up grammars and start recognition on ASR Server. Response from ASR Server to Application Server reporting a grammar match or timeout from ASR Server. etc. Again, this is shown in mu attached diagram. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Eric Burger" 12/16/02 08:29AM >>> From a personal perspective, the MRCP over SIP proposal was what pushed me over the edge to fix MRCP. I would be hard pressed to try to convince the IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, ... We need to pick the one that makes the most sense. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Monday, December 16, 2002 3:12 AM To: Skip Cave; Eric Burger Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Hi Skip, Nice to have some news from Intervoice... I agree. SIP will never provide multimedia control functionnalities, but I'm sure it's a great protocol from transport (and mandatory for 3G). WG has to define a couple of protocols, like MRCP/RTSP. What do you think of SPEECHSC/SIP, which can be very closed from MRCP/SIP. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: vendredi 13 décembre 2002 19:38 To: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Jean, Eric, I don't think SIP will support the separated media/control requirements I posted earlier. You will need a control protocol, and a separate media protocol. I expect that it will take a new protocol to meet these requirements. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Jean Philippe Longeray" 12/13/02 01:25AM >>> Thanks Eric for this analyze, I agree. H.248 doesn't seems to be the right answer for MRFC/MRFP, even if special packages can be provided. For my opinion, SIP is the correct answer for transport layer (since it's used everywhere in 3GPP and 3GPP2), and SPEECHSC could (should?) be used for resource control. Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing Protocols", I would like to add some remarks: In case of you would like to insert a routing mechanism (a SIP soft-switch) between Media Processing Entity / Application server and Resource server (ASR, SI/SV, TTS, Announcement server), I could be interesting to have a single transport protocol, like SIP, instead of several incompatible protocols (RTSP for example) for the closes functionalities. I think it is easier to add some redundancy, rather than conserving "old" protocols like RTSP. It seems to be very important to make distinctions between each layers of model. Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC, could be an answer. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: vendredi 13 décembre 2002 03:13 To: Jean Philippe Longeray Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] SPEECHSC vs 3GPP The Mp interface is (1) not the right concept and (2) is itself (IMHO) not the correct choice for 3GPP's needs, either. With respect to (1), Mp is trying to be an analog to the MGC/MG decomposition for a media server, where the MRFC is a "media server controller" and the MRFP is a "media server [processor]". The types of resources are bearer packet processors (e.g., tone detection, prompt playing, and recording). The protocol is a low-level device control protocol (e.g., allocate a resource, allocate a RTP port, connect the port to the resource, wait for a signal, etc.). speechsc is a higher-level protocol, concerned with things like 'establish session' and 'recognize speech'. In fact, early in the days of MRCP/speechsc, people wanted to extend the speechsc scope to do device control. The answer has consistently been to use H.248 for device control. With respect to (2), AFAIK, no one has ever built a MRFC. I believe this is because unlike a media gateway, where there are definite decomposition benefits, there are really few if any benefits to decomposing the MRF. In fact, there are clear benefits to using the native application interface (SIP), rather than the native gateway interface (H.248) for interfacing the AS and CSCF to the MRF. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 10, 2002 5:53 AM To: IETF SPEECHSC (E-mail) Subject: [Speechsc] SPEECHSC vs 3GPP Hi, Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229 Rel5) architecture. It looks like SPEECHSC is very closed from Mp interface (H.248). Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------=_NextPart_000_016E_01C2A5B1.33E49CD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Messieurs
 
Some interesting = discussion=20 here - to ease the job of the protocol eval doc editor :-) perhaps = someone would=20 like to do a protocol analysis section for 3GPP H.248 (maybe just to = rule it=20 out?) - Jean-Philippe perhaps?
 
My 2c on the = SPEECHSC/whatever=20 - I think there is a first question to resolve in my mind =
 Q1: what is the best model = for=20 SPEECHSC:
 - a = layer OVER a=20 media signalling protocol (SIP, RTSP, etc, depending on this lower layer = for=20 media and session control, just like MRCP/RTSP currently=20 does)
    = -> in=20 which case what is the encapsulation mechanism - RTSP has ANNOUNCE = messages,=20 what does SIP provide for this sort of bundling?
    ->=20 and what is the "best" protocol to layer over
 - an = extension to an=20 existing media signalling protocol (eg, add MRCP "verbs" as new ones in = RTSP, or=20 add as new SIP commands...)
 - a new = protocol=20 incorporating both media signalling, session control and resource = control (eg=20 Web services extensions)
 
As for the = identification and=20 resolution of resource servers, this is for me a separate functionality = to=20 SPEECHSC itself, and there are already multiple mechanisms existing = (SLP, UDDI,=20 etc) for service location and discovery.
 
Brian
-----Message d'origine-----
De : = speechsc-admin@ietf.org=20 [mailto:speechsc-admin@ietf.org]De la part de Jean Philippe=20 Longeray
Envoy=E9 : Tuesday, December 17, 2002=20 08:33
=C0 : Skip Cave; = speechsc@ietf.org
Cc :=20 eburger@snowshore.com
Objet : RE: [Speechsc] SPEECHSC = vs=20 3GPP

Hi = skip,
 
You're right, I = didn't say=20 something different.
 
Like MRCP, = SPEECHSC is a=20 media command protocol. SIP is not only a streaming protocol, It can = be used=20 as a transport protocol, like HTTP, X.224, ... If SIP transports SDP, = it=20 becomes a streaming protocol, but what don't you thing it's not = possible to=20 transport SPEECHSC messages in SIP Content.
 
In your document, = something=20 is missing: You need=20 something to find an Resource Server (ASR, SVI, TTS), and I propose to = use SIP=20 softswitching,
This softswitch = could be=20 inserted between your Application Execution Server and all others = voice=20 resource (It could be ASR, TTS, SVI, but also Audio/Video streaming,=20 conferencing, ....)
 
 
I think=20 that draft-robinson-mrcp-sip-00 is a great example that I want to = say. Do=20 you agree Eric?
 
Best=20 regards.
 
Jean-Philippe = LONGERAY 
R&D = Director - Service=20 NODE
 
NetCentrex 
 
Jean-philippe.longe= ray@netcentrex.net
+ 33 4 72 53 = 61 33 - + 33 4=20 72 53 61 30
Mobile: + 33 = 6 76 48 34=20 95
http://www.netcentrex.net<= /DIV>
 
-----Original Message-----
From: Skip Cave=20 [mailto:skip.cave@intervoice.com]
Sent: lundi 16 = d=E9cembre 2002=20 20:47
To: speechsc@ietf.org
Cc:=20 jean-philippe.longeray@netcentrex.net;=20 eburger@snowshore.com
Subject: RE: [Speechsc] SPEECHSC vs=20 3GPP

Eric, Jean,
 
It's good that we agree. I believe that there has been some = confusion=20 in the past that SpeechSC is a media streaming protocol. We need to = list the=20 basic issues to make sure that we clear up that misconception: =
 
1) SpeechSC is NOT a media streaming protocol.
2) The SpeechSC protocol is strictly a command/response = protocol,=20 carrying commands and returning responses from application servers = to speech=20 servers. The SpeechSC protocol will never be a media transport = protocol, and=20 will never carry any type of media.
3) Even though the SpeechSC protocol is not a media transport = protocol,=20 the SpeechSC protocol can be used to COMMAND speech servers to set = up=20 streaming with another server using some type of streaming protocol = (like=20 SIP). Which streaming protocol is used will be determined as = part of=20 the SpeechSC's work.
 
For example, in my attached architecture diagram, the SpeechSC = protocol=20 allows an Application Server commanding an ASR server to set up a = SIP=20 session between the ASR server and a telephony platform (see = attached=20 figure). Note that there is a SpeechSC command/control session = between=20 the Application Server and the ASR Server, but there is no streaming = media=20 going betweeen the Application & ASR Servers. There IS = a=20 standard SIP session between the Speech server and the Telephony = platform,=20 that was set up by commands given in the SpeechSC protocol. This SIP = session=20 does NOT carry any commands other than standard SIP setup/teardown = commands.=20
 
An example of the command/response sequence in a SpeechSC = Command=20 stream would be:
 
Request from Application server to Directory Services for an = ASR=20 server
Reply from Directory Services To Application Server giving info = on=20 specific ASR Server
Command from Application Server to ASR Server to set up a = specific=20 command/ response session for a call (one command session per call=20 context)
Response from ASR Server to Application Server acknowledging = the=20 completion of the session set-up.
Command from Application Server to selected ASR = server to=20 set up SIP session with a specific Telephony Server. The App Server = gives=20 the ASR server the addresses of the Telephony Server so the App = Server can=20 set up the SIP session.
(ASR Server sets up SIP Session to Telephony Server))
Response from ASR Server indicating successful SIP session = setup.
Command from Application Server to ASR Server to set up = grammars and=20 start recognition on ASR Server.
Response from ASR Server to Application Server reporting a = grammar=20 match or timeout from ASR Server.
etc.
 
Again, this is shown in mu attached diagram.
 
Skip Cave
Sr. Principal Engineer
Intervoice Inc.


>>> "Eric Burger" = <eburger@snowshore.com>=20 12/16/02 08:29AM >>>
From a personal perspective, the = MRCP over=20 SIP proposal was what pushed me over the edge to fix MRCP.  I = would be=20 hard pressed to try to convince the IESG that there is a need for = MRCP/RTSP,=20 MRCP/SIP, MRCP/foo, ...  We need to pick the one that makes the = most=20 sense.

-----Original Message-----
From: Jean Philippe = Longeray [mailto:jean-philip= pe.longeray@netcentrex.net]
Sent:=20 Monday, December 16, 2002 3:12 AM
To: Skip Cave; Eric = Burger
Cc:=20 speechsc@ietf.org
Subject: RE: [Speechsc] SPEECHSC vs = 3GPP


Hi=20 Skip,

Nice to have some news from Intervoice...

I = agree.=20 SIP  will never provide  multimedia control = functionnalities, but=20 I'm sure it's a great protocol from transport (and mandatory for = 3G).
WG=20 has to define a couple of protocols, like MRCP/RTSP. What do you = think of=20 SPEECHSC/SIP, which can be very closed from=20 MRCP/SIP.

Regards.


Jean-Philippe LONGERAY =
R&D=20 Director - Service NODE

NetCentrex=20

Jean-philippe.longeray@netcentrex.net
+ 33 4 72 53 61 33 = - + 33 4=20 72 53 61 30
Mobile: + 33 6 76 48 34 95
http://www.netcentrex.net

-= ----Original=20 Message-----
From: Skip Cave [mailto:skip.cave@intervoice.com= ]
Sent:=20 vendredi 13 d=E9cembre 2002 19:38
To:=20 jean-philippe.longeray@netcentrex.net; eburger@snowshore.com
Cc:=20 speechsc@ietf.org
Subject: RE: [Speechsc] SPEECHSC vs=20 3GPP


Jean, Eric,

I don't think SIP will support = the=20 separated media/control requirements I posted earlier. You will need = a=20 control protocol, and a separate media protocol. I expect that it = will take=20 a new protocol to meet these requirements.

Skip Cave
Sr. = Principal=20 Engineer
Intervoice Inc.


>>> "Jean Philippe=20 Longeray" <jean-philippe.longeray@netcentrex.net> 12/13/02 = 01:25AM=20 >>>
Thanks Eric for this analyze,

I agree. H.248 = doesn't=20 seems to be the right answer for MRFC/MRFP, even if
special = packages can=20 be provided.

For my opinion, SIP is the correct answer for = transport=20 layer (since it's
used everywhere in 3GPP and 3GPP2), and = SPEECHSC could=20 (should?) be used for
resource control.

Concerning = SPEECHSC, 3.3=20 "Avoid Duplicating Existing Protocols", I would
like to add some=20 remarks:

In case of you would like to insert a routing = mechanism (a=20 SIP soft-switch)
between Media Processing Entity / Application = server and=20 Resource server
(ASR, SI/SV, TTS, Announcement server), I could = be=20 interesting to have a
single transport protocol, like SIP, = instead of=20 several incompatible
protocols (RTSP for example) for the closes=20 functionalities. I think it is
easier to add some redundancy, = rather than=20 conserving "old" protocols like
RTSP.

It seems to be very=20 important to make distinctions between each layers = of
model.
Something=20 like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or = SCTP/SIP/SPEECHSC,
could be=20 an answer.



Regards.


Jean-Philippe=20 LONGERAY
R&D Director - Service=20 = NODE

NetCentrex

Jean-philippe.longeray@netcentrex.net
&l= t;mailto:Jean-philipp= e.longeray@netcentrex.net>
+=20 33 4 72 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 = 95
http://www.netcentrex.net

<= BR>
-----Original=20 Message-----
From: Eric Burger [mailto:eburger@snowshore.com]<= BR>Sent:=20 vendredi 13 d=E9cembre 2002 03:13
To: Jean Philippe = Longeray
Cc: IETF=20 SPEECHSC (E-mail)
Subject: RE: [Speechsc] SPEECHSC vs = 3GPP


The=20 Mp interface is (1) not the right concept and (2) is itself (IMHO)=20 not
the correct choice for 3GPP's needs, either.

With = respect to=20 (1), Mp is trying to be an analog to the MGC/MG
decomposition for = a media=20 server, where the MRFC is a "media server
controller" and the = MRFP is a=20 "media server [processor]".  The types of
resources are = bearer=20 packet processors (e.g., tone detection, prompt
playing, and=20 recording).  The protocol is a low-level device = control
protocol=20 (e.g., allocate a resource, allocate a RTP port, connect the = port
to the=20 resource, wait for a signal, etc.).  speechsc is a=20 higher-level
protocol, concerned with things like 'establish = session' and=20 'recognize
speech'.

In fact, early in the days of = MRCP/speechsc,=20 people wanted to extend the
speechsc scope to do device = control. =20 The answer has consistently been to
use H.248 for device=20 control.

With respect to (2), AFAIK, no one has ever built a=20 MRFC.  I believe this is
because unlike a media gateway, = where there=20 are definite decomposition
benefits, there are really few if any = benefits=20 to decomposing the MRF.  In
fact, there are clear benefits = to using=20 the native application interface
(SIP), rather than the native = gateway=20 interface (H.248) for interfacing the
AS and CSCF to the=20 MRF.

-----Original Message-----
From: Jean Philippe = Longeray [mailto:jean-philip= pe.longeray@netcentrex.net]
Sent:=20 Tuesday, December 10, 2002 5:53 AM
To: IETF SPEECHSC = (E-mail)
Subject:=20 [Speechsc] SPEECHSC vs 3GPP


Hi,

Do you ever = compare=20 SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229
Rel5)=20 architecture.

It looks like  SPEECHSC  is very = closed from=20 Mp interface (H.248).

Could SPEECHSC works with 3GPP = (www.3gpp.org) ,=20 3GPP2 (www.3gpp2.org) ,
3G.IP (www.3gip.org),  MWIF=20 (www.mwif.org)?

Regards.

Jean-Philippe = LONGERAY
R&D=20 Director - Service=20 = NODE

NetCentrex

Jean-philippe.longeray@netcentrex.net
+ = 33=20 4 72 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 = 95
http://www.netcentrex.net

_= ______________________________________________
Speechsc=20 mailing list
Speechsc@ietf.org
https://www1.iet= f.org/mailman/listinfo/speechsc
__________________________________= _____________
Speechsc=20 mailing list
Speechsc@ietf.org
https://www1.iet= f.org/mailman/listinfo/speechsc
------=_NextPart_000_016E_01C2A5B1.33E49CD0-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 05:07:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10651 for ; Tue, 17 Dec 2002 05:07:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHA9kl00556 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 05:09:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHA9kv00553 for ; Tue, 17 Dec 2002 05:09:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10634 for ; Tue, 17 Dec 2002 05:06:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHA9Yv00540; Tue, 17 Dec 2002 05:09:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHA8Av00498 for ; Tue, 17 Dec 2002 05:08:10 -0500 Received: from slap.mg2-lyon.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10623 for ; Tue, 17 Dec 2002 05:05:07 -0500 (EST) Received: from jpl (jpl.mg2-lyon.fr [132.147.160.27]) by slap.mg2-lyon.fr (Postfix) with SMTP id 6ECE010EFD; Tue, 17 Dec 2002 11:54:35 +0100 (CET) From: "Jean Philippe Longeray" To: , "'Skip Cave'" , Cc: Subject: RE: [Speechsc] SPEECHSC vs 3GPP Date: Tue, 17 Dec 2002 11:00:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01C2A5BB.7B6D6730" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <016d01c2a5a8$d22034d0$8300010a@hq.eloquant.com> Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0061_01C2A5BB.7B6D6730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Brian, Living in France, I'm very attached to the OSI model defined by ITU-T. I think it is really important to make some distinctions between transportation and application protocol. SIP is little bit poor for data transportation, but it exists and clearly chosen by 3GPP and 3GPP2. For my opinion , SPEECHSC could be something very closed from MRCP and transported by SIP INFO method. Speechsc, like MRCP must only define the media control part and the way how it can be transported by SIP (and optionally by others protocols like H.225.0, RTSP, H.248, ...) All media resources could be controlled by the same protocol (SPEECHSC). At the streaming side, RTP/RTCP is ouf course engaged. I'm sure that a MutliMedia VOIP core with optional peripheral gateways is the Next Gen architecture for Telephony. An extension of MRCP could be the answer. It is a great protocol, isn't it? And It already works over RTSP (Nuance, Speechworks, Telisma...) Find bellow some extension of MRCP, SPEECHSC could cover: - speaker verification, - speaker identification, - announcement, voice recording, - tones detection, tones generation, - fax, - audio conferencing, - video conferencing, - chat SPEECHSC could be a Multimedia protocol, not only for Speech but also for Video, Data, FAX ....3G! Best regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Brian Wyld [mailto:brian.wyld@eloquant.com] Sent: mardi 17 décembre 2002 09:47 To: 'Jean Philippe Longeray'; 'Skip Cave'; speechsc@ietf.org Cc: eburger@snowshore.com Subject: RE: [Speechsc] SPEECHSC vs 3GPP Messieurs Some interesting discussion here - to ease the job of the protocol eval doc editor :-) perhaps someone would like to do a protocol analysis section for 3GPP H.248 (maybe just to rule it out?) - Jean-Philippe perhaps? My 2c on the SPEECHSC/whatever - I think there is a first question to resolve in my mind Q1: what is the best model for SPEECHSC: - a layer OVER a media signalling protocol (SIP, RTSP, etc, depending on this lower layer for media and session control, just like MRCP/RTSP currently does) -> in which case what is the encapsulation mechanism - RTSP has ANNOUNCE messages, what does SIP provide for this sort of bundling? -> and what is the "best" protocol to layer over - an extension to an existing media signalling protocol (eg, add MRCP "verbs" as new ones in RTSP, or add as new SIP commands...) - a new protocol incorporating both media signalling, session control and resource control (eg Web services extensions) As for the identification and resolution of resource servers, this is for me a separate functionality to SPEECHSC itself, and there are already multiple mechanisms existing (SLP, UDDI, etc) for service location and discovery. Brian -----Message d'origine----- De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la part de Jean Philippe Longeray Envoyé : Tuesday, December 17, 2002 08:33 À : Skip Cave; speechsc@ietf.org Cc : eburger@snowshore.com Objet : RE: [Speechsc] SPEECHSC vs 3GPP Hi skip, You're right, I didn't say something different. Like MRCP, SPEECHSC is a media command protocol. SIP is not only a streaming protocol, It can be used as a transport protocol, like HTTP, X.224, ... If SIP transports SDP, it becomes a streaming protocol, but what don't you thing it's not possible to transport SPEECHSC messages in SIP Content. In your document, something is missing: You need something to find an Resource Server (ASR, SVI, TTS), and I propose to use SIP softswitching, This softswitch could be inserted between your Application Execution Server and all others voice resource (It could be ASR, TTS, SVI, but also Audio/Video streaming, conferencing, ....) I think that draft-robinson-mrcp-sip-00 is a great example that I want to say. Do you agree Eric? Best regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: lundi 16 décembre 2002 20:47 To: speechsc@ietf.org Cc: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Subject: RE: [Speechsc] SPEECHSC vs 3GPP Eric, Jean, It's good that we agree. I believe that there has been some confusion in the past that SpeechSC is a media streaming protocol. We need to list the basic issues to make sure that we clear up that misconception: 1) SpeechSC is NOT a media streaming protocol. 2) The SpeechSC protocol is strictly a command/response protocol, carrying commands and returning responses from application servers to speech servers. The SpeechSC protocol will never be a media transport protocol, and will never carry any type of media. 3) Even though the SpeechSC protocol is not a media transport protocol, the SpeechSC protocol can be used to COMMAND speech servers to set up streaming with another server using some type of streaming protocol (like SIP). Which streaming protocol is used will be determined as part of the SpeechSC's work. For example, in my attached architecture diagram, the SpeechSC protocol allows an Application Server commanding an ASR server to set up a SIP session between the ASR server and a telephony platform (see attached figure). Note that there is a SpeechSC command/control session between the Application Server and the ASR Server, but there is no streaming media going betweeen the Application & ASR Servers. There IS a standard SIP session between the Speech server and the Telephony platform, that was set up by commands given in the SpeechSC protocol. This SIP session does NOT carry any commands other than standard SIP setup/teardown commands. An example of the command/response sequence in a SpeechSC Command stream would be: Request from Application server to Directory Services for an ASR server Reply from Directory Services To Application Server giving info on specific ASR Server Command from Application Server to ASR Server to set up a specific command/ response session for a call (one command session per call context) Response from ASR Server to Application Server acknowledging the completion of the session set-up. Command from Application Server to selected ASR server to set up SIP session with a specific Telephony Server. The App Server gives the ASR server the addresses of the Telephony Server so the App Server can set up the SIP session. (ASR Server sets up SIP Session to Telephony Server)) Response from ASR Server indicating successful SIP session setup. Command from Application Server to ASR Server to set up grammars and start recognition on ASR Server. Response from ASR Server to Application Server reporting a grammar match or timeout from ASR Server. etc. Again, this is shown in mu attached diagram. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Eric Burger" 12/16/02 08:29AM >>> From a personal perspective, the MRCP over SIP proposal was what pushed me over the edge to fix MRCP. I would be hard pressed to try to convince the IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, ... We need to pick the one that makes the most sense. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Monday, December 16, 2002 3:12 AM To: Skip Cave; Eric Burger Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Hi Skip, Nice to have some news from Intervoice... I agree. SIP will never provide multimedia control functionnalities, but I'm sure it's a great protocol from transport (and mandatory for 3G). WG has to define a couple of protocols, like MRCP/RTSP. What do you think of SPEECHSC/SIP, which can be very closed from MRCP/SIP. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: vendredi 13 décembre 2002 19:38 To: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Jean, Eric, I don't think SIP will support the separated media/control requirements I posted earlier. You will need a control protocol, and a separate media protocol. I expect that it will take a new protocol to meet these requirements. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Jean Philippe Longeray" 12/13/02 01:25AM >>> Thanks Eric for this analyze, I agree. H.248 doesn't seems to be the right answer for MRFC/MRFP, even if special packages can be provided. For my opinion, SIP is the correct answer for transport layer (since it's used everywhere in 3GPP and 3GPP2), and SPEECHSC could (should?) be used for resource control. Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing Protocols", I would like to add some remarks: In case of you would like to insert a routing mechanism (a SIP soft-switch) between Media Processing Entity / Application server and Resource server (ASR, SI/SV, TTS, Announcement server), I could be interesting to have a single transport protocol, like SIP, instead of several incompatible protocols (RTSP for example) for the closes functionalities. I think it is easier to add some redundancy, rather than conserving "old" protocols like RTSP. It seems to be very important to make distinctions between each layers of model. Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC, could be an answer. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: vendredi 13 décembre 2002 03:13 To: Jean Philippe Longeray Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] SPEECHSC vs 3GPP The Mp interface is (1) not the right concept and (2) is itself (IMHO) not the correct choice for 3GPP's needs, either. With respect to (1), Mp is trying to be an analog to the MGC/MG decomposition for a media server, where the MRFC is a "media server controller" and the MRFP is a "media server [processor]". The types of resources are bearer packet processors (e.g., tone detection, prompt playing, and recording). The protocol is a low-level device control protocol (e.g., allocate a resource, allocate a RTP port, connect the port to the resource, wait for a signal, etc.). speechsc is a higher-level protocol, concerned with things like 'establish session' and 'recognize speech'. In fact, early in the days of MRCP/speechsc, people wanted to extend the speechsc scope to do device control. The answer has consistently been to use H.248 for device control. With respect to (2), AFAIK, no one has ever built a MRFC. I believe this is because unlike a media gateway, where there are definite decomposition benefits, there are really few if any benefits to decomposing the MRF. In fact, there are clear benefits to using the native application interface (SIP), rather than the native gateway interface (H.248) for interfacing the AS and CSCF to the MRF. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 10, 2002 5:53 AM To: IETF SPEECHSC (E-mail) Subject: [Speechsc] SPEECHSC vs 3GPP Hi, Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229 Rel5) architecture. It looks like SPEECHSC is very closed from Mp interface (H.248). Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------=_NextPart_000_0061_01C2A5BB.7B6D6730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Brian,
 
Living in France, = I'm very=20 attached to the OSI model defined by ITU-T.
 
I think it is = really important=20 to make some distinctions between transportation and application=20 protocol.
SIP is little bit = poor for data=20 transportation, but it exists and clearly chosen by 3GPP and=20 3GPP2.
 
For my opinion = ,  SPEECHSC=20 could be something very closed from MRCP and transported by = SIP  INFO=20 method.
Speechsc, = like MRCP must=20 only define the media control part and the way how it can be = transported by=20 SIP (and optionally by others protocols like H.225.0, RTSP, H.248,=20 ...)
 
All media resources = could be=20 controlled by the same protocol (SPEECHSC). At the streaming side, = RTP/RTCP is=20 ouf course engaged. I'm sure that a MutliMedia VOIP core with optional=20 peripheral gateways is the Next Gen architecture for=20 Telephony.
 
An extension of = MRCP could be=20 the answer. It is a great protocol, isn't it? And It already works over = RTSP=20 (Nuance, Speechworks, Telisma...)
 
Find bellow some = extension of=20 MRCP,  SPEECHSC could cover:
- speaker=20 verification,
- speaker=20 identification,
- announcement, = voice=20 recording,
- tones detection, = tones=20 generation,
- = fax,
- audio=20 conferencing,
- video=20 conferencing,
- = chat
 
 
SPEECHSC could be a = Multimedia=20 protocol, not only for Speech but also for Video, Data, FAX=20 ....3G!
 
 
Best=20 regards.
 
 
 
 
Jean-Philippe=20 LONGERAY 
R&D = Director - Service=20 NODE
 
NetCentrex 
 
Jean-philippe.longe= ray@netcentrex.net
+ 33 4 72 53 61 = 33 - + 33 4=20 72 53 61 30
Mobile: + 33 6 = 76 48 34=20 95
http://www.netcentrex.net<= /DIV>
 
-----Original Message-----
From: Brian Wyld=20 [mailto:brian.wyld@eloquant.com]
Sent: mardi 17 d=E9cembre = 2002=20 09:47
To: 'Jean Philippe Longeray'; 'Skip Cave';=20 speechsc@ietf.org
Cc: = eburger@snowshore.com
Subject: RE:=20 [Speechsc] SPEECHSC vs 3GPP

Messieurs
 
Some interesting = discussion=20 here - to ease the job of the protocol eval doc editor :-) perhaps = someone=20 would like to do a protocol analysis section for 3GPP H.248 (maybe = just to=20 rule it out?) - Jean-Philippe perhaps?
 
My 2c on the=20 SPEECHSC/whatever - I think there is a first question to resolve in my = mind=20
 Q1: what is the best = model for=20 SPEECHSC:
 - a = layer OVER a=20 media signalling protocol (SIP, RTSP, etc, depending on this lower = layer for=20 media and session control, just like MRCP/RTSP currently=20 does)
    -> in=20 which case what is the encapsulation mechanism - RTSP has ANNOUNCE = messages,=20 what does SIP provide for this sort of bundling?
    ->=20 and what is the "best" protocol to layer over
 - an = extension to an=20 existing media signalling protocol (eg, add MRCP "verbs" as new ones = in RTSP,=20 or add as new SIP commands...)
 - a new = protocol=20 incorporating both media signalling, session control and resource = control (eg=20 Web services extensions)
 
As for the = identification and=20 resolution of resource servers, this is for me a separate = functionality to=20 SPEECHSC itself, and there are already multiple mechanisms existing = (SLP,=20 UDDI, etc) for service location and discovery.
 
Brian
-----Message d'origine-----
De :=20 speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la = part de=20 Jean Philippe Longeray
Envoy=E9 : Tuesday, December = 17, 2002=20 08:33
=C0 : Skip Cave; = speechsc@ietf.org
Cc :=20 eburger@snowshore.com
Objet : RE: [Speechsc] SPEECHSC = vs=20 3GPP

Hi=20 skip,
 
You're right, I = didn't say=20 something different.
 
Like MRCP, = SPEECHSC is a=20 media command protocol. SIP is not only a streaming protocol, It can = be used=20 as a transport protocol, like HTTP, X.224, ... If SIP transports = SDP, it=20 becomes a streaming protocol, but what don't you thing it's not = possible to=20 transport SPEECHSC messages in SIP Content.
 
In your = document, something=20 is missing: You=20 need something to find an Resource Server (ASR, SVI, TTS), and I = propose to=20 use SIP softswitching,
This softswitch = could be=20 inserted between your Application Execution Server and all others = voice=20 resource (It could be ASR, TTS, SVI, but also Audio/Video streaming, = conferencing, ....)
 
 
I think=20 that draft-robinson-mrcp-sip-00 is a great example that I want = to say.=20 Do you agree Eric?
 
Best=20 regards.
 
Jean-Philippe=20 LONGERAY 
R&D = Director -=20 Service NODE
 
NetCentrex 
 
Jean-philippe.longe= ray@netcentrex.net
+ 33 4 72 = 53 61 33 - + 33=20 4 72 53 61 30
Mobile: + = 33 6 76 48 34=20 95
http://www.netcentrex.net<= /DIV>
 
-----Original Message-----
From: Skip Cave=20 [mailto:skip.cave@intervoice.com]
Sent: lundi 16 = d=E9cembre 2002=20 20:47
To: speechsc@ietf.org
Cc:=20 jean-philippe.longeray@netcentrex.net;=20 eburger@snowshore.com
Subject: RE: [Speechsc] SPEECHSC = vs=20 3GPP

Eric, Jean,
 
It's good that we agree. I believe that there has been some = confusion=20 in the past that SpeechSC is a media streaming protocol. We need = to list=20 the basic issues to make sure that we clear up that misconception: =
 
1) SpeechSC is NOT a media streaming protocol.
2) The SpeechSC protocol is strictly a command/response = protocol,=20 carrying commands and returning responses from application servers = to=20 speech servers. The SpeechSC protocol will never be a media = transport=20 protocol, and will never carry any type of media.
3) Even though the SpeechSC protocol is not a media transport = protocol, the SpeechSC protocol can be used to COMMAND speech = servers to=20 set up streaming with another server using some type of streaming = protocol=20 (like SIP). Which streaming protocol is used will be = determined as=20 part of the SpeechSC's work.
 
For example, in my attached architecture diagram, the = SpeechSC=20 protocol allows an Application Server commanding an ASR server to = set up a=20 SIP session between the ASR server and a telephony platform (see = attached=20 figure). Note that there is a SpeechSC command/control = session=20 between the Application Server and the ASR Server, but there is no = streaming media going betweeen the Application & ASR=20 Servers. There IS a standard SIP session between the = Speech=20 server and the Telephony platform, that was set up by commands = given in=20 the SpeechSC protocol. This SIP session does NOT carry any = commands other=20 than standard SIP setup/teardown commands.
 
An example of the command/response sequence in a = SpeechSC=20 Command stream would be:
 
Request from Application server to Directory Services for an = ASR=20 server
Reply from Directory Services To Application Server giving = info on=20 specific ASR Server
Command from Application Server to ASR Server to set up a = specific=20 command/ response session for a call (one command session per call = context)
Response from ASR Server to Application Server acknowledging = the=20 completion of the session set-up.
Command from Application Server to selected = ASR server=20 to set up SIP session with a specific Telephony Server. The App = Server=20 gives the ASR server the addresses of the Telephony Server so the = App=20 Server can set up the SIP session.
(ASR Server sets up SIP Session to Telephony Server))
Response from ASR Server indicating successful SIP session=20 setup.
Command from Application Server to ASR Server to set up = grammars and=20 start recognition on ASR Server.
Response from ASR Server to Application Server reporting a = grammar=20 match or timeout from ASR Server.
etc.
 
Again, this is shown in mu attached diagram.
 
Skip Cave
Sr. Principal Engineer
Intervoice Inc.


>>> "Eric Burger" = <eburger@snowshore.com>=20 12/16/02 08:29AM >>>
From a personal perspective, the = MRCP=20 over SIP proposal was what pushed me over the edge to fix = MRCP.  I=20 would be hard pressed to try to convince the IESG that there is a = need for=20 MRCP/RTSP, MRCP/SIP, MRCP/foo, ...  We need to pick the one = that=20 makes the most sense.

-----Original Message-----
From: = Jean=20 Philippe Longeray [mailto:jean-philip= pe.longeray@netcentrex.net]
Sent:=20 Monday, December 16, 2002 3:12 AM
To: Skip Cave; Eric = Burger
Cc:=20 speechsc@ietf.org
Subject: RE: [Speechsc] SPEECHSC vs=20 3GPP


Hi Skip,

Nice to have some news from=20 Intervoice...

I agree. SIP  will never provide =20 multimedia control functionnalities, but I'm sure it's a great = protocol=20 from transport (and mandatory for 3G).
WG has to define a = couple of=20 protocols, like MRCP/RTSP. What do you think of SPEECHSC/SIP, = which can be=20 very closed from = MRCP/SIP.

Regards.


Jean-Philippe=20 LONGERAY
R&D Director - Service NODE

NetCentrex=20

Jean-philippe.longeray@netcentrex.net
+ 33 4 72 53 61 = 33 - + 33=20 4 72 53 61 30
Mobile: + 33 6 76 48 34 95
http://www.netcentrex.net

-= ----Original=20 Message-----
From: Skip Cave [mailto:skip.cave@intervoice.com= ]
Sent:=20 vendredi 13 d=E9cembre 2002 19:38
To:=20 jean-philippe.longeray@netcentrex.net; = eburger@snowshore.com
Cc:=20 speechsc@ietf.org
Subject: RE: [Speechsc] SPEECHSC vs=20 3GPP


Jean, Eric,

I don't think SIP will support = the=20 separated media/control requirements I posted earlier. You will = need a=20 control protocol, and a separate media protocol. I expect that it = will=20 take a new protocol to meet these requirements.

Skip = Cave
Sr.=20 Principal Engineer
Intervoice Inc.


>>> = "Jean=20 Philippe Longeray" <jean-philippe.longeray@netcentrex.net> = 12/13/02=20 01:25AM >>>
Thanks Eric for this analyze,

I = agree.=20 H.248 doesn't seems to be the right answer for MRFC/MRFP, even=20 if
special packages can be provided.

For my opinion, SIP = is the=20 correct answer for transport layer (since it's
used everywhere = in 3GPP=20 and 3GPP2), and SPEECHSC could (should?) be used for
resource=20 control.

Concerning SPEECHSC, 3.3 "Avoid Duplicating = Existing=20 Protocols", I would
like to add some remarks:

In case of = you=20 would like to insert a routing mechanism (a SIP = soft-switch)
between=20 Media Processing Entity / Application server and Resource = server
(ASR,=20 SI/SV, TTS, Announcement server), I could be interesting to have=20 a
single transport protocol, like SIP, instead of several=20 incompatible
protocols (RTSP for example) for the closes=20 functionalities. I think it is
easier to add some redundancy, = rather=20 than conserving "old" protocols like
RTSP.

It seems to = be very=20 important to make distinctions between each layers=20 of
model.
Something like UDP/SIP/SPEECHSC or = TCP/SIP/SPEECHSC or=20 SCTP/SIP/SPEECHSC,
could be an=20 answer.



Regards.


Jean-Philippe=20 LONGERAY
R&D Director - Service=20 = NODE

NetCentrex

Jean-philippe.longeray@netcentrex.net
&l= t;mailto:Jean-philipp= e.longeray@netcentrex.net>
+=20 33 4 72 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 = 95
http://www.netcentrex.net

<= BR>
-----Original=20 Message-----
From: Eric Burger [mailto:eburger@snowshore.com]<= BR>Sent:=20 vendredi 13 d=E9cembre 2002 03:13
To: Jean Philippe = Longeray
Cc: IETF=20 SPEECHSC (E-mail)
Subject: RE: [Speechsc] SPEECHSC vs=20 3GPP


The Mp interface is (1) not the right concept and = (2) is=20 itself (IMHO) not
the correct choice for 3GPP's needs,=20 either.

With respect to (1), Mp is trying to be an analog = to the=20 MGC/MG
decomposition for a media server, where the MRFC is a = "media=20 server
controller" and the MRFP is a "media server = [processor]". =20 The types of
resources are bearer packet processors (e.g., tone = detection, prompt
playing, and recording).  The protocol = is a=20 low-level device control
protocol (e.g., allocate a resource, = allocate=20 a RTP port, connect the port
to the resource, wait for a = signal,=20 etc.).  speechsc is a higher-level
protocol, concerned = with things=20 like 'establish session' and 'recognize
speech'.

In = fact, early=20 in the days of MRCP/speechsc, people wanted to extend = the
speechsc=20 scope to do device control.  The answer has consistently been = to
use H.248 for device control.

With respect to (2), = AFAIK, no=20 one has ever built a MRFC.  I believe this is
because = unlike a=20 media gateway, where there are definite decomposition
benefits, = there=20 are really few if any benefits to decomposing the MRF.  = In
fact,=20 there are clear benefits to using the native application=20 interface
(SIP), rather than the native gateway interface = (H.248) for=20 interfacing the
AS and CSCF to the MRF.

-----Original=20 Message-----
From: Jean Philippe Longeray [mailto:jean-philip= pe.longeray@netcentrex.net]
Sent:=20 Tuesday, December 10, 2002 5:53 AM
To: IETF SPEECHSC=20 (E-mail)
Subject: [Speechsc] SPEECHSC vs = 3GPP


Hi,

Do=20 you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS=20 24.229
Rel5) architecture.

It looks like  = SPEECHSC  is=20 very closed from Mp interface (H.248).

Could SPEECHSC works = with=20 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) ,
3G.IP=20 (www.3gip.org),  MWIF=20 (www.mwif.org)?

Regards.

Jean-Philippe = LONGERAY
R&D=20 Director - Service=20 = NODE

NetCentrex

Jean-philippe.longeray@netcentrex.net
+ = 33 4 72 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 = 95
http://www.netcentrex.net

_= ______________________________________________
Speechsc=20 mailing list
Speechsc@ietf.org
https://www1.iet= f.org/mailman/listinfo/speechsc
__________________________________= _____________
Speechsc=20 mailing list
Speechsc@ietf.org
https://www1.iet= f.org/mailman/listinfo/speechsc
------=_NextPart_000_0061_01C2A5BB.7B6D6730-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 08:03:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13073 for ; Tue, 17 Dec 2002 08:03:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHD6Rj08805 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 08:06:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHD6Rv08802 for ; Tue, 17 Dec 2002 08:06:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13028 for ; Tue, 17 Dec 2002 08:03:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHD6Hv08787; Tue, 17 Dec 2002 08:06:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHCdov08063 for ; Tue, 17 Dec 2002 07:39:50 -0500 Received: from bbnmg1.net.external.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12703 for ; Tue, 17 Dec 2002 07:36:44 -0500 (EST) Received: from garonne.grenoble.hp.com (garonne.grenoble.hp.com [15.128.14.138]) by bbnmg1.net.external.hp.com (Postfix) with ESMTP id D55CD1E2 for ; Tue, 17 Dec 2002 13:39:41 +0100 (MET) Received: by garonne.grenoble.hp.com with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Dec 2002 13:39:39 +0100 Message-ID: <468579AFDE99E74DB926952FCDE3D657064BB0CF@dumas.grenoble.hp.com> From: "BRANDT,MARC (HP-France,ex2)" To: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Date: Tue, 17 Dec 2002 13:39:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A5C9.5AD40890" Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2A5C9.5AD40890 Content-Type: text/plain; charset="iso-8859-1" some comments on this thread, (sorry if I inject ideas already discussed in previous meetings, was not obvious on the mailings). I agree with the decomposition or unbundling model. Although there is no needs to support a multitude of protocol stacks profiles (aka speechsc over everything), I believe speechsc needs to enable some separation in terms of protocol layers and service interfaces (this is also a personal good learning of previous model like OSI, TCP/IP... which are somewhat widely adopted in the SIP, HTTP, SOAP and other work as well). Separation of Control pipe and media pipe is also at the heart of modern telecoms. I suspect in addition to the command/response protocol model for speechsc, there needs to be an event based model as well (like a pub/sub). Typically to support the detection of resources, or for better efficiency in terms of media resource processing (modern programming has always shown interest for poll as well as asynchronous models). I also noticed one point in the discussion that is important, regarding the extensions and openness to support evolutions of the resource control semantic. Speechsc would benefit by not relying on new specifications to be created each time a new resource control feature is available, this is imo well covered in the speechsc requirements. But going further and leaving this knowledge at the application level would really enable speechsc to become a framework for supporting disparate media resource control semantic with not much protocol changes. Additionally 'pay load' or 'specific resource profiles' could be described anytime a new one is added as standards extensions (e.g. like the model for RTP pay loads...). This also leaves the room to application specific extensions and differentiations while not violating standards. Enabling a 'programmable' approach when new media resources are created / described and used by app servers. An application may need to invoke a brand new control function without having to rewrite the speechsc protocol layer. Regarding that I tend to consider that adding verbs to the protocol might be more a specification burden than using a descriptive means which can be evolved. At the price of efficiency maybe. So I can agree that some verbs could be put at the core of the protocol (like we have for HTTP, SIP and so on), and the rest more as a semantic pay load (which can be standardized as well, see the XML payloads by OASIS). For instance if I want to build a speech resource that translates streams from voice to voice, will I need other verbs ? a new protocol ? Or if I build a resource that combines functions and so on. This is where we might think of proposing a framework with a way to create optimized interactions. This is already done in some protocols where for instance you can use abbreviated fields, or encoded fields instead of full XML stuff. Or by analogy when using a framework for interpreting languages or compiling languages. But the protocol shall certainly not be a hack just to support efficiency (one can also bet on Moore's law). I also agree with the point on multitude of possible multimedia resources that will have to be controlled by an application. This was initially discussed at the req phase if I remember well. With an output that initial focus of the 1st delivery of speechsc shall be limited in order to avoid the full-picture syndrome and no protocol at the end (and there is SPEECH in speechsc). I believe that other IETF groups are also holding worthwhile discussions on this domain. For instance, I would like to understand the opinions of the group on the mmusic status from last IETF: what about: XML Schema for Media Control in the mmusic minutes http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg01105.htm l draft-levin-mmusic-xml-media-control-00.txt http://www.ietf.org/internet-drafts/draft-levin-mmusic-xml-media-control-00. txt Of course each time we broaden the scope we ease programmable approaches and thus wide developers adoption, but often at the price of efficiency provided by limited scope approaches, really targeted at and tuned for specific resources (and manufacturers ;-). Now in terms of technology I guess there are advantages in the likes of SIP, SOAP, XML (anyway already widely used at the speech grammar or synthesis level in the MRCP packets for instance), with all the extensibility and programmability that they provide. For instance, SIP can be extended, see the SIPPING an SIMPLE work to provide open framework for other semantic to be built on top of it. SOAP clearly provides a good invocation model for a 'programmable' framework. One value add of speechsc could then be to keep this programmability and openness while delivering efficiency in the targeted application profiles (optimizing connections set up, traffic, reuse of media paths and so on ...), e.g. providing new verbs for these kind of core functions while using descriptive services for upper application/media resources functions. Refer to speechsc reqs: Re-use of transport connections across sessions, Piggybacking of responses on requests in the reverse direction, Caching of state across requests ... these are functions that deserve standard treatment across a whole bunch of resources (core protocol). Speechsc would then be completely independent of media resource semantic, and only aware of the semantic of 'controlling' such resources for the best application experience. A TTS resource would be speechsc compliant of the class TTS with such and such features defined in the programmable layer pay load (+ room for vendor extensions). One SIze protocol does not fit all layers. Marc Brandt - mailto:Marc.Brandt@hp.com Hewlett-Packard - OpenCall Business Unit 5, av. r. chanas - eybens - 38053 grenoble cedex 9 - france tel : +33 4 7614 1088 (hp 779-1088) fax : +33 4 7614 4323 (hp 779-4323) https://ecardfile.com/id/Marc+Brandt http://www.hp.com/communications/opencall/ -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 17, 2002 11:00 AM To: brian.wyld@eloquant.com; 'Skip Cave'; speechsc@ietf.org Cc: eburger@snowshore.com Subject: RE: [Speechsc] SPEECHSC vs 3GPP Brian, Living in France, I'm very attached to the OSI model defined by ITU-T. I think it is really important to make some distinctions between transportation and application protocol. SIP is little bit poor for data transportation, but it exists and clearly chosen by 3GPP and 3GPP2. For my opinion , SPEECHSC could be something very closed from MRCP and transported by SIP INFO method. Speechsc, like MRCP must only define the media control part and the way how it can be transported by SIP (and optionally by others protocols like H.225.0, RTSP, H.248, ...) All media resources could be controlled by the same protocol (SPEECHSC). At the streaming side, RTP/RTCP is ouf course engaged. I'm sure that a MutliMedia VOIP core with optional peripheral gateways is the Next Gen architecture for Telephony. An extension of MRCP could be the answer. It is a great protocol, isn't it? And It already works over RTSP (Nuance, Speechworks, Telisma...) Find bellow some extension of MRCP, SPEECHSC could cover: - speaker verification, - speaker identification, - announcement, voice recording, - tones detection, tones generation, - fax, - audio conferencing, - video conferencing, - chat SPEECHSC could be a Multimedia protocol, not only for Speech but also for Video, Data, FAX ....3G! Best regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Brian Wyld [mailto:brian.wyld@eloquant.com] Sent: mardi 17 décembre 2002 09:47 To: 'Jean Philippe Longeray'; 'Skip Cave'; speechsc@ietf.org Cc: eburger@snowshore.com Subject: RE: [Speechsc] SPEECHSC vs 3GPP Messieurs Some interesting discussion here - to ease the job of the protocol eval doc editor :-) perhaps someone would like to do a protocol analysis section for 3GPP H.248 (maybe just to rule it out?) - Jean-Philippe perhaps? My 2c on the SPEECHSC/whatever - I think there is a first question to resolve in my mind Q1: what is the best model for SPEECHSC: - a layer OVER a media signalling protocol (SIP, RTSP, etc, depending on this lower layer for media and session control, just like MRCP/RTSP currently does) -> in which case what is the encapsulation mechanism - RTSP has ANNOUNCE messages, what does SIP provide for this sort of bundling? -> and what is the "best" protocol to layer over - an extension to an existing media signalling protocol (eg, add MRCP "verbs" as new ones in RTSP, or add as new SIP commands...) - a new protocol incorporating both media signalling, session control and resource control (eg Web services extensions) As for the identification and resolution of resource servers, this is for me a separate functionality to SPEECHSC itself, and there are already multiple mechanisms existing (SLP, UDDI, etc) for service location and discovery. Brian -----Message d'origine----- De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la part de Jean Philippe Longeray Envoyé : Tuesday, December 17, 2002 08:33 À : Skip Cave; speechsc@ietf.org Cc : eburger@snowshore.com Objet : RE: [Speechsc] SPEECHSC vs 3GPP Hi skip, You're right, I didn't say something different. Like MRCP, SPEECHSC is a media command protocol. SIP is not only a streaming protocol, It can be used as a transport protocol, like HTTP, X.224, ... If SIP transports SDP, it becomes a streaming protocol, but what don't you thing it's not possible to transport SPEECHSC messages in SIP Content. In your document, something is missing: You need something to find an Resource Server (ASR, SVI, TTS), and I propose to use SIP softswitching, This softswitch could be inserted between your Application Execution Server and all others voice resource (It could be ASR, TTS, SVI, but also Audio/Video streaming, conferencing, ....) I think that draft-robinson-mrcp-sip-00 is a great example that I want to say. Do you agree Eric? Best regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: lundi 16 décembre 2002 20:47 To: speechsc@ietf.org Cc: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Subject: RE: [Speechsc] SPEECHSC vs 3GPP Eric, Jean, It's good that we agree. I believe that there has been some confusion in the past that SpeechSC is a media streaming protocol. We need to list the basic issues to make sure that we clear up that misconception: 1) SpeechSC is NOT a media streaming protocol. 2) The SpeechSC protocol is strictly a command/response protocol, carrying commands and returning responses from application servers to speech servers. The SpeechSC protocol will never be a media transport protocol, and will never carry any type of media. 3) Even though the SpeechSC protocol is not a media transport protocol, the SpeechSC protocol can be used to COMMAND speech servers to set up streaming with another server using some type of streaming protocol (like SIP). Which streaming protocol is used will be determined as part of the SpeechSC's work. For example, in my attached architecture diagram, the SpeechSC protocol allows an Application Server commanding an ASR server to set up a SIP session between the ASR server and a telephony platform (see attached figure). Note that there is a SpeechSC command/control session between the Application Server and the ASR Server, but there is no streaming media going betweeen the Application & ASR Servers. There IS a standard SIP session between the Speech server and the Telephony platform, that was set up by commands given in the SpeechSC protocol. This SIP session does NOT carry any commands other than standard SIP setup/teardown commands. An example of the command/response sequence in a SpeechSC Command stream would be: Request from Application server to Directory Services for an ASR server Reply from Directory Services To Application Server giving info on specific ASR Server Command from Application Server to ASR Server to set up a specific command/ response session for a call (one command session per call context) Response from ASR Server to Application Server acknowledging the completion of the session set-up. Command from Application Server to selected ASR server to set up SIP session with a specific Telephony Server. The App Server gives the ASR server the addresses of the Telephony Server so the App Server can set up the SIP session. (ASR Server sets up SIP Session to Telephony Server)) Response from ASR Server indicating successful SIP session setup. Command from Application Server to ASR Server to set up grammars and start recognition on ASR Server. Response from ASR Server to Application Server reporting a grammar match or timeout from ASR Server. etc. Again, this is shown in mu attached diagram. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Eric Burger" 12/16/02 08:29AM >>> From a personal perspective, the MRCP over SIP proposal was what pushed me over the edge to fix MRCP. I would be hard pressed to try to convince the IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, ... We need to pick the one that makes the most sense. -----Original Message----- From: Jean Philippe Longeray [ mailto:jean-philippe.longeray@netcentrex.net] Sent: Monday, December 16, 2002 3:12 AM To: Skip Cave; Eric Burger Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Hi Skip, Nice to have some news from Intervoice... I agree. SIP will never provide multimedia control functionnalities, but I'm sure it's a great protocol from transport (and mandatory for 3G). WG has to define a couple of protocols, like MRCP/RTSP. What do you think of SPEECHSC/SIP, which can be very closed from MRCP/SIP. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [ mailto:skip.cave@intervoice.com] Sent: vendredi 13 décembre 2002 19:38 To: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Jean, Eric, I don't think SIP will support the separated media/control requirements I posted earlier. You will need a control protocol, and a separate media protocol. I expect that it will take a new protocol to meet these requirements. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Jean Philippe Longeray" 12/13/02 01:25AM >>> Thanks Eric for this analyze, I agree. H.248 doesn't seems to be the right answer for MRFC/MRFP, even if special packages can be provided. For my opinion, SIP is the correct answer for transport layer (since it's used everywhere in 3GPP and 3GPP2), and SPEECHSC could (should?) be used for resource control. Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing Protocols", I would like to add some remarks: In case of you would like to insert a routing mechanism (a SIP soft-switch) between Media Processing Entity / Application server and Resource server (ASR, SI/SV, TTS, Announcement server), I could be interesting to have a single transport protocol, like SIP, instead of several incompatible protocols (RTSP for example) for the closes functionalities. I think it is easier to add some redundancy, rather than conserving "old" protocols like RTSP. It seems to be very important to make distinctions between each layers of model. Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC, could be an answer. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net < mailto:Jean-philippe.longeray@netcentrex.net > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Eric Burger [ mailto:eburger@snowshore.com] Sent: vendredi 13 décembre 2002 03:13 To: Jean Philippe Longeray Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] SPEECHSC vs 3GPP The Mp interface is (1) not the right concept and (2) is itself (IMHO) not the correct choice for 3GPP's needs, either. With respect to (1), Mp is trying to be an analog to the MGC/MG decomposition for a media server, where the MRFC is a "media server controller" and the MRFP is a "media server [processor]". The types of resources are bearer packet processors (e.g., tone detection, prompt playing, and recording). The protocol is a low-level device control protocol (e.g., allocate a resource, allocate a RTP port, connect the port to the resource, wait for a signal, etc.). speechsc is a higher-level protocol, concerned with things like 'establish session' and 'recognize speech'. In fact, early in the days of MRCP/speechsc, people wanted to extend the speechsc scope to do device control. The answer has consistently been to use H.248 for device control. With respect to (2), AFAIK, no one has ever built a MRFC. I believe this is because unlike a media gateway, where there are definite decomposition benefits, there are really few if any benefits to decomposing the MRF. In fact, there are clear benefits to using the native application interface (SIP), rather than the native gateway interface (H.248) for interfacing the AS and CSCF to the MRF. -----Original Message----- From: Jean Philippe Longeray [ mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 10, 2002 5:53 AM To: IETF SPEECHSC (E-mail) Subject: [Speechsc] SPEECHSC vs 3GPP Hi, Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229 Rel5) architecture. It looks like SPEECHSC is very closed from Mp interface (H.248). Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------_=_NextPart_001_01C2A5C9.5AD40890 Content-Type: text/html; charset="iso-8859-1"
some comments on this thread,
(sorry if I inject ideas already discussed in previous meetings, was not obvious on the mailings).
 
<layers>
 
I agree with the decomposition or unbundling model.
Although there is no needs to support a  multitude of protocol stacks profiles (aka speechsc over everything),  I believe speechsc needs to enable some separation in terms of protocol  layers and service interfaces (this is also a personal good learning of previous model  like OSI, TCP/IP... which are somewhat widely adopted in the SIP, HTTP,  SOAP and other work as well).
Separation of Control pipe and media pipe is also at the heart of modern telecoms.
 
<command semantic>
 
I suspect in addition to the command/response protocol model for speechsc, there needs to be an event based model as well (like a pub/sub).
Typically to support the detection of resources, or for better efficiency in terms of media resource processing (modern programming has always shown interest for poll as well as asynchronous models).
 
<extensions>
 
I also noticed one point in the discussion that is important, regarding the extensions and openness to support evolutions of the resource control semantic. Speechsc would benefit by not relying on new specifications to be created each time a new resource control feature is available, this is imo well covered in the speechsc requirements.
 
But going further and leaving this knowledge at the application level would really enable speechsc to  become a framework for supporting disparate media resource control semantic with not much protocol changes. Additionally 'pay load' or 'specific resource profiles' could be described anytime a new one is added as standards extensions (e.g. like the model for RTP pay loads...).
 
This also leaves the room to application specific extensions and differentiations while not violating standards. Enabling a 'programmable' approach when new media resources are created / described and used by app servers.
An application may need to invoke a brand new control function without having to rewrite the speechsc protocol layer.
 
Regarding that I tend to consider that adding verbs to the protocol might be more a specification burden than using a descriptive means which can be evolved. At the price of efficiency maybe. So I can agree that some verbs could be put at the core of the protocol (like we have for HTTP, SIP and so on), and the rest more as a semantic pay load (which can be standardized as well, see the XML payloads by OASIS).
 
For instance if I want to build a speech resource that translates streams from voice to voice, will I need other verbs ? a new protocol ? Or if I build a resource that combines functions and so on.
 
<efficient>
 
This is where we might think of proposing a framework with a way to create optimized interactions. This is already done in some protocols where for instance you can use abbreviated fields, or encoded fields instead of full XML stuff. Or by analogy when using a framework for interpreting languages or compiling languages. But the protocol shall certainly not be a hack just  to support efficiency (one can also bet on Moore's law).
 
<media resources scope>
 
I also agree with the point on multitude of possible multimedia resources that will have to be controlled by an application. This was  initially discussed at the req phase if I remember well.  With an output that initial focus of the 1st delivery of speechsc shall be limited in order to avoid the full-picture syndrome and no protocol at the end (and there is SPEECH in speechsc).  I believe that other IETF groups are also holding worthwhile  discussions on this domain.
 
For instance, I would like to understand the opinions of the group on the mmusic status from last IETF:
what about: XML Schema for Media Control in the mmusic minutes
 
draft-levin-mmusic-xml-media-control-00.txt
 
Of course each time we broaden the scope we ease programmable approaches and thus wide developers adoption, but often at the price of efficiency provided by limited scope approaches, really targeted at and tuned for specific resources (and manufacturers ;-).
 
<underlying techno candidates>
 
Now in terms of technology I guess there are advantages in the likes of SIP, SOAP, XML (anyway already widely used at the speech grammar or synthesis level in the MRCP packets for instance), with all the extensibility  and programmability that they provide.
For instance, SIP can be extended, see the SIPPING an SIMPLE work to provide open framework for other semantic to be built on top of it. SOAP clearly provides a good invocation model for a 'programmable' framework.
 
<finally>
 
One value add of speechsc could then be to keep this programmability and openness while delivering efficiency in the targeted application profiles (optimizing connections set up, traffic, reuse of media paths and so on ...), e.g. providing new verbs for these kind of core functions while using descriptive services for upper application/media resources functions.
Refer to speechsc reqs: Re-use of transport connections across sessions, Piggybacking of responses on requests in the reverse direction, Caching of  state across requests ... these are functions that deserve standard treatment across a whole bunch of resources (core protocol).
 
Speechsc would then be completely independent of media resource semantic, and only aware of the semantic of 'controlling' such resources for the best application experience. A TTS resource would be speechsc compliant of the class TTS with such and such features defined in the programmable layer pay load (+ room for vendor extensions).
 
One SIze protocol does not fit all layers.
 

Marc Brandt      - mailto:Marc.Brandt@hp.com
Hewlett-Packard  - OpenCall Business Unit
5, av. r. chanas - eybens - 38053 grenoble cedex 9 - france
tel  : +33  4 7614 1088 (hp 779-1088)
fax : +33  4 7614 4323 (hp 779-4323)
https://ecardfile.com/id/Marc+Brandt
http://www.hp.com/communications/opencall/

-----Original Message-----
From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net]
Sent: Tuesday, December 17, 2002 11:00 AM
To: brian.wyld@eloquant.com; 'Skip Cave'; speechsc@ietf.org
Cc: eburger@snowshore.com
Subject: RE: [Speechsc] SPEECHSC vs 3GPP

Brian,
 
Living in France, I'm very attached to the OSI model defined by ITU-T.
 
I think it is really important to make some distinctions between transportation and application protocol.
SIP is little bit poor for data transportation, but it exists and clearly chosen by 3GPP and 3GPP2.
 
For my opinion ,  SPEECHSC could be something very closed from MRCP and transported by SIP  INFO method.
Speechsc, like MRCP must only define the media control part and the way how it can be transported by SIP (and optionally by others protocols like H.225.0, RTSP, H.248, ...)
 
All media resources could be controlled by the same protocol (SPEECHSC). At the streaming side, RTP/RTCP is ouf course engaged. I'm sure that a MutliMedia VOIP core with optional peripheral gateways is the Next Gen architecture for Telephony.
 
An extension of MRCP could be the answer. It is a great protocol, isn't it? And It already works over RTSP (Nuance, Speechworks, Telisma...)
 
Find bellow some extension of MRCP,  SPEECHSC could cover:
- speaker verification,
- speaker identification,
- announcement, voice recording,
- tones detection, tones generation,
- fax,
- audio conferencing,
- video conferencing,
- chat
 
 
SPEECHSC could be a Multimedia protocol, not only for Speech but also for Video, Data, FAX ....3G!
 
 
Best regards.
 
 
 
 
Jean-Philippe LONGERAY 
R&D Director - Service NODE
 
NetCentrex 
 
+ 33 4 72 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 95
 
-----Original Message-----
From: Brian Wyld [mailto:brian.wyld@eloquant.com]
Sent: mardi 17 décembre 2002 09:47
To: 'Jean Philippe Longeray'; 'Skip Cave'; speechsc@ietf.org
Cc: eburger@snowshore.com
Subject: RE: [Speechsc] SPEECHSC vs 3GPP

Messieurs
 
Some interesting discussion here - to ease the job of the protocol eval doc editor :-) perhaps someone would like to do a protocol analysis section for 3GPP H.248 (maybe just to rule it out?) - Jean-Philippe perhaps?
 
My 2c on the SPEECHSC/whatever - I think there is a first question to resolve in my mind
 Q1: what is the best model for SPEECHSC:
 - a layer OVER a media signalling protocol (SIP, RTSP, etc, depending on this lower layer for media and session control, just like MRCP/RTSP currently does)
    -> in which case what is the encapsulation mechanism - RTSP has ANNOUNCE messages, what does SIP provide for this sort of bundling?
    -> and what is the "best" protocol to layer over
 - an extension to an existing media signalling protocol (eg, add MRCP "verbs" as new ones in RTSP, or add as new SIP commands...)
 - a new protocol incorporating both media signalling, session control and resource control (eg Web services extensions)
 
As for the identification and resolution of resource servers, this is for me a separate functionality to SPEECHSC itself, and there are already multiple mechanisms existing (SLP, UDDI, etc) for service location and discovery.
 
Brian
-----Message d'origine-----
De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la part de Jean Philippe Longeray
Envoyé : Tuesday, December 17, 2002 08:33
À : Skip Cave; speechsc@ietf.org
Cc : eburger@snowshore.com
Objet : RE: [Speechsc] SPEECHSC vs 3GPP

Hi skip,
 
You're right, I didn't say something different.
 
Like MRCP, SPEECHSC is a media command protocol. SIP is not only a streaming protocol, It can be used as a transport protocol, like HTTP, X.224, ... If SIP transports SDP, it becomes a streaming protocol, but what don't you thing it's not possible to transport SPEECHSC messages in SIP Content.
 
In your document, something is missing: You need something to find an Resource Server (ASR, SVI, TTS), and I propose to use SIP softswitching,
This softswitch could be inserted between your Application Execution Server and all others voice resource (It could be ASR, TTS, SVI, but also Audio/Video streaming, conferencing, ....)
 
 
I think that draft-robinson-mrcp-sip-00 is a great example that I want to say. Do you agree Eric?
 
Best regards.
 
Jean-Philippe LONGERAY 
R&D Director - Service NODE
 
NetCentrex 
 
+ 33 4 72 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 95
 
-----Original Message-----
From: Skip Cave [mailto:skip.cave@intervoice.com]
Sent: lundi 16 décembre 2002 20:47
To: speechsc@ietf.org
Cc: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com
Subject: RE: [Speechsc] SPEECHSC vs 3GPP

Eric, Jean,
 
It's good that we agree. I believe that there has been some confusion in the past that SpeechSC is a media streaming protocol. We need to list the basic issues to make sure that we clear up that misconception:
 
1) SpeechSC is NOT a media streaming protocol.
2) The SpeechSC protocol is strictly a command/response protocol, carrying commands and returning responses from application servers to speech servers. The SpeechSC protocol will never be a media transport protocol, and will never carry any type of media.
3) Even though the SpeechSC protocol is not a media transport protocol, the SpeechSC protocol can be used to COMMAND speech servers to set up streaming with another server using some type of streaming protocol (like SIP). Which streaming protocol is used will be determined as part of the SpeechSC's work.
 
For example, in my attached architecture diagram, the SpeechSC protocol allows an Application Server commanding an ASR server to set up a SIP session between the ASR server and a telephony platform (see attached figure). Note that there is a SpeechSC command/control session between the Application Server and the ASR Server, but there is no streaming media going betweeen the Application & ASR Servers. There IS a standard SIP session between the Speech server and the Telephony platform, that was set up by commands given in the SpeechSC protocol. This SIP session does NOT carry any commands other than standard SIP setup/teardown commands.
 
An example of the command/response sequence in a SpeechSC Command stream would be:
 
Request from Application server to Directory Services for an ASR server
Reply from Directory Services To Application Server giving info on specific ASR Server
Command from Application Server to ASR Server to set up a specific command/ response session for a call (one command session per call context)
Response from ASR Server to Application Server acknowledging the completion of the session set-up.
Command from Application Server to selected ASR server to set up SIP session with a specific Telephony Server. The App Server gives the ASR server the addresses of the Telephony Server so the App Server can set up the SIP session.
(ASR Server sets up SIP Session to Telephony Server))
Response from ASR Server indicating successful SIP session setup.
Command from Application Server to ASR Server to set up grammars and start recognition on ASR Server.
Response from ASR Server to Application Server reporting a grammar match or timeout from ASR Server.
etc.
 
Again, this is shown in mu attached diagram.
 
Skip Cave
Sr. Principal Engineer
Intervoice Inc.


>>> "Eric Burger" <eburger@snowshore.com> 12/16/02 08:29AM >>>
From a personal perspective, the MRCP over SIP proposal was what pushed me over the edge to fix MRCP.  I would be hard pressed to try to convince the IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, ...  We need to pick the one that makes the most sense.

-----Original Message-----
From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net]
Sent: Monday, December 16, 2002 3:12 AM
To: Skip Cave; Eric Burger
Cc: speechsc@ietf.org
Subject: RE: [Speechsc] SPEECHSC vs 3GPP


Hi Skip,

Nice to have some news from Intervoice...

I agree. SIP  will never provide  multimedia control functionnalities, but I'm sure it's a great protocol from transport (and mandatory for 3G).
WG has to define a couple of protocols, like MRCP/RTSP. What do you think of SPEECHSC/SIP, which can be very closed from MRCP/SIP.

Regards.


Jean-Philippe LONGERAY
R&D Director - Service NODE

NetCentrex

Jean-philippe.longeray@netcentrex.net
+ 33 4 72 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 95
http://www.netcentrex.net

-----Original Message-----
From: Skip Cave [mailto:skip.cave@intervoice.com]
Sent: vendredi 13 décembre 2002 19:38
To: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com
Cc: speechsc@ietf.org
Subject: RE: [Speechsc] SPEECHSC vs 3GPP


Jean, Eric,

I don't think SIP will support the separated media/control requirements I posted earlier. You will need a control protocol, and a separate media protocol. I expect that it will take a new protocol to meet these requirements.

Skip Cave
Sr. Principal Engineer
Intervoice Inc.


>>> "Jean Philippe Longeray" <jean-philippe.longeray@netcentrex.net> 12/13/02 01:25AM >>>
Thanks Eric for this analyze,

I agree. H.248 doesn't seems to be the right answer for MRFC/MRFP, even if
special packages can be provided.

For my opinion, SIP is the correct answer for transport layer (since it's
used everywhere in 3GPP and 3GPP2), and SPEECHSC could (should?) be used for
resource control.

Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing Protocols", I would
like to add some remarks:

In case of you would like to insert a routing mechanism (a SIP soft-switch)
between Media Processing Entity / Application server and Resource server
(ASR, SI/SV, TTS, Announcement server), I could be interesting to have a
single transport protocol, like SIP, instead of several incompatible
protocols (RTSP for example) for the closes functionalities. I think it is
easier to add some redundancy, rather than conserving "old" protocols like
RTSP.

It seems to be very important to make distinctions between each layers of
model.
Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC,
could be an answer.



Regards.


Jean-Philippe LONGERAY
R&D Director - Service NODE

NetCentrex

Jean-philippe.longeray@netcentrex.net
<mailto:Jean-philippe.longeray@netcentrex.net>
+ 33 4 72 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 95
http://www.netcentrex.net



-----Original Message-----
From: Eric Burger [mailto:eburger@snowshore.com]
Sent: vendredi 13 décembre 2002 03:13
To: Jean Philippe Longeray
Cc: IETF SPEECHSC (E-mail)
Subject: RE: [Speechsc] SPEECHSC vs 3GPP


The Mp interface is (1) not the right concept and (2) is itself (IMHO) not
the correct choice for 3GPP's needs, either.

With respect to (1), Mp is trying to be an analog to the MGC/MG
decomposition for a media server, where the MRFC is a "media server
controller" and the MRFP is a "media server [processor]".  The types of
resources are bearer packet processors (e.g., tone detection, prompt
playing, and recording).  The protocol is a low-level device control
protocol (e.g., allocate a resource, allocate a RTP port, connect the port
to the resource, wait for a signal, etc.).  speechsc is a higher-level
protocol, concerned with things like 'establish session' and 'recognize
speech'.

In fact, early in the days of MRCP/speechsc, people wanted to extend the
speechsc scope to do device control.  The answer has consistently been to
use H.248 for device control.

With respect to (2), AFAIK, no one has ever built a MRFC.  I believe this is
because unlike a media gateway, where there are definite decomposition
benefits, there are really few if any benefits to decomposing the MRF.  In
fact, there are clear benefits to using the native application interface
(SIP), rather than the native gateway interface (H.248) for interfacing the
AS and CSCF to the MRF.

-----Original Message-----
From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net]
Sent: Tuesday, December 10, 2002 5:53 AM
To: IETF SPEECHSC (E-mail)
Subject: [Speechsc] SPEECHSC vs 3GPP


Hi,

Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229
Rel5) architecture.

It looks like  SPEECHSC  is very closed from Mp interface (H.248).

Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) ,
3G.IP (www.3gip.org),  MWIF (www.mwif.org)?

Regards.

Jean-Philippe LONGERAY
R&D Director - Service NODE

NetCentrex

Jean-philippe.longeray@netcentrex.net
+ 33 4 72 53 61 33 - + 33 4 72 53 61 30
Mobile: + 33 6 76 48 34 95
http://www.netcentrex.net

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc
_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc
------_=_NextPart_001_01C2A5C9.5AD40890-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 10:23:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15527 for ; Tue, 17 Dec 2002 10:23:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHFQ1H16620 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 10:26:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHFQ0v16617 for ; Tue, 17 Dec 2002 10:26:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15514 for ; Tue, 17 Dec 2002 10:22:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHFPqv16606; Tue, 17 Dec 2002 10:25:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHFMGv16508 for ; Tue, 17 Dec 2002 10:22:16 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15466 for ; Tue, 17 Dec 2002 10:19:13 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 17 Dec 2002 10:22:13 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D097615@zoe.office.snowshore.com> Thread-Topic: [Speechsc] SPEECHSC vs 3GPP Thread-Index: AcKln6SLyDwQ60AXQTy8PyOl/Q7vNgAPmIHQ From: "Eric Burger" To: Cc: "Jean Philippe Longeray" , "Skip Cave" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBHFMGv16509 Subject: [Speechsc] speechsc model [was RE: SPEECHSC vs 3GPP] Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit On the use of SIP for MRCP transport: draft-robinson-mrcp-sip-00 is what drove me to realize that the MRCP tunneling approach was broken. That is not to say that it would be wrong to raise MRCP into SIP. However, given the existing semantics for RTSP and TTS, that may be a better way to go. On the other hand, the answer to your question is, "yes": the Robinson draft shows SIP for signaling, not media. On the speechsc model, how does this look: +-------------+ | application |_________ | entity | \ +-------------+ \ : \ speechsc +-------------+ : \---------------| Speech |+ : whatever | Processing ||+ : ---------------| Resource(s) ||| : / RTP +-------------+|| : / +-------------+| +----------+ / +-------------+ | RTP | / | entity |----------- +----------+ The speechsc perspective on the world has really only three logical elements. There is an application entity, which can be (for example ONLY) an application server, a VoiceXML browser, a SALT browser, a Java Bean, a handset, a media server, etc. There is a RTP entity, which is a source of RTP for the speech processing resource, which can be (for example ONLY) a phone, a media gateway, a VoiceXML or SALT browser, etc. Speech processing resources are the ASR, TTS, and SI/SV engines. Note the application entity and RTP entity may be combined, decomposed, or have various bits decomposed and combined. Do we care about rearranging or embellishing these three basic components? I don't think it will materially affect the protocol analysis. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 17, 2002 2:33 AM To: Skip Cave; speechsc@ietf.org Cc: Eric Burger Subject: RE: [Speechsc] SPEECHSC vs 3GPP Hi skip, You're right, I didn't say something different. Like MRCP, SPEECHSC is a media command protocol. SIP is not only a streaming protocol, It can be used as a transport protocol, like HTTP, X.224, ... If SIP transports SDP, it becomes a streaming protocol, but what don't you thing it's not possible to transport SPEECHSC messages in SIP Content. In your document, something is missing: You need something to find an Resource Server (ASR, SVI, TTS), and I propose to use SIP softswitching, This softswitch could be inserted between your Application Execution Server and all others voice resource (It could be ASR, TTS, SVI, but also Audio/Video streaming, conferencing, ....) I think that draft-robinson-mrcp-sip-00 is a great example that I want to say. Do you agree Eric? Best regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: lundi 16 décembre 2002 20:47 To: speechsc@ietf.org Cc: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Subject: RE: [Speechsc] SPEECHSC vs 3GPP Eric, Jean, It's good that we agree. I believe that there has been some confusion in the past that SpeechSC is a media streaming protocol. We need to list the basic issues to make sure that we clear up that misconception: 1) SpeechSC is NOT a media streaming protocol. 2) The SpeechSC protocol is strictly a command/response protocol, carrying commands and returning responses from application servers to speech servers. The SpeechSC protocol will never be a media transport protocol, and will never carry any type of media. 3) Even though the SpeechSC protocol is not a media transport protocol, the SpeechSC protocol can be used to COMMAND speech servers to set up streaming with another server using some type of streaming protocol (like SIP). Which streaming protocol is used will be determined as part of the SpeechSC's work. For example, in my attached architecture diagram, the SpeechSC protocol allows an Application Server commanding an ASR server to set up a SIP session between the ASR server and a telephony platform (see attached figure). Note that there is a SpeechSC command/control session between the Application Server and the ASR Server, but there is no streaming media going betweeen the Application & ASR Servers. There IS a standard SIP session between the Speech server and the Telephony platform, that was set up by commands given in the SpeechSC protocol. This SIP session does NOT carry any commands other than standard SIP setup/teardown commands. An example of the command/response sequence in a SpeechSC Command stream would be: Request from Application server to Directory Services for an ASR server Reply from Directory Services To Application Server giving info on specific ASR Server Command from Application Server to ASR Server to set up a specific command/ response session for a call (one command session per call context) Response from ASR Server to Application Server acknowledging the completion of the session set-up. Command from Application Server to selected ASR server to set up SIP session with a specific Telephony Server. The App Server gives the ASR server the addresses of the Telephony Server so the App Server can set up the SIP session. (ASR Server sets up SIP Session to Telephony Server)) Response from ASR Server indicating successful SIP session setup. Command from Application Server to ASR Server to set up grammars and start recognition on ASR Server. Response from ASR Server to Application Server reporting a grammar match or timeout from ASR Server. etc. Again, this is shown in mu attached diagram. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Eric Burger" 12/16/02 08:29AM >>> From a personal perspective, the MRCP over SIP proposal was what pushed me over the edge to fix MRCP. I would be hard pressed to try to convince the IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, ... We need to pick the one that makes the most sense. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Monday, December 16, 2002 3:12 AM To: Skip Cave; Eric Burger Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Hi Skip, Nice to have some news from Intervoice... I agree. SIP will never provide multimedia control functionnalities, but I'm sure it's a great protocol from transport (and mandatory for 3G). WG has to define a couple of protocols, like MRCP/RTSP. What do you think of SPEECHSC/SIP, which can be very closed from MRCP/SIP. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: vendredi 13 décembre 2002 19:38 To: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Jean, Eric, I don't think SIP will support the separated media/control requirements I posted earlier. You will need a control protocol, and a separate media protocol. I expect that it will take a new protocol to meet these requirements. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Jean Philippe Longeray" 12/13/02 01:25AM >>> Thanks Eric for this analyze, I agree. H.248 doesn't seems to be the right answer for MRFC/MRFP, even if special packages can be provided. For my opinion, SIP is the correct answer for transport layer (since it's used everywhere in 3GPP and 3GPP2), and SPEECHSC could (should?) be used for resource control. Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing Protocols", I would like to add some remarks: In case of you would like to insert a routing mechanism (a SIP soft-switch) between Media Processing Entity / Application server and Resource server (ASR, SI/SV, TTS, Announcement server), I could be interesting to have a single transport protocol, like SIP, instead of several incompatible protocols (RTSP for example) for the closes functionalities. I think it is easier to add some redundancy, rather than conserving "old" protocols like RTSP. It seems to be very important to make distinctions between each layers of model. Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC, could be an answer. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: vendredi 13 décembre 2002 03:13 To: Jean Philippe Longeray Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] SPEECHSC vs 3GPP The Mp interface is (1) not the right concept and (2) is itself (IMHO) not the correct choice for 3GPP's needs, either. With respect to (1), Mp is trying to be an analog to the MGC/MG decomposition for a media server, where the MRFC is a "media server controller" and the MRFP is a "media server [processor]". The types of resources are bearer packet processors (e.g., tone detection, prompt playing, and recording). The protocol is a low-level device control protocol (e.g., allocate a resource, allocate a RTP port, connect the port to the resource, wait for a signal, etc.). speechsc is a higher-level protocol, concerned with things like 'establish session' and 'recognize speech'. In fact, early in the days of MRCP/speechsc, people wanted to extend the speechsc scope to do device control. The answer has consistently been to use H.248 for device control. With respect to (2), AFAIK, no one has ever built a MRFC. I believe this is because unlike a media gateway, where there are definite decomposition benefits, there are really few if any benefits to decomposing the MRF. In fact, there are clear benefits to using the native application interface (SIP), rather than the native gateway interface (H.248) for interfacing the AS and CSCF to the MRF. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 10, 2002 5:53 AM To: IETF SPEECHSC (E-mail) Subject: [Speechsc] SPEECHSC vs 3GPP Hi, Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229 Rel5) architecture. It looks like SPEECHSC is very closed from Mp interface (H.248). Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 10:24:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15551 for ; Tue, 17 Dec 2002 10:24:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHFR6v16665 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 10:27:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHFR6v16662 for ; Tue, 17 Dec 2002 10:27:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15542 for ; Tue, 17 Dec 2002 10:24:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHFR1v16654; Tue, 17 Dec 2002 10:27:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHFQMv16632 for ; Tue, 17 Dec 2002 10:26:22 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15521 for ; Tue, 17 Dec 2002 10:23:18 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Speechsc] SPEECHSC vs 3GPP Date: Tue, 17 Dec 2002 10:26:19 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D097619@zoe.office.snowshore.com> Thread-Topic: [Speechsc] SPEECHSC vs 3GPP Thread-Index: AcKltDR+HiTba6fdTe2KVeEAnDm4EAALDIrw From: "Eric Burger" To: "Jean Philippe Longeray" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBHFQMv16633 Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit The following items are explicitly out of scope. We already have SIP, H.248, and J.162. We don't need yet another protocol to do the same thing. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 17, 2002 5:00 AM [snip] Find bellow some extension of MRCP, SPEECHSC could cover: [snip] - announcement, voice recording, - tones detection, tones generation, - fax, - audio conferencing, - video conferencing, - chat SPEECHSC could be a Multimedia protocol, not only for Speech but also for Video, Data, FAX ....3G! _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 11:02:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16338 for ; Tue, 17 Dec 2002 11:02:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHG4Xv18767 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 11:04:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHG4Xv18764 for ; Tue, 17 Dec 2002 11:04:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16335 for ; Tue, 17 Dec 2002 11:01:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHFw6v18557; Tue, 17 Dec 2002 10:58:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHFvqv18541 for ; Tue, 17 Dec 2002 10:57:52 -0500 Received: from navgw.sandcherry.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16256 for ; Tue, 17 Dec 2002 10:54:50 -0500 (EST) Received: from con-63-117-80-25.rocky.net ([10.20.1.32]) by navgw.sandcherry.com (NAVGW 2.5.2.12) with SMTP id M2002121709170607735 ; Tue, 17 Dec 2002 09:17:06 -0700 Received: by exchange01.sccorp.com with Internet Mail Service (5.5.2656.59) id ; Tue, 17 Dec 2002 08:50:43 -0700 Message-ID: From: Brian Marquette To: "'Eric Burger'" , Jean Philippe Longeray Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Date: Tue, 17 Dec 2002 08:50:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , As some of you know, the MRCP over SIP draft was initiated by SandCherry. Not only did we complete a draft on the subject but implemented the protocol in our product over a year ago. So I would like to offer some real world analysis of how the tunneling of MRCP in SIP: Overview - the basic idea was to use SIP as the session initiation between a media resource client and a media resource server ( TTS, ASR, Prompt, etc). That basic assumption then lets you bring into play SIP location and proxy servers to do efficient and scalable resource location. Then all request, responses and events between client and server were sent as SIP re-invite messages. Pros - the basic benefit that we saw in our implementation was that a virtual connection between client and server was created via SIP. That is to say that a SIP user agent will already map a UAC session to a UAS thread. So all messages flowing between the UAC and UAS will be delivered to the correct object within the user agent. Another benefit is the connection setup between client and server is a 1 step process. Meaning that once the SIP session is established no further discovery or connections need to be made. For example, if you were to use MRCP over TCP then a separate TCP connection would need to be made after the SIP session is established. The state machine on the client side becomes more complex due to more failure scenarios. Cons - the downside we found is that first and foremost a SIP re-invite is a poor choice. It appears to a UA as any other INVITE and therefore can lead to MRCP requests being mistaken as actual session initiation requests. Also, each MRCP request involves a large overhead of INVITE, 200 and ACK. The header information carried by SIP is basically not used for MRCP. It becames obvious to us that the transport of MRCP over SIP using a SIP reinvite was not the right method. So, in conclusion I believe that SIP "could" be used for the transport of MRCP but only by adding a new method type to SIP, such as CONTROL. However, my opinion in using MRCP over the last year or so is that a better approach is using a model of web services. Our experience at SandCherry has shown that TTS and ASR engines have many different features and a static protocol like MRCP will only cover the least common set of features. But, the use of WSDL/SOAP will allow a much better solution. My 2 cents. brian Brian Marquette CTO SandCherry, Inc 720-562-4518 (w) 303-478-0609 (m) 2845 Wilderness Place Boulder, CO 80301 http://www.sandcherry.com -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Tuesday, December 17, 2002 8:26 AM To: Jean Philippe Longeray Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP The following items are explicitly out of scope. We already have SIP, H.248, and J.162. We don't need yet another protocol to do the same thing. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 17, 2002 5:00 AM [snip] Find bellow some extension of MRCP, SPEECHSC could cover: [snip] - announcement, voice recording, - tones detection, tones generation, - fax, - audio conferencing, - video conferencing, - chat SPEECHSC could be a Multimedia protocol, not only for Speech but also for Video, Data, FAX ....3G! _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 12:05:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17743 for ; Tue, 17 Dec 2002 12:05:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHH7ia23297 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 12:07:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHH7iv23294 for ; Tue, 17 Dec 2002 12:07:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17708 for ; Tue, 17 Dec 2002 12:04:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHH7bv23258; Tue, 17 Dec 2002 12:07:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHH6ov22521 for ; Tue, 17 Dec 2002 12:06:50 -0500 Received: from slap.mg2-lyon.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17655 for ; Tue, 17 Dec 2002 12:03:46 -0500 (EST) Received: from jpl (jpl.mg2-lyon.fr [132.147.160.27]) by slap.mg2-lyon.fr (Postfix) with SMTP id C707110EFD; Tue, 17 Dec 2002 18:53:18 +0100 (CET) From: "Jean Philippe Longeray" To: "Eric Burger" , Cc: "Skip Cave" Date: Tue, 17 Dec 2002 17:58:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <4A3384433CE2AB46A63468CB207E209D097615@zoe.office.snowshore.com> Content-Transfer-Encoding: 8bit Subject: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP] Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Thank you eric, 1) What do you think of: +-------------+ | application |_________ | entity | \ +-------------+ +-------------+ : + Soft switch + : +-------------+ \ speechsc +-------------+ : \---------------| Speech |+ : whatever | Processing ||+ : ---------------| Resource(s) ||| : / RTP +-------------+|| : / +-------------+| +----------+ / +-------------+ | RTP | / | entity |----------- +----------+ In this case Soft switch can be used to select the right speech processing resource. 2) As speech processing resources, you think : - ASR - TTS - speaker verif. Do you think we could be able to use also : streaming audio, video, fax (T.38) 3) "Whatever" could be MGCP, or H.248 4) RTP entity could be : - RTP Proxy - RTP conference - RTP duplicator - RTP transcoder Best regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: mardi 17 décembre 2002 16:22 To: speechsc@ietf.org Cc: Jean Philippe Longeray; Skip Cave Subject: speechsc model [was RE: SPEECHSC vs 3GPP] On the use of SIP for MRCP transport: draft-robinson-mrcp-sip-00 is what drove me to realize that the MRCP tunneling approach was broken. That is not to say that it would be wrong to raise MRCP into SIP. However, given the existing semantics for RTSP and TTS, that may be a better way to go. On the other hand, the answer to your question is, "yes": the Robinson draft shows SIP for signaling, not media. On the speechsc model, how does this look: +-------------+ | application |_________ | entity | \ +-------------+ \ : \ speechsc +-------------+ : \---------------| Speech |+ : whatever | Processing ||+ : ---------------| Resource(s) ||| : / RTP +-------------+|| : / +-------------+| +----------+ / +-------------+ | RTP | / | entity |----------- +----------+ The speechsc perspective on the world has really only three logical elements. There is an application entity, which can be (for example ONLY) an application server, a VoiceXML browser, a SALT browser, a Java Bean, a handset, a media server, etc. There is a RTP entity, which is a source of RTP for the speech processing resource, which can be (for example ONLY) a phone, a media gateway, a VoiceXML or SALT browser, etc. Speech processing resources are the ASR, TTS, and SI/SV engines. Note the application entity and RTP entity may be combined, decomposed, or have various bits decomposed and combined. Do we care about rearranging or embellishing these three basic components? I don't think it will materially affect the protocol analysis. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 17, 2002 2:33 AM To: Skip Cave; speechsc@ietf.org Cc: Eric Burger Subject: RE: [Speechsc] SPEECHSC vs 3GPP Hi skip, You're right, I didn't say something different. Like MRCP, SPEECHSC is a media command protocol. SIP is not only a streaming protocol, It can be used as a transport protocol, like HTTP, X.224, ... If SIP transports SDP, it becomes a streaming protocol, but what don't you thing it's not possible to transport SPEECHSC messages in SIP Content. In your document, something is missing: You need something to find an Resource Server (ASR, SVI, TTS), and I propose to use SIP softswitching, This softswitch could be inserted between your Application Execution Server and all others voice resource (It could be ASR, TTS, SVI, but also Audio/Video streaming, conferencing, ....) I think that draft-robinson-mrcp-sip-00 is a great example that I want to say. Do you agree Eric? Best regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: lundi 16 décembre 2002 20:47 To: speechsc@ietf.org Cc: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Subject: RE: [Speechsc] SPEECHSC vs 3GPP Eric, Jean, It's good that we agree. I believe that there has been some confusion in the past that SpeechSC is a media streaming protocol. We need to list the basic issues to make sure that we clear up that misconception: 1) SpeechSC is NOT a media streaming protocol. 2) The SpeechSC protocol is strictly a command/response protocol, carrying commands and returning responses from application servers to speech servers. The SpeechSC protocol will never be a media transport protocol, and will never carry any type of media. 3) Even though the SpeechSC protocol is not a media transport protocol, the SpeechSC protocol can be used to COMMAND speech servers to set up streaming with another server using some type of streaming protocol (like SIP). Which streaming protocol is used will be determined as part of the SpeechSC's work. For example, in my attached architecture diagram, the SpeechSC protocol allows an Application Server commanding an ASR server to set up a SIP session between the ASR server and a telephony platform (see attached figure). Note that there is a SpeechSC command/control session between the Application Server and the ASR Server, but there is no streaming media going betweeen the Application & ASR Servers. There IS a standard SIP session between the Speech server and the Telephony platform, that was set up by commands given in the SpeechSC protocol. This SIP session does NOT carry any commands other than standard SIP setup/teardown commands. An example of the command/response sequence in a SpeechSC Command stream would be: Request from Application server to Directory Services for an ASR server Reply from Directory Services To Application Server giving info on specific ASR Server Command from Application Server to ASR Server to set up a specific command/ response session for a call (one command session per call context) Response from ASR Server to Application Server acknowledging the completion of the session set-up. Command from Application Server to selected ASR server to set up SIP session with a specific Telephony Server. The App Server gives the ASR server the addresses of the Telephony Server so the App Server can set up the SIP session. (ASR Server sets up SIP Session to Telephony Server)) Response from ASR Server indicating successful SIP session setup. Command from Application Server to ASR Server to set up grammars and start recognition on ASR Server. Response from ASR Server to Application Server reporting a grammar match or timeout from ASR Server. etc. Again, this is shown in mu attached diagram. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Eric Burger" 12/16/02 08:29AM >>> >From a personal perspective, the MRCP over SIP proposal was what pushed me over the edge to fix MRCP. I would be hard pressed to try to convince the IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, ... We need to pick the one that makes the most sense. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Monday, December 16, 2002 3:12 AM To: Skip Cave; Eric Burger Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Hi Skip, Nice to have some news from Intervoice... I agree. SIP will never provide multimedia control functionnalities, but I'm sure it's a great protocol from transport (and mandatory for 3G). WG has to define a couple of protocols, like MRCP/RTSP. What do you think of SPEECHSC/SIP, which can be very closed from MRCP/SIP. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: vendredi 13 décembre 2002 19:38 To: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Jean, Eric, I don't think SIP will support the separated media/control requirements I posted earlier. You will need a control protocol, and a separate media protocol. I expect that it will take a new protocol to meet these requirements. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Jean Philippe Longeray" 12/13/02 01:25AM >>> Thanks Eric for this analyze, I agree. H.248 doesn't seems to be the right answer for MRFC/MRFP, even if special packages can be provided. For my opinion, SIP is the correct answer for transport layer (since it's used everywhere in 3GPP and 3GPP2), and SPEECHSC could (should?) be used for resource control. Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing Protocols", I would like to add some remarks: In case of you would like to insert a routing mechanism (a SIP soft-switch) between Media Processing Entity / Application server and Resource server (ASR, SI/SV, TTS, Announcement server), I could be interesting to have a single transport protocol, like SIP, instead of several incompatible protocols (RTSP for example) for the closes functionalities. I think it is easier to add some redundancy, rather than conserving "old" protocols like RTSP. It seems to be very important to make distinctions between each layers of model. Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC, could be an answer. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: vendredi 13 décembre 2002 03:13 To: Jean Philippe Longeray Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] SPEECHSC vs 3GPP The Mp interface is (1) not the right concept and (2) is itself (IMHO) not the correct choice for 3GPP's needs, either. With respect to (1), Mp is trying to be an analog to the MGC/MG decomposition for a media server, where the MRFC is a "media server controller" and the MRFP is a "media server [processor]". The types of resources are bearer packet processors (e.g., tone detection, prompt playing, and recording). The protocol is a low-level device control protocol (e.g., allocate a resource, allocate a RTP port, connect the port to the resource, wait for a signal, etc.). speechsc is a higher-level protocol, concerned with things like 'establish session' and 'recognize speech'. In fact, early in the days of MRCP/speechsc, people wanted to extend the speechsc scope to do device control. The answer has consistently been to use H.248 for device control. With respect to (2), AFAIK, no one has ever built a MRFC. I believe this is because unlike a media gateway, where there are definite decomposition benefits, there are really few if any benefits to decomposing the MRF. In fact, there are clear benefits to using the native application interface (SIP), rather than the native gateway interface (H.248) for interfacing the AS and CSCF to the MRF. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 10, 2002 5:53 AM To: IETF SPEECHSC (E-mail) Subject: [Speechsc] SPEECHSC vs 3GPP Hi, Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229 Rel5) architecture. It looks like SPEECHSC is very closed from Mp interface (H.248). Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 12:29:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18346 for ; Tue, 17 Dec 2002 12:29:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHHWFa24111 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 12:32:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHHWFv24108 for ; Tue, 17 Dec 2002 12:32:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18341 for ; Tue, 17 Dec 2002 12:29:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHHW8v24097; Tue, 17 Dec 2002 12:32:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHHVcv24071 for ; Tue, 17 Dec 2002 12:31:38 -0500 Received: from bbnmg1.net.external.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18320 for ; Tue, 17 Dec 2002 12:28:33 -0500 (EST) Received: from garonne.grenoble.hp.com (garonne.grenoble.hp.com [15.128.14.138]) by bbnmg1.net.external.hp.com (Postfix) with ESMTP id 3BFC3A6; Tue, 17 Dec 2002 18:31:31 +0100 (MET) Received: by garonne.grenoble.hp.com with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Dec 2002 18:31:30 +0100 Message-ID: <468579AFDE99E74DB926952FCDE3D657064BB232@dumas.grenoble.hp.com> From: "BRANDT,MARC (HP-France,ex2)" To: Jean Philippe Longeray , Eric Burger , speechsc@ietf.org Cc: Skip Cave Subject: RE: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP] Date: Tue, 17 Dec 2002 18:31:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBHHVcv24072 Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit could you clarify the definition of softswitch in this architecture and the possible interface between App entity and the sosw ? > -----Original Message----- > From: Jean Philippe Longeray > [mailto:jean-philippe.longeray@netcentrex.net] > Sent: Tuesday, December 17, 2002 5:59 PM > To: Eric Burger; speechsc@ietf.org > Cc: Skip Cave > Subject: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP] > > > Thank you eric, > > 1) What do you think of: > > > +-------------+ | application |_________ | entity | \ +-------------+ +-------------+ : + Soft switch + : +-------------+ \ speechsc +-------------+ : \---------------| Speech |+ : whatever | Processing ||+ : ---------------| Resource(s) ||| : / RTP +-------------+|| : / +-------------+| +----------+ / +-------------+ | RTP | / | entity |----------- +----------+ > > > > In this case Soft switch can be used to select the right > speech processing > resource. > > 2) As speech processing resources, you think : > - ASR > - TTS > - speaker verif. > > Do you think we could be able to use also : streaming audio, > video, fax > (T.38) > > 3) "Whatever" could be MGCP, or H.248 > > 4) RTP entity could be : > - RTP Proxy > - RTP conference > - RTP duplicator > - RTP transcoder > > > > Best regards. > > > Jean-Philippe LONGERAY > R&D Director - Service NODE > > NetCentrex > > Jean-philippe.longeray@netcentrex.net > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > Mobile: + 33 6 76 48 34 95 > http://www.netcentrex.net > > > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: mardi 17 décembre 2002 16:22 > To: speechsc@ietf.org > Cc: Jean Philippe Longeray; Skip Cave > Subject: speechsc model [was RE: SPEECHSC vs 3GPP] > > > On the use of SIP for MRCP transport: > draft-robinson-mrcp-sip-00 is what > drove me to realize that the MRCP tunneling approach was > broken. That is > not to say that it would be wrong to raise MRCP into SIP. > However, given > the existing semantics for RTSP and TTS, that may be a better > way to go. On > the other hand, the answer to your question is, "yes": the > Robinson draft > shows SIP for signaling, not media. > > On the speechsc model, how does this look: > > > > +-------------+ > | application |_________ > | entity | \ > +-------------+ \ > : \ speechsc > +-------------+ > : \---------------| > Speech |+ > : whatever | > Processing ||+ > : ---------------| > Resource(s) ||| > : / RTP > +-------------+|| > : / > +-------------+| > +----------+ / > +-------------+ > | RTP | / > | entity |----------- > +----------+ > > > The speechsc perspective on the world has really only three logical > elements. There is an application entity, which can be (for > example ONLY) > an application server, a VoiceXML browser, a SALT browser, a > Java Bean, a > handset, a media server, etc. There is a RTP entity, which > is a source of > RTP for the speech processing resource, which can be (for > example ONLY) a > phone, a media gateway, a VoiceXML or SALT browser, etc. > Speech processing > resources are the ASR, TTS, and SI/SV engines. Note the > application entity > and RTP entity may be combined, decomposed, or have various > bits decomposed > and combined. > > Do we care about rearranging or embellishing these three > basic components? > I don't think it will materially affect the protocol analysis. > > > -----Original Message----- > From: Jean Philippe Longeray > [mailto:jean-philippe.longeray@netcentrex.net] > Sent: Tuesday, December 17, 2002 2:33 AM > To: Skip Cave; speechsc@ietf.org > Cc: Eric Burger > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > Hi skip, > > You're right, I didn't say something different. > > Like MRCP, SPEECHSC is a media command protocol. SIP is not > only a streaming > protocol, It can be used as a transport protocol, like HTTP, > X.224, ... If > SIP transports SDP, it becomes a streaming protocol, but what > don't you > thing it's not possible to transport SPEECHSC messages in SIP Content. > > In your document, something is missing: You need something to find an > Resource Server (ASR, SVI, TTS), and I propose to use SIP > softswitching, > This softswitch could be inserted between your Application > Execution Server > and all others voice resource (It could be ASR, TTS, SVI, but also > Audio/Video streaming, conferencing, ....) > > > I think that draft-robinson-mrcp-sip-00 is a great example > that I want to > say. Do you agree Eric? > > Best regards. > > Jean-Philippe LONGERAY > R&D Director - Service NODE > > NetCentrex > > Jean-philippe.longeray@netcentrex.net > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > Mobile: + 33 6 76 48 34 95 > http://www.netcentrex.net > > -----Original Message----- > From: Skip Cave [mailto:skip.cave@intervoice.com] > Sent: lundi 16 décembre 2002 20:47 > To: speechsc@ietf.org > Cc: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > Eric, Jean, > > It's good that we agree. I believe that there has been some > confusion in the > past that SpeechSC is a media streaming protocol. We need to > list the basic > issues to make sure that we clear up that misconception: > > 1) SpeechSC is NOT a media streaming protocol. > 2) The SpeechSC protocol is strictly a command/response > protocol, carrying > commands and returning responses from application servers to > speech servers. > The SpeechSC protocol will never be a media transport > protocol, and will > never carry any type of media. > 3) Even though the SpeechSC protocol is not a media transport > protocol, the > SpeechSC protocol can be used to COMMAND speech servers to > set up streaming > with another server using some type of streaming protocol > (like SIP). Which > streaming protocol is used will be determined as part of the > SpeechSC's > work. > > For example, in my attached architecture diagram, the > SpeechSC protocol > allows an Application Server commanding an ASR server to set up a SIP > session between the ASR server and a telephony platform (see attached > figure). Note that there is a SpeechSC command/control > session between the > Application Server and the ASR Server, but there is no > streaming media going > betweeen the Application & ASR Servers. There IS a standard > SIP session > between the Speech server and the Telephony platform, that > was set up by > commands given in the SpeechSC protocol. This SIP session > does NOT carry any > commands other than standard SIP setup/teardown commands. > > An example of the command/response sequence in a SpeechSC > Command stream > would be: > > Request from Application server to Directory Services for an > ASR server > Reply from Directory Services To Application Server giving > info on specific > ASR Server > Command from Application Server to ASR Server to set up a > specific command/ > response session for a call (one command session per call context) > Response from ASR Server to Application Server acknowledging > the completion > of the session set-up. > Command from Application Server to selected ASR server to set > up SIP session > with a specific Telephony Server. The App Server gives the > ASR server the > addresses of the Telephony Server so the App Server can set up the SIP > session. > (ASR Server sets up SIP Session to Telephony Server)) > Response from ASR Server indicating successful SIP session setup. > Command from Application Server to ASR Server to set up > grammars and start > recognition on ASR Server. > Response from ASR Server to Application Server reporting a > grammar match or > timeout from ASR Server. > etc. > > Again, this is shown in mu attached diagram. > > Skip Cave > Sr. Principal Engineer > Intervoice Inc. > > > >>> "Eric Burger" 12/16/02 08:29AM >>> > >From a personal perspective, the MRCP over SIP proposal was > what pushed me > over the edge to fix MRCP. I would be hard pressed to try to > convince the > IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, > ... We need to > pick the one that makes the most sense. > > -----Original Message----- > From: Jean Philippe Longeray > [mailto:jean-philippe.longeray@netcentrex.net] > Sent: Monday, December 16, 2002 3:12 AM > To: Skip Cave; Eric Burger > Cc: speechsc@ietf.org > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > Hi Skip, > > Nice to have some news from Intervoice... > > I agree. SIP will never provide multimedia control > functionnalities, but > I'm sure it's a great protocol from transport (and mandatory for 3G). > WG has to define a couple of protocols, like MRCP/RTSP. What > do you think of > SPEECHSC/SIP, which can be very closed from MRCP/SIP. > > Regards. > > > Jean-Philippe LONGERAY > R&D Director - Service NODE > > NetCentrex > > Jean-philippe.longeray@netcentrex.net > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > Mobile: + 33 6 76 48 34 95 > http://www.netcentrex.net > > -----Original Message----- > From: Skip Cave [mailto:skip.cave@intervoice.com] > Sent: vendredi 13 décembre 2002 19:38 > To: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com > Cc: speechsc@ietf.org > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > Jean, Eric, > > I don't think SIP will support the separated media/control > requirements I > posted earlier. You will need a control protocol, and a separate media > protocol. I expect that it will take a new protocol to meet these > requirements. > > Skip Cave > Sr. Principal Engineer > Intervoice Inc. > > > >>> "Jean Philippe Longeray" > 12/13/02 01:25AM >>> > Thanks Eric for this analyze, > > I agree. H.248 doesn't seems to be the right answer for > MRFC/MRFP, even if > special packages can be provided. > > For my opinion, SIP is the correct answer for transport layer > (since it's > used everywhere in 3GPP and 3GPP2), and SPEECHSC could > (should?) be used for > resource control. > > Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing > Protocols", I would > like to add some remarks: > > In case of you would like to insert a routing mechanism (a > SIP soft-switch) > between Media Processing Entity / Application server and > Resource server > (ASR, SI/SV, TTS, Announcement server), I could be > interesting to have a > single transport protocol, like SIP, instead of several incompatible > protocols (RTSP for example) for the closes functionalities. > I think it is > easier to add some redundancy, rather than conserving "old" > protocols like > RTSP. > > It seems to be very important to make distinctions between > each layers of > model. > Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or > SCTP/SIP/SPEECHSC, > could be an answer. > > > > Regards. > > > Jean-Philippe LONGERAY > R&D Director - Service NODE > > NetCentrex > > Jean-philippe.longeray@netcentrex.net > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > Mobile: + 33 6 76 48 34 95 > http://www.netcentrex.net > > > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: vendredi 13 décembre 2002 03:13 > To: Jean Philippe Longeray > Cc: IETF SPEECHSC (E-mail) > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > The Mp interface is (1) not the right concept and (2) is > itself (IMHO) not > the correct choice for 3GPP's needs, either. > > With respect to (1), Mp is trying to be an analog to the MGC/MG > decomposition for a media server, where the MRFC is a "media server > controller" and the MRFP is a "media server [processor]". > The types of > resources are bearer packet processors (e.g., tone detection, prompt > playing, and recording). The protocol is a low-level device control > protocol (e.g., allocate a resource, allocate a RTP port, > connect the port > to the resource, wait for a signal, etc.). speechsc is a higher-level > protocol, concerned with things like 'establish session' and > 'recognize > speech'. > > In fact, early in the days of MRCP/speechsc, people wanted to > extend the > speechsc scope to do device control. The answer has > consistently been to > use H.248 for device control. > > With respect to (2), AFAIK, no one has ever built a MRFC. I > believe this is > because unlike a media gateway, where there are definite decomposition > benefits, there are really few if any benefits to decomposing > the MRF. In > fact, there are clear benefits to using the native > application interface > (SIP), rather than the native gateway interface (H.248) for > interfacing the > AS and CSCF to the MRF. > > -----Original Message----- > From: Jean Philippe Longeray > [mailto:jean-philippe.longeray@netcentrex.net] > Sent: Tuesday, December 10, 2002 5:53 AM > To: IETF SPEECHSC (E-mail) > Subject: [Speechsc] SPEECHSC vs 3GPP > > > Hi, > > Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP > (TS 24.229 > Rel5) architecture. > > It looks like SPEECHSC is very closed from Mp interface (H.248). > > Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 12:53:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18900 for ; Tue, 17 Dec 2002 12:53:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHHuEd25745 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 12:56:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHHuEv25742 for ; Tue, 17 Dec 2002 12:56:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18895 for ; Tue, 17 Dec 2002 12:53:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHHniv25516; Tue, 17 Dec 2002 12:49:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHHkTv25405 for ; Tue, 17 Dec 2002 12:46:29 -0500 Received: from slap.mg2-lyon.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18694 for ; Tue, 17 Dec 2002 12:43:22 -0500 (EST) Received: from jpl (jpl.mg2-lyon.fr [132.147.160.27]) by slap.mg2-lyon.fr (Postfix) with SMTP id 4EC8910EFD; Tue, 17 Dec 2002 19:32:56 +0100 (CET) From: "Jean Philippe Longeray" To: "BRANDT,MARC (HP-France,ex2)" , "Eric Burger" , Cc: "Skip Cave" Subject: RE: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP] Date: Tue, 17 Dec 2002 18:38:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <468579AFDE99E74DB926952FCDE3D657064BB232@dumas.grenoble.hp.com> Content-Transfer-Encoding: 8bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I think that it is very similar to establish a session between a SPR (Speech Processing resource) and an AE (Application equipment) than to establish a connection between two others components (like a SIP GW and an AE). You always need to route messages between 2 entities. DNS is not a good answer, softswitch could be. Example INVITE ASR@SPR.com SIP 2.0 From : To : ... Can be routed by any soft switch, to find ASR resource... so interface between AE/SOSW is SIP and between SOSW/SP is SIP also. By experience, I know that sharing Resources between many AE is a great challenge! Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: BRANDT,MARC (HP-France,ex2) [mailto:marc.brandt@hp.com] Sent: mardi 17 décembre 2002 18:31 To: Jean Philippe Longeray; Eric Burger; speechsc@ietf.org Cc: Skip Cave Subject: RE: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP] could you clarify the definition of softswitch in this architecture and the possible interface between App entity and the sosw ? > -----Original Message----- > From: Jean Philippe Longeray > [mailto:jean-philippe.longeray@netcentrex.net] > Sent: Tuesday, December 17, 2002 5:59 PM > To: Eric Burger; speechsc@ietf.org > Cc: Skip Cave > Subject: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP] > > > Thank you eric, > > 1) What do you think of: > > > +-------------+ | application |_________ | entity | \ +-------------+ +-------------+ : + Soft switch + : +-------------+ \ speechsc +-------------+ : \---------------| Speech |+ : whatever | Processing ||+ : ---------------| Resource(s) ||| : / RTP +-------------+|| : / +-------------+| +----------+ / +-------------+ | RTP | / | entity |----------- +----------+ > > > > In this case Soft switch can be used to select the right > speech processing > resource. > > 2) As speech processing resources, you think : > - ASR > - TTS > - speaker verif. > > Do you think we could be able to use also : streaming audio, > video, fax > (T.38) > > 3) "Whatever" could be MGCP, or H.248 > > 4) RTP entity could be : > - RTP Proxy > - RTP conference > - RTP duplicator > - RTP transcoder > > > > Best regards. > > > Jean-Philippe LONGERAY > R&D Director - Service NODE > > NetCentrex > > Jean-philippe.longeray@netcentrex.net > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > Mobile: + 33 6 76 48 34 95 > http://www.netcentrex.net > > > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: mardi 17 décembre 2002 16:22 > To: speechsc@ietf.org > Cc: Jean Philippe Longeray; Skip Cave > Subject: speechsc model [was RE: SPEECHSC vs 3GPP] > > > On the use of SIP for MRCP transport: > draft-robinson-mrcp-sip-00 is what > drove me to realize that the MRCP tunneling approach was > broken. That is > not to say that it would be wrong to raise MRCP into SIP. > However, given > the existing semantics for RTSP and TTS, that may be a better > way to go. On > the other hand, the answer to your question is, "yes": the > Robinson draft > shows SIP for signaling, not media. > > On the speechsc model, how does this look: > > > > +-------------+ > | application |_________ > | entity | \ > +-------------+ \ > : \ speechsc > +-------------+ > : \---------------| > Speech |+ > : whatever | > Processing ||+ > : ---------------| > Resource(s) ||| > : / RTP > +-------------+|| > : / > +-------------+| > +----------+ / > +-------------+ > | RTP | / > | entity |----------- > +----------+ > > > The speechsc perspective on the world has really only three logical > elements. There is an application entity, which can be (for > example ONLY) > an application server, a VoiceXML browser, a SALT browser, a > Java Bean, a > handset, a media server, etc. There is a RTP entity, which > is a source of > RTP for the speech processing resource, which can be (for > example ONLY) a > phone, a media gateway, a VoiceXML or SALT browser, etc. > Speech processing > resources are the ASR, TTS, and SI/SV engines. Note the > application entity > and RTP entity may be combined, decomposed, or have various > bits decomposed > and combined. > > Do we care about rearranging or embellishing these three > basic components? > I don't think it will materially affect the protocol analysis. > > > -----Original Message----- > From: Jean Philippe Longeray > [mailto:jean-philippe.longeray@netcentrex.net] > Sent: Tuesday, December 17, 2002 2:33 AM > To: Skip Cave; speechsc@ietf.org > Cc: Eric Burger > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > Hi skip, > > You're right, I didn't say something different. > > Like MRCP, SPEECHSC is a media command protocol. SIP is not > only a streaming > protocol, It can be used as a transport protocol, like HTTP, > X.224, ... If > SIP transports SDP, it becomes a streaming protocol, but what > don't you > thing it's not possible to transport SPEECHSC messages in SIP Content. > > In your document, something is missing: You need something to find an > Resource Server (ASR, SVI, TTS), and I propose to use SIP > softswitching, > This softswitch could be inserted between your Application > Execution Server > and all others voice resource (It could be ASR, TTS, SVI, but also > Audio/Video streaming, conferencing, ....) > > > I think that draft-robinson-mrcp-sip-00 is a great example > that I want to > say. Do you agree Eric? > > Best regards. > > Jean-Philippe LONGERAY > R&D Director - Service NODE > > NetCentrex > > Jean-philippe.longeray@netcentrex.net > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > Mobile: + 33 6 76 48 34 95 > http://www.netcentrex.net > > -----Original Message----- > From: Skip Cave [mailto:skip.cave@intervoice.com] > Sent: lundi 16 décembre 2002 20:47 > To: speechsc@ietf.org > Cc: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > Eric, Jean, > > It's good that we agree. I believe that there has been some > confusion in the > past that SpeechSC is a media streaming protocol. We need to > list the basic > issues to make sure that we clear up that misconception: > > 1) SpeechSC is NOT a media streaming protocol. > 2) The SpeechSC protocol is strictly a command/response > protocol, carrying > commands and returning responses from application servers to > speech servers. > The SpeechSC protocol will never be a media transport > protocol, and will > never carry any type of media. > 3) Even though the SpeechSC protocol is not a media transport > protocol, the > SpeechSC protocol can be used to COMMAND speech servers to > set up streaming > with another server using some type of streaming protocol > (like SIP). Which > streaming protocol is used will be determined as part of the > SpeechSC's > work. > > For example, in my attached architecture diagram, the > SpeechSC protocol > allows an Application Server commanding an ASR server to set up a SIP > session between the ASR server and a telephony platform (see attached > figure). Note that there is a SpeechSC command/control > session between the > Application Server and the ASR Server, but there is no > streaming media going > betweeen the Application & ASR Servers. There IS a standard > SIP session > between the Speech server and the Telephony platform, that > was set up by > commands given in the SpeechSC protocol. This SIP session > does NOT carry any > commands other than standard SIP setup/teardown commands. > > An example of the command/response sequence in a SpeechSC > Command stream > would be: > > Request from Application server to Directory Services for an > ASR server > Reply from Directory Services To Application Server giving > info on specific > ASR Server > Command from Application Server to ASR Server to set up a > specific command/ > response session for a call (one command session per call context) > Response from ASR Server to Application Server acknowledging > the completion > of the session set-up. > Command from Application Server to selected ASR server to set > up SIP session > with a specific Telephony Server. The App Server gives the > ASR server the > addresses of the Telephony Server so the App Server can set up the SIP > session. > (ASR Server sets up SIP Session to Telephony Server)) > Response from ASR Server indicating successful SIP session setup. > Command from Application Server to ASR Server to set up > grammars and start > recognition on ASR Server. > Response from ASR Server to Application Server reporting a > grammar match or > timeout from ASR Server. > etc. > > Again, this is shown in mu attached diagram. > > Skip Cave > Sr. Principal Engineer > Intervoice Inc. > > > >>> "Eric Burger" 12/16/02 08:29AM >>> > >From a personal perspective, the MRCP over SIP proposal was > what pushed me > over the edge to fix MRCP. I would be hard pressed to try to > convince the > IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, > ... We need to > pick the one that makes the most sense. > > -----Original Message----- > From: Jean Philippe Longeray > [mailto:jean-philippe.longeray@netcentrex.net] > Sent: Monday, December 16, 2002 3:12 AM > To: Skip Cave; Eric Burger > Cc: speechsc@ietf.org > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > Hi Skip, > > Nice to have some news from Intervoice... > > I agree. SIP will never provide multimedia control > functionnalities, but > I'm sure it's a great protocol from transport (and mandatory for 3G). > WG has to define a couple of protocols, like MRCP/RTSP. What > do you think of > SPEECHSC/SIP, which can be very closed from MRCP/SIP. > > Regards. > > > Jean-Philippe LONGERAY > R&D Director - Service NODE > > NetCentrex > > Jean-philippe.longeray@netcentrex.net > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > Mobile: + 33 6 76 48 34 95 > http://www.netcentrex.net > > -----Original Message----- > From: Skip Cave [mailto:skip.cave@intervoice.com] > Sent: vendredi 13 décembre 2002 19:38 > To: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com > Cc: speechsc@ietf.org > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > Jean, Eric, > > I don't think SIP will support the separated media/control > requirements I > posted earlier. You will need a control protocol, and a separate media > protocol. I expect that it will take a new protocol to meet these > requirements. > > Skip Cave > Sr. Principal Engineer > Intervoice Inc. > > > >>> "Jean Philippe Longeray" > 12/13/02 01:25AM >>> > Thanks Eric for this analyze, > > I agree. H.248 doesn't seems to be the right answer for > MRFC/MRFP, even if > special packages can be provided. > > For my opinion, SIP is the correct answer for transport layer > (since it's > used everywhere in 3GPP and 3GPP2), and SPEECHSC could > (should?) be used for > resource control. > > Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing > Protocols", I would > like to add some remarks: > > In case of you would like to insert a routing mechanism (a > SIP soft-switch) > between Media Processing Entity / Application server and > Resource server > (ASR, SI/SV, TTS, Announcement server), I could be > interesting to have a > single transport protocol, like SIP, instead of several incompatible > protocols (RTSP for example) for the closes functionalities. > I think it is > easier to add some redundancy, rather than conserving "old" > protocols like > RTSP. > > It seems to be very important to make distinctions between > each layers of > model. > Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or > SCTP/SIP/SPEECHSC, > could be an answer. > > > > Regards. > > > Jean-Philippe LONGERAY > R&D Director - Service NODE > > NetCentrex > > Jean-philippe.longeray@netcentrex.net > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > Mobile: + 33 6 76 48 34 95 > http://www.netcentrex.net > > > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: vendredi 13 décembre 2002 03:13 > To: Jean Philippe Longeray > Cc: IETF SPEECHSC (E-mail) > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > The Mp interface is (1) not the right concept and (2) is > itself (IMHO) not > the correct choice for 3GPP's needs, either. > > With respect to (1), Mp is trying to be an analog to the MGC/MG > decomposition for a media server, where the MRFC is a "media server > controller" and the MRFP is a "media server [processor]". > The types of > resources are bearer packet processors (e.g., tone detection, prompt > playing, and recording). The protocol is a low-level device control > protocol (e.g., allocate a resource, allocate a RTP port, > connect the port > to the resource, wait for a signal, etc.). speechsc is a higher-level > protocol, concerned with things like 'establish session' and > 'recognize > speech'. > > In fact, early in the days of MRCP/speechsc, people wanted to > extend the > speechsc scope to do device control. The answer has > consistently been to > use H.248 for device control. > > With respect to (2), AFAIK, no one has ever built a MRFC. I > believe this is > because unlike a media gateway, where there are definite decomposition > benefits, there are really few if any benefits to decomposing > the MRF. In > fact, there are clear benefits to using the native > application interface > (SIP), rather than the native gateway interface (H.248) for > interfacing the > AS and CSCF to the MRF. > > -----Original Message----- > From: Jean Philippe Longeray > [mailto:jean-philippe.longeray@netcentrex.net] > Sent: Tuesday, December 10, 2002 5:53 AM > To: IETF SPEECHSC (E-mail) > Subject: [Speechsc] SPEECHSC vs 3GPP > > > Hi, > > Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP > (TS 24.229 > Rel5) architecture. > > It looks like SPEECHSC is very closed from Mp interface (H.248). > > Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 13:04:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19201 for ; Tue, 17 Dec 2002 13:04:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHI7PE26770 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 13:07:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHI7Pv26767 for ; Tue, 17 Dec 2002 13:07:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19184 for ; Tue, 17 Dec 2002 13:04:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHI03v25921; Tue, 17 Dec 2002 13:00:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHHxrv25885 for ; Tue, 17 Dec 2002 12:59:53 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18959 for ; Tue, 17 Dec 2002 12:56:47 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP] Date: Tue, 17 Dec 2002 12:59:45 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D097BAD@zoe.office.snowshore.com> Thread-Topic: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP] Thread-Index: AcKl9DqTNeUapqarTLK7/YaGxYDNrwAABDCw From: "Eric Burger" To: "Jean Philippe Longeray" Cc: "BRANDT,MARC (HP-France,ex2)" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBHHxrv25886 Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit The concept is OK. The terminology is a non-starter. Most people assume a softswitch is a media gateway controller. See . However, I again ask, does having an application switch (to use Internet terminology) have any bearing on speechsc? It shouldn't. The whole point of using IP is that transport and distribution is transparent to our application-layer [sic; I know we're tsv] protocol. > -----Original Message----- > From: Jean Philippe Longeray > [mailto:jean-philippe.longeray@netcentrex.net] > Sent: Tuesday, December 17, 2002 12:39 PM > To: BRANDT,MARC (HP-France,ex2); Eric Burger; speechsc@ietf.org > Cc: Skip Cave > Subject: RE: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP] > > > I think that it is very similar to establish a session > between a SPR (Speech > Processing resource) and an AE (Application equipment) than > to establish a > connection between two others components (like a SIP GW and an AE). > You always need to route messages between 2 entities. DNS is > not a good > answer, softswitch could be. > > Example > > > INVITE ASR@SPR.com SIP 2.0 > From : > To : > > ... > > Can be routed by any soft switch, to find ASR resource... so interface > between AE/SOSW is SIP and between SOSW/SP is SIP also. > > By experience, I know that sharing Resources between many AE > is a great > challenge! > > Regards. > > > Jean-Philippe LONGERAY > R&D Director - Service NODE > > NetCentrex > > Jean-philippe.longeray@netcentrex.net > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > Mobile: + 33 6 76 48 34 95 > http://www.netcentrex.net > > > > -----Original Message----- > From: BRANDT,MARC (HP-France,ex2) [mailto:marc.brandt@hp.com] > Sent: mardi 17 décembre 2002 18:31 > To: Jean Philippe Longeray; Eric Burger; speechsc@ietf.org > Cc: Skip Cave > Subject: RE: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP] > > > > could you clarify the definition of softswitch in this architecture > and the possible interface between App entity and the sosw ? > > > > -----Original Message----- > > From: Jean Philippe Longeray > > [mailto:jean-philippe.longeray@netcentrex.net] > > Sent: Tuesday, December 17, 2002 5:59 PM > > To: Eric Burger; speechsc@ietf.org > > Cc: Skip Cave > > Subject: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP] > > > > > > Thank you eric, > > > > 1) What do you think of: > > > > > > > > +-------------+ > | application |_________ > | entity | \ > +-------------+ +-------------+ > : + Soft switch + > : +-------------+ > \ speechsc > +-------------+ > : \---------------| > Speech |+ > : whatever | > Processing ||+ > : ---------------| > Resource(s) ||| > : / RTP > +-------------+|| > : / > +-------------+| > +----------+ / > +-------------+ > | RTP | / > | entity |----------- > +----------+ > > > > > > > > > > In this case Soft switch can be used to select the right > > speech processing > > resource. > > > > 2) As speech processing resources, you think : > > - ASR > > - TTS > > - speaker verif. > > > > Do you think we could be able to use also : streaming audio, > > video, fax > > (T.38) > > > > 3) "Whatever" could be MGCP, or H.248 > > > > 4) RTP entity could be : > > - RTP Proxy > > - RTP conference > > - RTP duplicator > > - RTP transcoder > > > > > > > > Best regards. > > > > > > Jean-Philippe LONGERAY > > R&D Director - Service NODE > > > > NetCentrex > > > > Jean-philippe.longeray@netcentrex.net > > > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > > Mobile: + 33 6 76 48 34 95 > > http://www.netcentrex.net > > > > > > > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: mardi 17 décembre 2002 16:22 > > To: speechsc@ietf.org > > Cc: Jean Philippe Longeray; Skip Cave > > Subject: speechsc model [was RE: SPEECHSC vs 3GPP] > > > > > > On the use of SIP for MRCP transport: > > draft-robinson-mrcp-sip-00 is what > > drove me to realize that the MRCP tunneling approach was > > broken. That is > > not to say that it would be wrong to raise MRCP into SIP. > > However, given > > the existing semantics for RTSP and TTS, that may be a better > > way to go. On > > the other hand, the answer to your question is, "yes": the > > Robinson draft > > shows SIP for signaling, not media. > > > > On the speechsc model, how does this look: > > > > > > > > +-------------+ > > | application |_________ > > | entity | \ > > +-------------+ \ > > : \ speechsc > > +-------------+ > > : \---------------| > > Speech |+ > > : whatever | > > Processing ||+ > > : ---------------| > > Resource(s) ||| > > : / RTP > > +-------------+|| > > : / > > +-------------+| > > +----------+ / > > +-------------+ > > | RTP | / > > | entity |----------- > > +----------+ > > > > > > The speechsc perspective on the world has really only three logical > > elements. There is an application entity, which can be (for > > example ONLY) > > an application server, a VoiceXML browser, a SALT browser, a > > Java Bean, a > > handset, a media server, etc. There is a RTP entity, which > > is a source of > > RTP for the speech processing resource, which can be (for > > example ONLY) a > > phone, a media gateway, a VoiceXML or SALT browser, etc. > > Speech processing > > resources are the ASR, TTS, and SI/SV engines. Note the > > application entity > > and RTP entity may be combined, decomposed, or have various > > bits decomposed > > and combined. > > > > Do we care about rearranging or embellishing these three > > basic components? > > I don't think it will materially affect the protocol analysis. > > > > > > -----Original Message----- > > From: Jean Philippe Longeray > > [mailto:jean-philippe.longeray@netcentrex.net] > > Sent: Tuesday, December 17, 2002 2:33 AM > > To: Skip Cave; speechsc@ietf.org > > Cc: Eric Burger > > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > > > > Hi skip, > > > > You're right, I didn't say something different. > > > > Like MRCP, SPEECHSC is a media command protocol. SIP is not > > only a streaming > > protocol, It can be used as a transport protocol, like HTTP, > > X.224, ... If > > SIP transports SDP, it becomes a streaming protocol, but what > > don't you > > thing it's not possible to transport SPEECHSC messages in > SIP Content. > > > > In your document, something is missing: You need something > to find an > > Resource Server (ASR, SVI, TTS), and I propose to use SIP > > softswitching, > > This softswitch could be inserted between your Application > > Execution Server > > and all others voice resource (It could be ASR, TTS, SVI, but also > > Audio/Video streaming, conferencing, ....) > > > > > > I think that draft-robinson-mrcp-sip-00 is a great example > > that I want to > > say. Do you agree Eric? > > > > Best regards. > > > > Jean-Philippe LONGERAY > > R&D Director - Service NODE > > > > NetCentrex > > > > Jean-philippe.longeray@netcentrex.net > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > > Mobile: + 33 6 76 48 34 95 > > http://www.netcentrex.net > > > > -----Original Message----- > > From: Skip Cave [mailto:skip.cave@intervoice.com] > > Sent: lundi 16 décembre 2002 20:47 > > To: speechsc@ietf.org > > Cc: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com > > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > > > > Eric, Jean, > > > > It's good that we agree. I believe that there has been some > > confusion in the > > past that SpeechSC is a media streaming protocol. We need to > > list the basic > > issues to make sure that we clear up that misconception: > > > > 1) SpeechSC is NOT a media streaming protocol. > > 2) The SpeechSC protocol is strictly a command/response > > protocol, carrying > > commands and returning responses from application servers to > > speech servers. > > The SpeechSC protocol will never be a media transport > > protocol, and will > > never carry any type of media. > > 3) Even though the SpeechSC protocol is not a media transport > > protocol, the > > SpeechSC protocol can be used to COMMAND speech servers to > > set up streaming > > with another server using some type of streaming protocol > > (like SIP). Which > > streaming protocol is used will be determined as part of the > > SpeechSC's > > work. > > > > For example, in my attached architecture diagram, the > > SpeechSC protocol > > allows an Application Server commanding an ASR server to > set up a SIP > > session between the ASR server and a telephony platform > (see attached > > figure). Note that there is a SpeechSC command/control > > session between the > > Application Server and the ASR Server, but there is no > > streaming media going > > betweeen the Application & ASR Servers. There IS a standard > > SIP session > > between the Speech server and the Telephony platform, that > > was set up by > > commands given in the SpeechSC protocol. This SIP session > > does NOT carry any > > commands other than standard SIP setup/teardown commands. > > > > An example of the command/response sequence in a SpeechSC > > Command stream > > would be: > > > > Request from Application server to Directory Services for an > > ASR server > > Reply from Directory Services To Application Server giving > > info on specific > > ASR Server > > Command from Application Server to ASR Server to set up a > > specific command/ > > response session for a call (one command session per call context) > > Response from ASR Server to Application Server acknowledging > > the completion > > of the session set-up. > > Command from Application Server to selected ASR server to set > > up SIP session > > with a specific Telephony Server. The App Server gives the > > ASR server the > > addresses of the Telephony Server so the App Server can set > up the SIP > > session. > > (ASR Server sets up SIP Session to Telephony Server)) > > Response from ASR Server indicating successful SIP session setup. > > Command from Application Server to ASR Server to set up > > grammars and start > > recognition on ASR Server. > > Response from ASR Server to Application Server reporting a > > grammar match or > > timeout from ASR Server. > > etc. > > > > Again, this is shown in mu attached diagram. > > > > Skip Cave > > Sr. Principal Engineer > > Intervoice Inc. > > > > > > >>> "Eric Burger" 12/16/02 08:29AM >>> > > >From a personal perspective, the MRCP over SIP proposal was > > what pushed me > > over the edge to fix MRCP. I would be hard pressed to try to > > convince the > > IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, > > ... We need to > > pick the one that makes the most sense. > > > > -----Original Message----- > > From: Jean Philippe Longeray > > [mailto:jean-philippe.longeray@netcentrex.net] > > Sent: Monday, December 16, 2002 3:12 AM > > To: Skip Cave; Eric Burger > > Cc: speechsc@ietf.org > > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > > > > Hi Skip, > > > > Nice to have some news from Intervoice... > > > > I agree. SIP will never provide multimedia control > > functionnalities, but > > I'm sure it's a great protocol from transport (and > mandatory for 3G). > > WG has to define a couple of protocols, like MRCP/RTSP. What > > do you think of > > SPEECHSC/SIP, which can be very closed from MRCP/SIP. > > > > Regards. > > > > > > Jean-Philippe LONGERAY > > R&D Director - Service NODE > > > > NetCentrex > > > > Jean-philippe.longeray@netcentrex.net > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > > Mobile: + 33 6 76 48 34 95 > > http://www.netcentrex.net > > > > -----Original Message----- > > From: Skip Cave [mailto:skip.cave@intervoice.com] > > Sent: vendredi 13 décembre 2002 19:38 > > To: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com > > Cc: speechsc@ietf.org > > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > > > > Jean, Eric, > > > > I don't think SIP will support the separated media/control > > requirements I > > posted earlier. You will need a control protocol, and a > separate media > > protocol. I expect that it will take a new protocol to meet these > > requirements. > > > > Skip Cave > > Sr. Principal Engineer > > Intervoice Inc. > > > > > > >>> "Jean Philippe Longeray" > > 12/13/02 01:25AM >>> > > Thanks Eric for this analyze, > > > > I agree. H.248 doesn't seems to be the right answer for > > MRFC/MRFP, even if > > special packages can be provided. > > > > For my opinion, SIP is the correct answer for transport layer > > (since it's > > used everywhere in 3GPP and 3GPP2), and SPEECHSC could > > (should?) be used for > > resource control. > > > > Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing > > Protocols", I would > > like to add some remarks: > > > > In case of you would like to insert a routing mechanism (a > > SIP soft-switch) > > between Media Processing Entity / Application server and > > Resource server > > (ASR, SI/SV, TTS, Announcement server), I could be > > interesting to have a > > single transport protocol, like SIP, instead of several incompatible > > protocols (RTSP for example) for the closes functionalities. > > I think it is > > easier to add some redundancy, rather than conserving "old" > > protocols like > > RTSP. > > > > It seems to be very important to make distinctions between > > each layers of > > model. > > Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or > > SCTP/SIP/SPEECHSC, > > could be an answer. > > > > > > > > Regards. > > > > > > Jean-Philippe LONGERAY > > R&D Director - Service NODE > > > > NetCentrex > > > > Jean-philippe.longeray@netcentrex.net > > > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > > Mobile: + 33 6 76 48 34 95 > > http://www.netcentrex.net > > > > > > > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: vendredi 13 décembre 2002 03:13 > > To: Jean Philippe Longeray > > Cc: IETF SPEECHSC (E-mail) > > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > > > > The Mp interface is (1) not the right concept and (2) is > > itself (IMHO) not > > the correct choice for 3GPP's needs, either. > > > > With respect to (1), Mp is trying to be an analog to the MGC/MG > > decomposition for a media server, where the MRFC is a "media server > > controller" and the MRFP is a "media server [processor]". > > The types of > > resources are bearer packet processors (e.g., tone detection, prompt > > playing, and recording). The protocol is a low-level device control > > protocol (e.g., allocate a resource, allocate a RTP port, > > connect the port > > to the resource, wait for a signal, etc.). speechsc is a > higher-level > > protocol, concerned with things like 'establish session' and > > 'recognize > > speech'. > > > > In fact, early in the days of MRCP/speechsc, people wanted to > > extend the > > speechsc scope to do device control. The answer has > > consistently been to > > use H.248 for device control. > > > > With respect to (2), AFAIK, no one has ever built a MRFC. I > > believe this is > > because unlike a media gateway, where there are definite > decomposition > > benefits, there are really few if any benefits to decomposing > > the MRF. In > > fact, there are clear benefits to using the native > > application interface > > (SIP), rather than the native gateway interface (H.248) for > > interfacing the > > AS and CSCF to the MRF. > > > > -----Original Message----- > > From: Jean Philippe Longeray > > [mailto:jean-philippe.longeray@netcentrex.net] > > Sent: Tuesday, December 10, 2002 5:53 AM > > To: IETF SPEECHSC (E-mail) > > Subject: [Speechsc] SPEECHSC vs 3GPP > > > > > > Hi, > > > > Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP > > (TS 24.229 > > Rel5) architecture. > > > > It looks like SPEECHSC is very closed from Mp interface (H.248). > > > > Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 > (www.3gpp2.org) , > 3G.IP (www.3gip.org), MWIF (www.mwif.org)? > > Regards. > > Jean-Philippe LONGERAY > R&D Director - Service NODE > > NetCentrex > > Jean-philippe.longeray@netcentrex.net > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > Mobile: + 33 6 76 48 34 95 > http://www.netcentrex.net > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 13:53:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20204 for ; Tue, 17 Dec 2002 13:53:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHIuFP29165 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 13:56:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHIuFv29162 for ; Tue, 17 Dec 2002 13:56:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20195 for ; Tue, 17 Dec 2002 13:53:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHIuAv29153; Tue, 17 Dec 2002 13:56:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHIu0v29138 for ; Tue, 17 Dec 2002 13:56:00 -0500 Received: from speechworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20178 for ; Tue, 17 Dec 2002 13:52:56 -0500 (EST) Received: from vishnu.speechworks.com (mailhost.speechworks.com [63.113.17.2]) by speechworks.com (8.10.2+Sun/8.9.3) with ESMTP id gBHJ1UA10597; Tue, 17 Dec 2002 14:01:30 -0500 (EST) Received: from whitney (localhost [127.0.0.1]) by vishnu.speechworks.com (8.10.2+Sun/8.9.3) with SMTP id gBHItsm11854; Tue, 17 Dec 2002 13:55:54 -0500 (EST) From: "Brian Eberman" To: "Eric Burger" , "Jean Philippe Longeray" Cc: Subject: RE: [Speechsc] SPEECHSC vs 3GPP Date: Tue, 17 Dec 2002 13:55:54 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <4A3384433CE2AB46A63468CB207E209D097619@zoe.office.snowshore.com> Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There is one area that needs more thought that is related to voice recording. VoiceXML requires that the tag support termination based on DTMF recognition against a grammar. It can also require "hot word" based recognition. So this kind of voice recording is more of a recognition terminated recording and I think we might need to put that in scope. -Brian -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf Of Eric Burger Sent: Tuesday, December 17, 2002 10:26 AM To: Jean Philippe Longeray Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP The following items are explicitly out of scope. We already have SIP, H.248, and J.162. We don't need yet another protocol to do the same thing. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 17, 2002 5:00 AM [snip] Find bellow some extension of MRCP, SPEECHSC could cover: [snip] - announcement, voice recording, - tones detection, tones generation, - fax, - audio conferencing, - video conferencing, - chat SPEECHSC could be a Multimedia protocol, not only for Speech but also for Video, Data, FAX ....3G! _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 14:15:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20759 for ; Tue, 17 Dec 2002 14:15:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHJIOh30453 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 14:18:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHJIOv30450 for ; Tue, 17 Dec 2002 14:18:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20724 for ; Tue, 17 Dec 2002 14:15:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHJIKv30430; Tue, 17 Dec 2002 14:18:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHJGMv30335 for ; Tue, 17 Dec 2002 14:16:22 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20666 for ; Tue, 17 Dec 2002 14:13:18 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Speechsc] SPEECHSC vs 3GPP Date: Tue, 17 Dec 2002 14:16:18 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D097636@zoe.office.snowshore.com> Thread-Topic: [Speechsc] SPEECHSC vs 3GPP Thread-Index: AcKl/fNJbYGu8p6tRw2jfe9C1rgWXQAArHzg From: "Eric Burger" To: "Brian Eberman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBHJGNv30336 Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Correct. What is out of scope is the H.248 line package. Clearly a cloudy area :-) > -----Original Message----- > From: Brian Eberman [mailto:bse@speechworks.com] > Sent: Tuesday, December 17, 2002 1:56 PM > To: Eric Burger; Jean Philippe Longeray > Cc: speechsc@ietf.org > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > There is one area that needs more thought that is related to voice > recording. VoiceXML requires that the tag support > termination > based on DTMF recognition against a grammar. It can also > require "hot word" > based recognition. So this kind of voice recording is more > of a recognition > terminated recording and I think we might need to put that in scope. > > -Brian > > -----Original Message----- > From: speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]On Behalf > Of Eric Burger > Sent: Tuesday, December 17, 2002 10:26 AM > To: Jean Philippe Longeray > Cc: speechsc@ietf.org > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > The following items are explicitly out of scope. We already have SIP, > H.248, and J.162. We don't need yet another protocol to do > the same thing. > > > -----Original Message----- From: Jean Philippe Longeray > [mailto:jean-philippe.longeray@netcentrex.net] > Sent: Tuesday, December 17, 2002 5:00 AM > [snip] > > Find bellow some extension of MRCP, SPEECHSC could cover: > [snip] > - announcement, voice recording, > - tones detection, tones generation, > - fax, > - audio conferencing, > - video conferencing, > - chat > > > SPEECHSC could be a Multimedia protocol, not only for Speech > but also for > Video, Data, FAX ....3G! > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 15:24:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22594 for ; Tue, 17 Dec 2002 15:24:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHKQrk01695 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 15:26:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHKQqv01692 for ; Tue, 17 Dec 2002 15:26:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22585 for ; Tue, 17 Dec 2002 15:23:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHKKLv01493; Tue, 17 Dec 2002 15:20:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHKJav01445 for ; Tue, 17 Dec 2002 15:19:36 -0500 Received: from gremg1.net.external.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22422 for ; Tue, 17 Dec 2002 15:16:28 -0500 (EST) Received: from loire.grenoble.hp.com (loire.grenoble.hp.com [15.128.14.199]) by gremg1.net.external.hp.com (Postfix) with ESMTP id EE9AB16B for ; Tue, 17 Dec 2002 21:19:27 +0100 (MET) Received: by loire.grenoble.hp.com with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Dec 2002 21:19:27 +0100 Message-ID: <468579AFDE99E74DB926952FCDE3D657017CA7AC@dumas.grenoble.hp.com> From: "BRANDT,MARC (HP-France,ex2)" To: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Date: Tue, 17 Dec 2002 21:19:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , <-- sorry if dup, I had email pb posting to the list, and was not sure of the result, + this one is in ascii --> some comments on this thread below, I agree with the decomposition or unbundling model. Although there is no needs to support a multitude of protocol stacks profiles (aka speechsc over everything), I believe speechsc needs to enable some separation in terms of protocol layers and service interfaces (this is also a personal good learning of previous model like OSI, TCP/IP... which are somewhat widely adopted in the SIP, HTTP, SOAP and other work as well). Separation of Control pipe and media pipe is also at the heart of modern telecoms. I suspect in addition to the command/response protocol model for speechsc, there needs to be an event based model as well (like a pub/sub). Typically to support the detection of resources, or for better efficiency in terms of media resource processing (modern programming has always shown interest for poll as well as asynchronous models). I also noticed one point in the discussion that is important, regarding the extensions and openness to support evolutions of the resource control semantic. Speechsc would benefit by not relying on new specifications to be created each time a new resource control feature is available, this is imo well covered in the speechsc requirements. But going further and leaving this knowledge at the application level would really enable speechsc to become a framework for supporting disparate media resource control semantic with not much protocol changes. Additionally 'pay load' or 'specific resource profiles' could be described anytime a new one is added as standards extensions (e.g. like the model for RTP pay loads...). This also leaves the room to application specific extensions and differentiations while not violating standards. Enabling a 'programmable' approach when new media resources are created / described and used by app servers. An application may need to invoke a brand new control function without having to rewrite the speechsc protocol layer. Regarding that I tend to consider that adding verbs to the protocol might be more a specification burden than using a descriptive means which can be evolved. At the price of efficiency maybe. So I can agree that some verbs could be put at the core of the protocol (like we have for HTTP, SIP and so on), and the rest more as a semantic pay load (which can be standardized as well, see the XML payloads by OASIS). For instance if I want to build a speech resource that translates streams from voice to voice, will I need other verbs ? a new protocol ? Or if I build a resource that combines functions and so on. This is where we might think of proposing a framework with a way to create optimized interactions. This is already done in some protocols where for instance you can use abbreviated fields, or encoded fields instead of full XML stuff. Or by analogy when using a framework for interpreting languages or compiling languages. But the protocol shall certainly not be a hack just to support efficiency (one can also bet on Moore's law). I also agree with the point on multitude of possible multimedia resources that will have to be controlled by an application. This was initially discussed at the req phase if I remember well. With an output that initial focus of the 1st delivery of speechsc shall be limited in order to avoid the full-picture syndrome and no protocol at the end (and there is SPEECH in speechsc). I believe that other IETF groups are also holding worthwhile discussions on this domain. For instance, I would like to understand the opinions of the group on the mmusic status from last IETF: what about: XML Schema for Media Control in the mmusic minutes http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg01105.htm l draft-levin-mmusic-xml-media-control-00.txt http://www.ietf.org/internet-drafts/draft-levin-mmusic-xml-media-control-00. txt Of course each time we broaden the scope we ease programmable approaches and thus wide developers adoption, but often at the price of efficiency provided by limited scope approaches, really targeted at and tuned for specific resources (and manufacturers ;-). Now in terms of technology I guess there are advantages in the likes of SIP, SOAP, XML (anyway already widely used at the speech grammar or synthesis level in the MRCP packets for instance), with all the extensibility and programmability that they provide. For instance, SIP can be extended, see the SIPPING an SIMPLE work to provide open framework for other semantic to be built on top of it. SOAP clearly provides a good invocation model for a 'programmable' framework. One value add of speechsc could then be to keep this programmability and openness while delivering efficiency in the targeted application profiles (optimizing connections set up, traffic, reuse of media paths and so on ...), e.g. providing new verbs for these kind of core functions while using descriptive services for upper application/media resources functions. Refer to speechsc reqs: Re-use of transport connections across sessions, Piggybacking of responses on requests in the reverse direction, Caching of state across requests ... these are functions that deserve standard treatment across a whole bunch of resources (core protocol). Speechsc would then be completely independent of media resource semantic, and only aware of the semantic of 'controlling' such resources for the best application experience. A TTS resource would be speechsc compliant of the class TTS with such and such features defined in the programmable layer pay load (+ room for vendor extensions). One SIze protocol does not fit all layers. Marc Brandt - mailto:Marc.Brandt@hp.com Hewlett-Packard - OpenCall Business Unit 5, av. r. chanas - eybens - 38053 grenoble cedex 9 - france tel : +33 4 7614 1088 (hp 779-1088) fax : +33 4 7614 4323 (hp 779-4323) https://ecardfile.com/id/Marc+Brandt http://www.hp.com/communications/opencall/ -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 17, 2002 11:00 AM To: brian.wyld@eloquant.com; 'Skip Cave'; speechsc@ietf.org Cc: eburger@snowshore.com Subject: RE: [Speechsc] SPEECHSC vs 3GPP Brian, Living in France, I'm very attached to the OSI model defined by ITU-T. I think it is really important to make some distinctions between transportation and application protocol. SIP is little bit poor for data transportation, but it exists and clearly chosen by 3GPP and 3GPP2. For my opinion , SPEECHSC could be something very closed from MRCP and transported by SIP INFO method. Speechsc, like MRCP must only define the media control part and the way how it can be transported by SIP (and optionally by others protocols like H.225.0, RTSP, H.248, ...) All media resources could be controlled by the same protocol (SPEECHSC). At the streaming side, RTP/RTCP is ouf course engaged. I'm sure that a MutliMedia VOIP core with optional peripheral gateways is the Next Gen architecture for Telephony. An extension of MRCP could be the answer. It is a great protocol, isn't it? And It already works over RTSP (Nuance, Speechworks, Telisma...) Find bellow some extension of MRCP, SPEECHSC could cover: - speaker verification, - speaker identification, - announcement, voice recording, - tones detection, tones generation, - fax, - audio conferencing, - video conferencing, - chat SPEECHSC could be a Multimedia protocol, not only for Speech but also for Video, Data, FAX ....3G! Best regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Brian Wyld [mailto:brian.wyld@eloquant.com] Sent: mardi 17 décembre 2002 09:47 To: 'Jean Philippe Longeray'; 'Skip Cave'; speechsc@ietf.org Cc: eburger@snowshore.com Subject: RE: [Speechsc] SPEECHSC vs 3GPP Messieurs Some interesting discussion here - to ease the job of the protocol eval doc editor :-) perhaps someone would like to do a protocol analysis section for 3GPP H.248 (maybe just to rule it out?) - Jean-Philippe perhaps? My 2c on the SPEECHSC/whatever - I think there is a first question to resolve in my mind Q1: what is the best model for SPEECHSC: - a layer OVER a media signalling protocol (SIP, RTSP, etc, depending on this lower layer for media and session control, just like MRCP/RTSP currently does) -> in which case what is the encapsulation mechanism - RTSP has ANNOUNCE messages, what does SIP provide for this sort of bundling? -> and what is the "best" protocol to layer over - an extension to an existing media signalling protocol (eg, add MRCP "verbs" as new ones in RTSP, or add as new SIP commands...) - a new protocol incorporating both media signalling, session control and resource control (eg Web services extensions) As for the identification and resolution of resource servers, this is for me a separate functionality to SPEECHSC itself, and there are already multiple mechanisms existing (SLP, UDDI, etc) for service location and discovery. Brian -----Message d'origine----- De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la part de Jean Philippe Longeray Envoyé : Tuesday, December 17, 2002 08:33 À : Skip Cave; speechsc@ietf.org Cc : eburger@snowshore.com Objet : RE: [Speechsc] SPEECHSC vs 3GPP Hi skip, You're right, I didn't say something different. Like MRCP, SPEECHSC is a media command protocol. SIP is not only a streaming protocol, It can be used as a transport protocol, like HTTP, X.224, ... If SIP transports SDP, it becomes a streaming protocol, but what don't you thing it's not possible to transport SPEECHSC messages in SIP Content. In your document, something is missing: You need something to find an Resource Server (ASR, SVI, TTS), and I propose to use SIP softswitching, This softswitch could be inserted between your Application Execution Server and all others voice resource (It could be ASR, TTS, SVI, but also Audio/Video streaming, conferencing, ....) I think that draft-robinson-mrcp-sip-00 is a great example that I want to say. Do you agree Eric? Best regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: lundi 16 décembre 2002 20:47 To: speechsc@ietf.org Cc: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Subject: RE: [Speechsc] SPEECHSC vs 3GPP Eric, Jean, It's good that we agree. I believe that there has been some confusion in the past that SpeechSC is a media streaming protocol. We need to list the basic issues to make sure that we clear up that misconception: 1) SpeechSC is NOT a media streaming protocol. 2) The SpeechSC protocol is strictly a command/response protocol, carrying commands and returning responses from application servers to speech servers. The SpeechSC protocol will never be a media transport protocol, and will never carry any type of media. 3) Even though the SpeechSC protocol is not a media transport protocol, the SpeechSC protocol can be used to COMMAND speech servers to set up streaming with another server using some type of streaming protocol (like SIP). Which streaming protocol is used will be determined as part of the SpeechSC's work. For example, in my attached architecture diagram, the SpeechSC protocol allows an Application Server commanding an ASR server to set up a SIP session between the ASR server and a telephony platform (see attached figure). Note that there is a SpeechSC command/control session between the Application Server and the ASR Server, but there is no streaming media going betweeen the Application & ASR Servers. There IS a standard SIP session between the Speech server and the Telephony platform, that was set up by commands given in the SpeechSC protocol. This SIP session does NOT carry any commands other than standard SIP setup/teardown commands. An example of the command/response sequence in a SpeechSC Command stream would be: Request from Application server to Directory Services for an ASR server Reply from Directory Services To Application Server giving info on specific ASR Server Command from Application Server to ASR Server to set up a specific command/ response session for a call (one command session per call context) Response from ASR Server to Application Server acknowledging the completion of the session set-up. Command from Application Server to selected ASR server to set up SIP session with a specific Telephony Server. The App Server gives the ASR server the addresses of the Telephony Server so the App Server can set up the SIP session. (ASR Server sets up SIP Session to Telephony Server)) Response from ASR Server indicating successful SIP session setup. Command from Application Server to ASR Server to set up grammars and start recognition on ASR Server. Response from ASR Server to Application Server reporting a grammar match or timeout from ASR Server. etc. Again, this is shown in mu attached diagram. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Eric Burger" 12/16/02 08:29AM >>> From a personal perspective, the MRCP over SIP proposal was what pushed me over the edge to fix MRCP. I would be hard pressed to try to convince the IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, ... We need to pick the one that makes the most sense. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Monday, December 16, 2002 3:12 AM To: Skip Cave; Eric Burger Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Hi Skip, Nice to have some news from Intervoice... I agree. SIP will never provide multimedia control functionnalities, but I'm sure it's a great protocol from transport (and mandatory for 3G). WG has to define a couple of protocols, like MRCP/RTSP. What do you think of SPEECHSC/SIP, which can be very closed from MRCP/SIP. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: vendredi 13 décembre 2002 19:38 To: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP Jean, Eric, I don't think SIP will support the separated media/control requirements I posted earlier. You will need a control protocol, and a separate media protocol. I expect that it will take a new protocol to meet these requirements. Skip Cave Sr. Principal Engineer Intervoice Inc. >>> "Jean Philippe Longeray" 12/13/02 01:25AM >>> Thanks Eric for this analyze, I agree. H.248 doesn't seems to be the right answer for MRFC/MRFP, even if special packages can be provided. For my opinion, SIP is the correct answer for transport layer (since it's used everywhere in 3GPP and 3GPP2), and SPEECHSC could (should?) be used for resource control. Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing Protocols", I would like to add some remarks: In case of you would like to insert a routing mechanism (a SIP soft-switch) between Media Processing Entity / Application server and Resource server (ASR, SI/SV, TTS, Announcement server), I could be interesting to have a single transport protocol, like SIP, instead of several incompatible protocols (RTSP for example) for the closes functionalities. I think it is easier to add some redundancy, rather than conserving "old" protocols like RTSP. It seems to be very important to make distinctions between each layers of model. Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC, could be an answer. Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: vendredi 13 décembre 2002 03:13 To: Jean Philippe Longeray Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] SPEECHSC vs 3GPP The Mp interface is (1) not the right concept and (2) is itself (IMHO) not the correct choice for 3GPP's needs, either. With respect to (1), Mp is trying to be an analog to the MGC/MG decomposition for a media server, where the MRFC is a "media server controller" and the MRFP is a "media server [processor]". The types of resources are bearer packet processors (e.g., tone detection, prompt playing, and recording). The protocol is a low-level device control protocol (e.g., allocate a resource, allocate a RTP port, connect the port to the resource, wait for a signal, etc.). speechsc is a higher-level protocol, concerned with things like 'establish session' and 'recognize speech'. In fact, early in the days of MRCP/speechsc, people wanted to extend the speechsc scope to do device control. The answer has consistently been to use H.248 for device control. With respect to (2), AFAIK, no one has ever built a MRFC. I believe this is because unlike a media gateway, where there are definite decomposition benefits, there are really few if any benefits to decomposing the MRF. In fact, there are clear benefits to using the native application interface (SIP), rather than the native gateway interface (H.248) for interfacing the AS and CSCF to the MRF. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 10, 2002 5:53 AM To: IETF SPEECHSC (E-mail) Subject: [Speechsc] SPEECHSC vs 3GPP Hi, Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229 Rel5) architecture. It looks like SPEECHSC is very closed from Mp interface (H.248). Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) , 3G.IP (www.3gip.org), MWIF (www.mwif.org)? Regards. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 16:33:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24509 for ; Tue, 17 Dec 2002 16:33:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHLaDG05968 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 16:36:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHLaDv05965 for ; Tue, 17 Dec 2002 16:36:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24486 for ; Tue, 17 Dec 2002 16:33:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHLT9v05629; Tue, 17 Dec 2002 16:29:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHLS2v05588 for ; Tue, 17 Dec 2002 16:28:02 -0500 Received: from gremg1.net.external.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24276 for ; Tue, 17 Dec 2002 16:24:54 -0500 (EST) Received: from garonne.grenoble.hp.com (garonne.grenoble.hp.com [15.128.14.138]) by gremg1.net.external.hp.com (Postfix) with ESMTP id E837F25; Tue, 17 Dec 2002 22:27:53 +0100 (MET) Received: by garonne.grenoble.hp.com with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Dec 2002 22:27:53 +0100 Message-ID: <468579AFDE99E74DB926952FCDE3D657017CA7AE@dumas.grenoble.hp.com> From: "BRANDT,MARC (HP-France,ex2)" To: Eric Burger , Jean Philippe Longeray Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP] Date: Tue, 17 Dec 2002 22:27:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBHLS2v05589 Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I tend to agree that routing the speechsc control messages among several resources is an important need, and that sharing resources among applications certainly leaves room to some valuable solutions. This is the key problems that product implementers need to deliver. But also as expressed in the speechsc requirements this may certainly rely on existing protocol properties (service discovery, location servers, dns....), which for instance SIP clearly takes advantage of, like in your example (a class of ASR in the URI and so on). I also tend to agree that the presence, or not, of intermediate nodes in the architecture is more an implementation choice and that speechsc shall not prevent nor enforce such a needs. As long as they do not bring a clear functional needs to the architecture, I mean not simply (although not so simple ;-) for handling scalability or other properties of the solution. This can typically be of value to some product solutions, like the load balancers, the cache servers were for the web and so on... What was put in the requirements is that speechsc may define extra mechanisms for load balancing but this may not impose a new box for every possible implementation, but only extra facility so that the underlying framework can do the routing more efficiently. > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Tuesday, December 17, 2002 7:00 PM > To: Jean Philippe Longeray > Cc: BRANDT,MARC (HP-France,ex2); speechsc@ietf.org > Subject: RE: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP] > > > The concept is OK. The terminology is a non-starter. Most > people assume a softswitch is a media gateway controller. > See . > > However, I again ask, does having an application switch (to > use Internet terminology) have any bearing on speechsc? It > shouldn't. The whole point of using IP is that transport and > distribution is transparent to our application-layer [sic; I > know we're tsv] protocol. > > > -----Original Message----- > > From: Jean Philippe Longeray > > [mailto:jean-philippe.longeray@netcentrex.net] > > Sent: Tuesday, December 17, 2002 12:39 PM > > To: BRANDT,MARC (HP-France,ex2); Eric Burger; speechsc@ietf.org > > Cc: Skip Cave > > Subject: RE: [Speechsc] RE: speechsc model [was RE: > SPEECHSC vs 3GPP] > > > > > > I think that it is very similar to establish a session > > between a SPR (Speech > > Processing resource) and an AE (Application equipment) than > > to establish a > > connection between two others components (like a SIP GW and an AE). > > You always need to route messages between 2 entities. DNS is > > not a good > > answer, softswitch could be. > > > > Example > > > > > > INVITE ASR@SPR.com SIP 2.0 > > From : > > To : > > > > ... > > > > Can be routed by any soft switch, to find ASR resource... > so interface > > between AE/SOSW is SIP and between SOSW/SP is SIP also. > > > > By experience, I know that sharing Resources between many AE > > is a great > > challenge! > > > > Regards. > > > > > > Jean-Philippe LONGERAY > > R&D Director - Service NODE > > > > NetCentrex > > > > Jean-philippe.longeray@netcentrex.net > > > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > > Mobile: + 33 6 76 48 34 95 > > http://www.netcentrex.net > > > > > > > > -----Original Message----- > > From: BRANDT,MARC (HP-France,ex2) [mailto:marc.brandt@hp.com] > > Sent: mardi 17 décembre 2002 18:31 > > To: Jean Philippe Longeray; Eric Burger; speechsc@ietf.org > > Cc: Skip Cave > > Subject: RE: [Speechsc] RE: speechsc model [was RE: > SPEECHSC vs 3GPP] > > > > > > > > could you clarify the definition of softswitch in this architecture > > and the possible interface between App entity and the sosw ? > > > > > > > -----Original Message----- > > > From: Jean Philippe Longeray > > > [mailto:jean-philippe.longeray@netcentrex.net] > > > Sent: Tuesday, December 17, 2002 5:59 PM > > > To: Eric Burger; speechsc@ietf.org > > > Cc: Skip Cave > > > Subject: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP] > > > > > > > > > Thank you eric, > > > > > > 1) What do you think of: > > > > > > > > > > > > > +-------------+ > > | application |_________ > > | entity | \ > > +-------------+ +-------------+ > > : + Soft switch + > > : +-------------+ > > \ speechsc > > +-------------+ > > : \---------------| > > Speech |+ > > : whatever | > > Processing ||+ > > : ---------------| > > Resource(s) ||| > > : / RTP > > +-------------+|| > > : / > > +-------------+| > > +----------+ / > > +-------------+ > > | RTP | / > > | entity |----------- > > +----------+ > > > > > > > > > > > > > > > > In this case Soft switch can be used to select the right > > > speech processing > > > resource. > > > > > > 2) As speech processing resources, you think : > > > - ASR > > > - TTS > > > - speaker verif. > > > > > > Do you think we could be able to use also : streaming audio, > > > video, fax > > > (T.38) > > > > > > 3) "Whatever" could be MGCP, or H.248 > > > > > > 4) RTP entity could be : > > > - RTP Proxy > > > - RTP conference > > > - RTP duplicator > > > - RTP transcoder > > > > > > > > > > > > Best regards. > > > > > > > > > Jean-Philippe LONGERAY > > > R&D Director - Service NODE > > > > > > NetCentrex > > > > > > Jean-philippe.longeray@netcentrex.net > > > > > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > > > Mobile: + 33 6 76 48 34 95 > > > http://www.netcentrex.net > > > > > > > > > > > > -----Original Message----- > > > From: Eric Burger [mailto:eburger@snowshore.com] > > > Sent: mardi 17 décembre 2002 16:22 > > > To: speechsc@ietf.org > > > Cc: Jean Philippe Longeray; Skip Cave > > > Subject: speechsc model [was RE: SPEECHSC vs 3GPP] > > > > > > > > > On the use of SIP for MRCP transport: > > > draft-robinson-mrcp-sip-00 is what > > > drove me to realize that the MRCP tunneling approach was > > > broken. That is > > > not to say that it would be wrong to raise MRCP into SIP. > > > However, given > > > the existing semantics for RTSP and TTS, that may be a better > > > way to go. On > > > the other hand, the answer to your question is, "yes": the > > > Robinson draft > > > shows SIP for signaling, not media. > > > > > > On the speechsc model, how does this look: > > > > > > > > > > > > +-------------+ > > > | application |_________ > > > | entity | \ > > > +-------------+ \ > > > : \ speechsc > > > +-------------+ > > > : \---------------| > > > Speech |+ > > > : whatever | > > > Processing ||+ > > > : ---------------| > > > Resource(s) ||| > > > : / RTP > > > +-------------+|| > > > : / > > > +-------------+| > > > +----------+ / > > > +-------------+ > > > | RTP | / > > > | entity |----------- > > > +----------+ > > > > > > > > > The speechsc perspective on the world has really only > three logical > > > elements. There is an application entity, which can be (for > > > example ONLY) > > > an application server, a VoiceXML browser, a SALT browser, a > > > Java Bean, a > > > handset, a media server, etc. There is a RTP entity, which > > > is a source of > > > RTP for the speech processing resource, which can be (for > > > example ONLY) a > > > phone, a media gateway, a VoiceXML or SALT browser, etc. > > > Speech processing > > > resources are the ASR, TTS, and SI/SV engines. Note the > > > application entity > > > and RTP entity may be combined, decomposed, or have various > > > bits decomposed > > > and combined. > > > > > > Do we care about rearranging or embellishing these three > > > basic components? > > > I don't think it will materially affect the protocol analysis. > > > > > > > > > -----Original Message----- > > > From: Jean Philippe Longeray > > > [mailto:jean-philippe.longeray@netcentrex.net] > > > Sent: Tuesday, December 17, 2002 2:33 AM > > > To: Skip Cave; speechsc@ietf.org > > > Cc: Eric Burger > > > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > > > > > > > Hi skip, > > > > > > You're right, I didn't say something different. > > > > > > Like MRCP, SPEECHSC is a media command protocol. SIP is not > > > only a streaming > > > protocol, It can be used as a transport protocol, like HTTP, > > > X.224, ... If > > > SIP transports SDP, it becomes a streaming protocol, but what > > > don't you > > > thing it's not possible to transport SPEECHSC messages in > > SIP Content. > > > > > > In your document, something is missing: You need something > > to find an > > > Resource Server (ASR, SVI, TTS), and I propose to use SIP > > > softswitching, > > > This softswitch could be inserted between your Application > > > Execution Server > > > and all others voice resource (It could be ASR, TTS, SVI, but also > > > Audio/Video streaming, conferencing, ....) > > > > > > > > > I think that draft-robinson-mrcp-sip-00 is a great example > > > that I want to > > > say. Do you agree Eric? > > > > > > Best regards. > > > > > > Jean-Philippe LONGERAY > > > R&D Director - Service NODE > > > > > > NetCentrex > > > > > > Jean-philippe.longeray@netcentrex.net > > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > > > Mobile: + 33 6 76 48 34 95 > > > http://www.netcentrex.net > > > > > > -----Original Message----- > > > From: Skip Cave [mailto:skip.cave@intervoice.com] > > > Sent: lundi 16 décembre 2002 20:47 > > > To: speechsc@ietf.org > > > Cc: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com > > > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > > > > > > > Eric, Jean, > > > > > > It's good that we agree. I believe that there has been some > > > confusion in the > > > past that SpeechSC is a media streaming protocol. We need to > > > list the basic > > > issues to make sure that we clear up that misconception: > > > > > > 1) SpeechSC is NOT a media streaming protocol. > > > 2) The SpeechSC protocol is strictly a command/response > > > protocol, carrying > > > commands and returning responses from application servers to > > > speech servers. > > > The SpeechSC protocol will never be a media transport > > > protocol, and will > > > never carry any type of media. > > > 3) Even though the SpeechSC protocol is not a media transport > > > protocol, the > > > SpeechSC protocol can be used to COMMAND speech servers to > > > set up streaming > > > with another server using some type of streaming protocol > > > (like SIP). Which > > > streaming protocol is used will be determined as part of the > > > SpeechSC's > > > work. > > > > > > For example, in my attached architecture diagram, the > > > SpeechSC protocol > > > allows an Application Server commanding an ASR server to > > set up a SIP > > > session between the ASR server and a telephony platform > > (see attached > > > figure). Note that there is a SpeechSC command/control > > > session between the > > > Application Server and the ASR Server, but there is no > > > streaming media going > > > betweeen the Application & ASR Servers. There IS a standard > > > SIP session > > > between the Speech server and the Telephony platform, that > > > was set up by > > > commands given in the SpeechSC protocol. This SIP session > > > does NOT carry any > > > commands other than standard SIP setup/teardown commands. > > > > > > An example of the command/response sequence in a SpeechSC > > > Command stream > > > would be: > > > > > > Request from Application server to Directory Services for an > > > ASR server > > > Reply from Directory Services To Application Server giving > > > info on specific > > > ASR Server > > > Command from Application Server to ASR Server to set up a > > > specific command/ > > > response session for a call (one command session per call context) > > > Response from ASR Server to Application Server acknowledging > > > the completion > > > of the session set-up. > > > Command from Application Server to selected ASR server to set > > > up SIP session > > > with a specific Telephony Server. The App Server gives the > > > ASR server the > > > addresses of the Telephony Server so the App Server can set > > up the SIP > > > session. > > > (ASR Server sets up SIP Session to Telephony Server)) > > > Response from ASR Server indicating successful SIP session setup. > > > Command from Application Server to ASR Server to set up > > > grammars and start > > > recognition on ASR Server. > > > Response from ASR Server to Application Server reporting a > > > grammar match or > > > timeout from ASR Server. > > > etc. > > > > > > Again, this is shown in mu attached diagram. > > > > > > Skip Cave > > > Sr. Principal Engineer > > > Intervoice Inc. > > > > > > > > > >>> "Eric Burger" 12/16/02 08:29AM >>> > > > >From a personal perspective, the MRCP over SIP proposal was > > > what pushed me > > > over the edge to fix MRCP. I would be hard pressed to try to > > > convince the > > > IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, > > > ... We need to > > > pick the one that makes the most sense. > > > > > > -----Original Message----- > > > From: Jean Philippe Longeray > > > [mailto:jean-philippe.longeray@netcentrex.net] > > > Sent: Monday, December 16, 2002 3:12 AM > > > To: Skip Cave; Eric Burger > > > Cc: speechsc@ietf.org > > > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > > > > > > > Hi Skip, > > > > > > Nice to have some news from Intervoice... > > > > > > I agree. SIP will never provide multimedia control > > > functionnalities, but > > > I'm sure it's a great protocol from transport (and > > mandatory for 3G). > > > WG has to define a couple of protocols, like MRCP/RTSP. What > > > do you think of > > > SPEECHSC/SIP, which can be very closed from MRCP/SIP. > > > > > > Regards. > > > > > > > > > Jean-Philippe LONGERAY > > > R&D Director - Service NODE > > > > > > NetCentrex > > > > > > Jean-philippe.longeray@netcentrex.net > > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > > > Mobile: + 33 6 76 48 34 95 > > > http://www.netcentrex.net > > > > > > -----Original Message----- > > > From: Skip Cave [mailto:skip.cave@intervoice.com] > > > Sent: vendredi 13 décembre 2002 19:38 > > > To: jean-philippe.longeray@netcentrex.net; eburger@snowshore.com > > > Cc: speechsc@ietf.org > > > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > > > > > > > Jean, Eric, > > > > > > I don't think SIP will support the separated media/control > > > requirements I > > > posted earlier. You will need a control protocol, and a > > separate media > > > protocol. I expect that it will take a new protocol to meet these > > > requirements. > > > > > > Skip Cave > > > Sr. Principal Engineer > > > Intervoice Inc. > > > > > > > > > >>> "Jean Philippe Longeray" > > > > 12/13/02 01:25AM >>> > > > Thanks Eric for this analyze, > > > > > > I agree. H.248 doesn't seems to be the right answer for > > > MRFC/MRFP, even if > > > special packages can be provided. > > > > > > For my opinion, SIP is the correct answer for transport layer > > > (since it's > > > used everywhere in 3GPP and 3GPP2), and SPEECHSC could > > > (should?) be used for > > > resource control. > > > > > > Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing > > > Protocols", I would > > > like to add some remarks: > > > > > > In case of you would like to insert a routing mechanism (a > > > SIP soft-switch) > > > between Media Processing Entity / Application server and > > > Resource server > > > (ASR, SI/SV, TTS, Announcement server), I could be > > > interesting to have a > > > single transport protocol, like SIP, instead of several > incompatible > > > protocols (RTSP for example) for the closes functionalities. > > > I think it is > > > easier to add some redundancy, rather than conserving "old" > > > protocols like > > > RTSP. > > > > > > It seems to be very important to make distinctions between > > > each layers of > > > model. > > > Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or > > > SCTP/SIP/SPEECHSC, > > > could be an answer. > > > > > > > > > > > > Regards. > > > > > > > > > Jean-Philippe LONGERAY > > > R&D Director - Service NODE > > > > > > NetCentrex > > > > > > Jean-philippe.longeray@netcentrex.net > > > > > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > > > Mobile: + 33 6 76 48 34 95 > > > http://www.netcentrex.net > > > > > > > > > > > > -----Original Message----- > > > From: Eric Burger [mailto:eburger@snowshore.com] > > > Sent: vendredi 13 décembre 2002 03:13 > > > To: Jean Philippe Longeray > > > Cc: IETF SPEECHSC (E-mail) > > > Subject: RE: [Speechsc] SPEECHSC vs 3GPP > > > > > > > > > The Mp interface is (1) not the right concept and (2) is > > > itself (IMHO) not > > > the correct choice for 3GPP's needs, either. > > > > > > With respect to (1), Mp is trying to be an analog to the MGC/MG > > > decomposition for a media server, where the MRFC is a > "media server > > > controller" and the MRFP is a "media server [processor]". > > > The types of > > > resources are bearer packet processors (e.g., tone > detection, prompt > > > playing, and recording). The protocol is a low-level > device control > > > protocol (e.g., allocate a resource, allocate a RTP port, > > > connect the port > > > to the resource, wait for a signal, etc.). speechsc is a > > higher-level > > > protocol, concerned with things like 'establish session' and > > > 'recognize > > > speech'. > > > > > > In fact, early in the days of MRCP/speechsc, people wanted to > > > extend the > > > speechsc scope to do device control. The answer has > > > consistently been to > > > use H.248 for device control. > > > > > > With respect to (2), AFAIK, no one has ever built a MRFC. I > > > believe this is > > > because unlike a media gateway, where there are definite > > decomposition > > > benefits, there are really few if any benefits to decomposing > > > the MRF. In > > > fact, there are clear benefits to using the native > > > application interface > > > (SIP), rather than the native gateway interface (H.248) for > > > interfacing the > > > AS and CSCF to the MRF. > > > > > > -----Original Message----- > > > From: Jean Philippe Longeray > > > [mailto:jean-philippe.longeray@netcentrex.net] > > > Sent: Tuesday, December 10, 2002 5:53 AM > > > To: IETF SPEECHSC (E-mail) > > > Subject: [Speechsc] SPEECHSC vs 3GPP > > > > > > > > > Hi, > > > > > > Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP > > > (TS 24.229 > > > Rel5) architecture. > > > > > > It looks like SPEECHSC is very closed from Mp interface (H.248). > > > > > > Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 > > (www.3gpp2.org) , > > 3G.IP (www.3gip.org), MWIF (www.mwif.org)? > > > > Regards. > > > > Jean-Philippe LONGERAY > > R&D Director - Service NODE > > > > NetCentrex > > > > Jean-philippe.longeray@netcentrex.net > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > > Mobile: + 33 6 76 48 34 95 > > http://www.netcentrex.net > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 18:34:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26645 for ; Tue, 17 Dec 2002 18:34:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHNabl12695 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 18:36:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHNaav12692 for ; Tue, 17 Dec 2002 18:36:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26639 for ; Tue, 17 Dec 2002 18:33:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHNaTv12684; Tue, 17 Dec 2002 18:36:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHNZ5v12638 for ; Tue, 17 Dec 2002 18:35:05 -0500 Received: from mail2.intervoice-brite.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26625 for ; Tue, 17 Dec 2002 18:31:57 -0500 (EST) Received: from 172.16.16.64 (gwsmtpsrv.intervoice.com [172.16.16.64]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with SMTP id RAA03676 for ; Tue, 17 Dec 2002 17:48:42 -0600 Received: from INTERVOICE-Message_Server by 172.16.16.64 with Novell_GroupWise; Tue, 17 Dec 2002 17:34:55 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Tue, 17 Dec 2002 17:34:22 -0600 From: "Skip Cave" To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_91CD5E8F.9EFFAC4D" Subject: [Speechsc] speechsc protocol issues Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_91CD5E8F.9EFFAC4D Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Here are my comments on several of the issues discussed in the last few = posts: SpeechSC & media transport The basic problem with trying to add speech server control messages to a = media transport protocol such as RTSP or SIP is that in the speechsc = architecture, the command channel between the appication server and the = speech server DOES NOT CARRY ANY MEDIA, streaming or otherwise! So, there = is no reason to use a media transport protocol such as RTSP or SIP/RTP to = "pigyback" media commands on. When there is no media to carry, whay use a = media protocol at all?=20 There may be media going from the Speech resource to a telephony server = (the RTP entity in Eric's picture), but no media goes to the application = entity. Eric's pictutre of the blocks show it pretty well:=20 +-------------+ | application |_________ | entity | \ +-------------+ \ speechsc : \ (no media) +-------------+ : \---------------| Speech |+ : whatever | Processing ||+ : ---------------| Resource(s) ||| : / RTP +-------------+|| : / +-------------+| +----------+ / +-------------+ | RTP | / | entity |----------- +----------+ Notice that there is no media going from the application entity to the = speech resources. So, there is no need for a media transport protocol to = piggyback the control commands onto. In fact, the entity requiring media = streams (RTP entity) may be in a completely different location from the = application entity. Existing media transport protocols such as SIP and = RTSP do not support this kind of separation between the control session = and the media transport. For that matter, the Speech processing resource may itself be distributed, = so that the speech control entity that is being commanded by the speechsc = session may not be the entity that sources or sinks the media! The picture = would look something like this... +-------------+ speechsc +-------------+ | application |----------------------------| Speech | | entity | | Server | +-------------+ | Controller | : +-------------+ : : : : /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Wide Area Network /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ : : : whatever : Internal = protocol : : Proprietary = to speech =20 : : server = vendors Phone : : Lines +----------+ RTP or SIP +-------------+ ------|Telephony |------------------------------| Speech |+ ------| entity | | Processing ||+ +----------+ | Resource(s) ||| +-------------+|| +-------------+| +-------------+ This is a fairly common scenario with the ASR vendors new distributed = architectures.=20 Because of thse issues, protocols that assume that the control session and = the media are together, such as SIP or RTSP, cannot be used for speechsc. = These media transport prococols do not have any way to separate the media = from the control session. A potential approach to this dilemma is the web services architecture. = There is no underlying assumption that SOAP commands will be accompanied = by media, so this is a step in the right direction. The speechsc protocol = could simply be a set of SOAP requests to the speech server with the = responses contained in the standard HTTP reply. Unfortunately, because = SOAP uses the HTTP request/response protocol, this makes the interface = inherently synchronous. I won't go into details here, but suffice it to = say that a synchronous protocol is not appropriate for speech server = control. SOAP has the right general idea, just not the right details.=20 To address Bryan's question:=20 > Q1: what is the best model for SPEECHSC: > - a layer OVER a media signalling protocol (SIP, RTSP, etc, depending on = this lower layer=20 >for media and session control, just like MRCP/RTSP currently does) As discussed above, speechsc cannot be placed OVER a media protocol such = as SIP RTSP, etc, because speechsc SHOULD NOT CARRY MEDIA. No need to use = a media protocol when there is no media to carry. We just need to be able = to set up a command/ response session between the application server and = the speech resources.=20 This makes the remainder of Bryan's issues about media protocols moot... > -> in which case what is the encapsulation mechanism - RTSP has = ANNOUNCE=20 > messages, what does SIP provide for this sort of bundling? > -> and what is the "best" protocol to layer over > - an extension to an existing media signalling protocol (eg, add MRCP = "verbs" as new > ones in RTSP, or add as new SIP commands...) Bryan then asks: > - [should we uuse] a new protocol incorporating both media signalling, = session=20 > control and resource control (eg Web services extensions)? =20 Skip says: The speechsc protocol does not need media signaling (in it's most common = sense), just session control with command/response messages. We do need a = way for the application server to tell the speech server (or the telephony = server) where to send his media, but this is about the extent of "media = control" in speechsc. Bryan says: > As for the identification and resolution of resource servers, this is = for me a=20 > separate functionality to SPEECHSC itself, and there are already = multiple mechanisms=20 > existing (SLP, UDDI, etc) for service location and discovery. Skip says: Absolutely. There are already plenty of discovery/ allocation protocols = out there. It would probably be useful for the speecsc group to recommend = one particular solution in the specification, if only to make life easier = for systems integrators. However this is probably not a critical issue in = the early phases. Jean Philippe said: > SIP is little bit poor for data transportation, but it exists and = clearly chosen by=20 > 3GPP and 3GPP2. For my opinion , SPEECHSC could be something very = closed from MRCP >and transported by SIP INFO method. Skip says:=20 As above, when you don't need to transport media, why use a media = transport protocol to send command/control messages? Jean Philippe said: > Speechsc, like MRCP must only define the media control part and the way = how it can=20 > be transported by SIP (and optionally by others protocols like H.225.0, = RTSP, H.248,=20 Skip says: There's no reason to go to all the trouble trying to figure out how to put = media control messages on top of a media protocol, if you don't need to = carry media. =20 Jean Philippe said: > All media resources could be controlled by the same protocol (SPEECHSC). = At the=20 > streaming side, RTP/RTCP is of course engaged. I'm sure that a MutliMedia= VOIP core=20 > with optional peripheral gateways is the Next Gen architecture for = Telephony. Skip says:=20 The telephony server, or softswitch, or VOIP gateway, or whatever, will = definitely need to deal with media streams. However this entity will NOT = need to deal with speech resource control commands. Clearly RTP is a = front-runner in the protocol race, to carry the media from the speech = resource to the telephony interface. The interesting question is whether = we need to encapsulate RTP in a session protocol such as SIP, or whether a = basic, stripped-down RTP protocol is suficient to carry the media between = the speech servers and the telephony interface. If we decide on pure RTP, then speechsc will have to take on some SIP-like = qualities. This will probably add considerable to the work required to get = out a spec.=20 I suspect that it will be much easier to have speechsc simply to set up a = SIP session between the two entities requiring media connections, and let = SIP do the rest. This means that both the speech server and the telephony = entity (softswitch, VOIP gateway, Intel/Dialogic card, etc.) will have to = support the SIP protocol. Luckily, this is an absolutely STOCK SIP = protocol, no extensions needed.=20 Jean Philippe said: > An extension of MRCP could be the answer. It is a great protocol, isn't = it?=20 > And It already works over RTSP (Nuance, Speechworks, Telisma...) =20 > Find bellow some extension of MRCP, SPEECHSC could cover: > - speaker verification, > - speaker identification, > - announcement, voice recording,=20 > - tones detection, tones generation, > - fax, > - audio conferencing, > - video conferencing, > - chat Skip says: MRCP, or RTSP, or SIP, or extensions to these protocols can't be used for = a general speechsc protocol, because of the requirement that the media and = commands be completely separate from each other. MRCP or RTSP would be = fine if the application entity and the telephony entity resided in the = same box, but that won't be the case in many future systems. MRCP cannot = deal with the problem of remote telephony servers separate from the = application servers, as I described earlier in this discussion. We = certainly don't want to restrict future architectures to require that the = application and telephony systems must reside in the same box! Marc said: > I agree with the decomposition or unbundling model.=20 > Although there is no needs to support a multitude of protocol stacks = profiles (aka=20 > speechsc over everything), I believe speechsc needs to enable some = separation in=20 > terms of protocol layers and service interfaces (this is also a = personal good=20 > learning of previous model like OSI, TCP/IP... which are somewhat = widely adopted in=20 > the SIP, HTTP, SOAP and other work as well).=20 > Separation of Control pipe and media pipe is also at the heart of modern = telecoms. =20 Skip says:=20 Absolutely! Spoken like a true believer. In fact. speechsc should be = separated by more than a layered architecure. Speechsc shold be strictly a = command/response protocol. No media in any of the layers. Now, within the = speechsc commands you can have a request for the speech server (or the = telephony server) to send a media stream somewhere. The stream can = originate anywhere, and terminate anywhere else. This is a close as = speechsc should get to media stream control.=20 Marc said: > Now in terms of technology I guess there are advantages in the likes of = SIP, SOAP,=20 > XML (anyway already widely used at the speech grammar or synthesis level = in the MRCP=20 > packets for instance), with all the extensibility and programmability = that they=20 > provide.=20 > For instance, SIP can be extended, see the SIPPING an SIMPLE work to = provide open=20 > framework for other semantic to be built on top of it. SOAP clearly = provides a good=20 > invocation model for a 'programmable' framework. Skip says: I believe that speechsc's command/response protocol can be defined as a = set of XML messages. This is probably as open a way of building the = protocol as any. Now this doesn't mean that SOAP is the best transport = mechanism. SOAP's synchronous attributes prevent the asynchronous control = functionality needed by speechsc. I expect that we will come to find that = a SOAP-like xml message structure, over a more general socket-type = protocol (instead of SOAP's HTTP) will be the best tradeoff for = speechsc.=20 As far as the media protocol is concerned, un-modified SIP is probably the = best candidate to set up and carry the audio between the speech servers = and the telephony interfaces. So, speechsc would be SOAP-like xml messages = over a socket-like protocol between the application server and the speech = servers. Meanwhile, un-modified SIP would set up and carry the media = between the speech resources and the telephony interfaces. Skip Cave Sr. Principal Engineer Intervoice Inc. --=_91CD5E8F.9EFFAC4D Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: quoted-printable
Here are my comments on several of the issues = discussed in the=20 last few posts:
 
SpeechSC & media transport
 
The basic problem with trying to add speech server = control=20 messages to a media transport protocol such as RTSP or SIP is that in = the=20 speechsc architecture, the command channel between the appication server = and the=20 speech server DOES NOT CARRY ANY MEDIA, streaming or otherwise! So, there = is no=20 reason to use a media transport protocol such as RTSP or SIP/RTP to = "pigyback"=20 media commands on. When there is no media to carry, whay use a media = protocol at=20 all?
 
There may be media going from the Speech resource to = a=20 telephony server (the RTP entity in Eric's picture), but no media goes to = the=20 application entity.
 
Eric's pictutre of the blocks show it pretty well:=20
 
           =  =20 +-------------+
         &n= bsp;  =20 | application=20 |_________
          &= nbsp; =20 |   entity   =20 |        =20 \
           &nbs= p;=20 +-------------+         =20 \   =20 speechsc
          &nb= sp;        =20 :            &n= bsp;    =20 \   (no media)  =20 +-------------+
         &n= bsp;         =20 :            &n= bsp;     =20 \---------------| Speech     =20 |+
           &nb= sp;       =20 :=20 whatever           &= nbsp;           &nbs= p; =20 | Processing =20 ||+
           &n= bsp;       =20 :            &n= bsp;      =20 ---------------| Resource(s)=20 |||
           &n= bsp;       =20 :            &n= bsp;     =20 /     RTP      =20 +-------------+||
         =           =20 :            &n= bsp;    =20 /            &n= bsp;   =20 +-------------+|
         &= nbsp;   =20 +----------+          &nb= sp;=20 /            &n= bsp;     =20 +-------------+
         &n= bsp;   =20 |   RTP   =20 |          =20 /
           &nbs= p; =20 |  entity =20 |-----------
          = ;   =20 +----------+
 
Notice that there is no media going from the applicatio= n=20 entity to the speech resources. So, there is no need for a media = transport=20 protocol to piggyback the control commands onto. In fact, the entity = requiring=20 media streams (RTP entity) may be in a completely different location from = the=20 application entity. Existing media transport protocols such as SIP and = RTSP do=20 not support this kind of separation between the control session and the = media=20 transport.
 

For that matter, the Speech processing resource may itself be=20 distributed, so that the speech control entity that is being commanded by = the=20 speechsc session may not be the entity that sources or sinks the media! = The=20 picture would look something like this...
 

         =20 +-------------+         =20 speechsc         =20 +-------------+
          = |=20 application |----------------------------| Speech    &n= bsp;=20 |
          |=20 entity     =20 |            &n= bsp;            = ;  =20 | Server     =20 |
         =20 +-------------+          =             &nb= sp;    =20 | Controller =20 |
           &nbs= p;    =20 :            &n= bsp;            = ;         =20 +-------------+
         &n= bsp;      =20 :            &n= bsp;            = ;            &n= bsp;  =20 :
           &nbs= p;    =20 :            &n= bsp;            = ;            &n= bsp;  =20 :
    =20 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
&nb= sp;            =             &nb= sp;     =20 Wide Area Network
    =20 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
&n= bsp;            = ;   =20 :            &n= bsp;            = ;            &n= bsp;  =20 :
           &nbs= p;    =20 :=20 whatever           &= nbsp;           &nbs= p;       =20 :   Internal=20 protocol
          &nb= sp;     =20 :            &n= bsp;            = ;            &n= bsp;  =20 :   Proprietary to speech =20
            = ;    =20 :            &n= bsp;            = ;            &n= bsp;  =20 :   server vendors
    =20 Phone      =20 :            &n= bsp;            = ;            &n= bsp;  =20 :
     Lines=20 +----------+           = RTP or=20 SIP        =20 +-------------+
     ------|Telephony=20 |------------------------------| Speech     =20 |+
     ------|  entity =20 |            &n= bsp;            = ;    =20 | Processing =20 ||+
          =20 +----------+          &nb= sp;            =       =20 | Resource(s)=20 |||
           &n= bsp;            = ;            &n= bsp;            = ;   =20 +-------------+||
         =             &nb= sp;            =             &nb= sp;      =20 +-------------+|
         &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       =20 +-------------+
 
This is a fairly common scenario with the ASR vendors new distributed= =20 architectures.
 
Because of thse issues, protocols that assume that the control = session and=20 the media are together, such as SIP or RTSP, cannot be used for speechsc. = These=20 media transport prococols do not have any way to separate the media from = the=20 control session.
 
A potential approach to this dilemma is the web services architecture.= =20 There is no underlying assumption that SOAP commands will be accompanied = by=20 media, so this is a step in the right direction. The speechsc protocol = could=20 simply be a set of SOAP requests to the speech server with the responses=20= contained in the standard HTTP reply. Unfortunately, because SOAP uses the = HTTP=20 request/response protocol, this makes the interface inherently synchronous.= I=20 won't go into details here, but suffice it to say that a synchronous = protocol is=20 not appropriate for speech server control. SOAP has the right general = idea, just=20 not the right details.
 
To address Bryan's question:
 
> Q1: what is the best model for SPEECHSC:
> - a layer OVER = a=20 media signalling protocol (SIP, RTSP, etc, depending on this lower layer =
>for media and session control, just like MRCP/RTSP currently=20 does)
 
As discussed above, speechsc cannot be placed OVER a media protocol = such as=20 SIP RTSP, etc, because speechsc SHOULD NOT CARRY MEDIA. No need to use a = media=20 protocol when there is no media to carry. We just need to be able to set = up a=20 command/ response session between the application server and the speech=20 resources.
 
This makes the remainder of Bryan's issues about media protocols=20 moot...
 
>    -> in which case what is the encapsulation= =20 mechanism - RTSP has ANNOUNCE
> messages, what  does SIP provide for this sort of=20 bundling?
>    -> and what is the "best" protocol = to=20 layer over
> - an extension to an existing media signalling protocol = (eg,=20 add MRCP "verbs" as new
> ones in RTSP, or add as new SIP commands...)
 
Bryan then asks:
 
> - [should we uuse] a new protocol incorporating both media = signalling,=20 session
> control and resource control (eg Web services=20 extensions)?
 
Skip says:
The speechsc protocol does not = need=20 media signaling (in it's most common sense), just session control with=20 command/response messages. We do need a way for the application server to = tell=20 the speech server (or the telephony server) where to send his media, but = this is=20 about the extent of "media control" in speechsc.
 
Bryan says:
> As for the identification and resolution of = resource=20 servers, this is for me a
> separate functionality to SPEECHSC itself, and there are = already=20 multiple mechanisms
> existing (SLP,  UDDI, etc) for service location and=20 discovery.
 
Skip says:
Absolutely. There are already plenty of discovery/ = allocation=20 protocols out there. It would probably be useful for the speecsc group = to=20 recommend one particular solution in the specification, if only to make = life=20 easier for systems integrators. However this is probably not a critical = issue in=20 the early phases.
 

Jean Philippe said:
> SIP is little bit poor for data=20 transportation, but it exists and clearly chosen by
> 3GPP and 3GPP2. For my opinion ,  SPEECHSC could be = something=20 very closed from MRCP
>and transported by SIP  INFO method.
 
Skip says:
As above, when you don't need to transport media, why = use a=20 media transport protocol to send command/control messages?
 
Jean Philippe said:
> Speechsc, like MRCP must only define the = media=20 control part and the way how it can
> be transported by SIP (and optionally by others protocols = like=20 H.225.0, RTSP, H.248,
 
Skip says:
There's no reason to go to all the trouble trying to = figure=20 out how to put media control messages on top of a media protocol, if you = don't=20 need to carry media. 
 
Jean Philippe said:
> All media resources could be controlled = by the=20 same protocol (SPEECHSC). At the
> streaming side, RTP/RTCP is of course engaged. I'm sure that = a=20 MutliMedia VOIP core
> with optional peripheral gateways is the Next Gen architecture = for=20 Telephony.
 
Skip says:
The telephony server, or softswitch, or VOIP gateway, = or=20 whatever, will definitely need to deal with media streams. However this = entity=20 will NOT need to deal with speech resource control commands. Clearly RTP = is a=20 front-runner in the protocol race,  to carry the media from the = speech=20 resource to the telephony interface. The interesting question is whether = we need=20 to encapsulate RTP in a session protocol such as SIP, or whether a = basic,=20 stripped-down RTP protocol is suficient to carry the media between the = speech=20 servers and the telephony interface.
 
If we decide on pure RTP, then speechsc will have to take on some = SIP-like=20 qualities. This will probably add considerable to the work required to get = out a=20 spec.
 
I suspect that it will be much easier to have speechsc simply to set = up a=20 SIP session between the two entities requiring media connections, and let = SIP do=20 the rest. This means that both the speech server and the telephony = entity=20 (softswitch, VOIP gateway, Intel/Dialogic card, etc.) will have to support = the=20 SIP protocol. Luckily, this is an absolutely STOCK SIP protocol, no = extensions=20 needed.
 
Jean Philippe said:
> An extension of MRCP could be the answer. = It is=20 a great protocol, isn't it?
> And It already works over RTSP (Nuance, Speechworks,=20 Telisma...)
 
> Find bellow some extension of MRCP,  = SPEECHSC=20 could cover:
> - speaker verification,
> - speaker=20 identification,
> - announcement, voice recording,
> - = tones=20 detection, tones generation,
> - fax,
> - audio=20 conferencing,
> - video conferencing,
> - chat
 
Skip says:
MRCP, or RTSP, or SIP, or extensions to these protocols = can't=20 be used for a general speechsc protocol, because of the requirement that = the=20 media and commands be completely separate from each other. MRCP or RTSP = would be=20 fine if the application entity and the telephony entity resided in the = same box,=20 but that won't be the case in many future systems. MRCP cannot deal with = the=20 problem of remote telephony servers separate from the application servers, = as I=20 described earlier in this discussion. We certainly don't want to restrict = future=20 architectures to require that the application and telephony systems must = reside=20 in the same box!
 
Marc said:
> I agree with the decomposition or unbundling = model.=20
> Although there is no needs to support a  multitude of = protocol=20 stacks profiles (aka
> speechsc over everything),  I believe speechsc needs to = enable=20 some separation in
> terms of protocol  layers and service interfaces (this is = also a=20 personal good
> learning of previous model  like OSI, TCP/IP... which = are=20 somewhat widely adopted in
> the SIP, HTTP,  SOAP and other work as well).
> = Separation=20 of Control pipe and media pipe is also at the heart of modern=20 telecoms.
 
Skip says:
Absolutely! Spoken like a true = believer.=20 In fact. speechsc should be separated by more than a layered architecure.= =20 Speechsc shold be strictly a command/response protocol. No media in any of = the=20 layers. Now, within the speechsc commands you can have a request for the = speech=20 server (or the telephony server) to send a media stream somewhere. The = stream=20 can originate anywhere, and terminate anywhere else. This is a close as = speechsc=20 should get to media stream control.
 
Marc said:
> Now in terms of technology I guess there are = advantages=20 in the likes of SIP, SOAP,
> XML (anyway already widely used at the speech grammar or = synthesis=20 level in the MRCP
> packets for instance), with all the extensibility  and=20 programmability that they
> provide.
> For instance, SIP can be extended, see the = SIPPING=20 an SIMPLE work to provide open
> framework for other semantic to be built on top of it. SOAP = clearly=20 provides a good
> invocation model for a 'programmable' framework.
 
Skip says:
I believe that speechsc's command/response protocol can = be=20 defined as a set of XML messages. This is probably as open a way of = building the=20 protocol as any. Now this doesn't mean that SOAP is the best transport=20 mechanism. SOAP's synchronous attributes prevent the asynchronous = control=20 functionality needed by speechsc. I expect that we will come to find that = a=20 SOAP-like xml message structure, over a more general socket-type = protocol=20 (instead of SOAP's HTTP) will be the best tradeoff for speechsc.
 
As far as the media protocol is concerned, un-modified SIP is = probably the=20 best candidate to set up and carry the audio between the speech servers = and the=20 telephony interfaces. So, speechsc would be SOAP-like xml messages over = a=20 socket-like  protocol between the application server and the = speech=20 servers. Meanwhile, un-modified SIP would set up and carry the media = between the=20 speech resources and the telephony interfaces.
 
Skip Cave
Sr. Principal Engineer
Intervoice Inc.
--=_91CD5E8F.9EFFAC4D-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Dec 17 19:49:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27987 for ; Tue, 17 Dec 2002 19:49:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBI0qJr17168 for speechsc-archive@odin.ietf.org; Tue, 17 Dec 2002 19:52:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI0qJv17165 for ; Tue, 17 Dec 2002 19:52:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27981 for ; Tue, 17 Dec 2002 19:49:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI0qAv17152; Tue, 17 Dec 2002 19:52:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI0p7v17124 for ; Tue, 17 Dec 2002 19:51:07 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27959 for ; Tue, 17 Dec 2002 19:47:59 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Speechsc] speechsc protocol issues Date: Tue, 17 Dec 2002 19:50:59 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D097BB2@zoe.office.snowshore.com> Thread-Topic: [Speechsc] speechsc protocol issues Thread-Index: AcKmJsrcpc+iZfaOTBSW/vnAEINTXgAB21Eg From: "Eric Burger" To: "Skip Cave" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBI0p7v17125 Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I have to disagree. Consider the following network architecture: +------------------+ +---------------+ | SS7 Gateway | SIP | Media Gateway | | (A SIP Endpoint) |------------------------------| Controller | +------------------+ +---------------+ : : : Something : H.248 : (Diameter, H.248, J.162, ...) : : : +-------------------+ RTP +---------------+ | Media Gateway |-----------------------------| Media Gateway | | (An RTP Endpoint) | +---------------+ +-------------------+ This looks to me to be the identical configuration you describe below. There is absolutely no media being transported by SIP. That is what RTP is for. These boxes are clearly different physical boxes. SS7 gateways definitely DON'T do media. I don't get the distinction you are making. SIP and RTSP *explicitly* assume the control and media legs are separate. That was a design goal that was met. On the other hand, there is a definite *correlation* between the signaling and media stream, if a media stream is present. Let's say that differently: you can have a signaling relationship without a media relationship. Take, for example, SIMPLE (please!). That correlation is the reason we use SIP and RTSP to do dialog and playback sessions. -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: Tuesday, December 17, 2002 6:34 PM To: speechsc@ietf.org Subject: [Speechsc] speechsc protocol issues Here are my comments on several of the issues discussed in the last few posts: SpeechSC & media transport The basic problem with trying to add speech server control messages to a media transport protocol such as RTSP or SIP is that in the speechsc architecture, the command channel between the appication server and the speech server DOES NOT CARRY ANY MEDIA, streaming or otherwise! So, there is no reason to use a media transport protocol such as RTSP or SIP/RTP to "pigyback" media commands on. When there is no media to carry, whay use a media protocol at all? There may be media going from the Speech resource to a telephony server (the RTP entity in Eric's picture), but no media goes to the application entity. Eric's pictutre of the blocks show it pretty well: +-------------+ | application |_________ | entity | \ +-------------+ \ speechsc : \ (no media) +-------------+ : \---------------| Speech |+ : whatever | Processing ||+ : ---------------| Resource(s) ||| : / RTP +-------------+|| : / +-------------+| +----------+ / +-------------+ | RTP | / | entity |----------- +----------+ Notice that there is no media going from the application entity to the speech resources. So, there is no need for a media transport protocol to piggyback the control commands onto. In fact, the entity requiring media streams (RTP entity) may be in a completely different location from the application entity. Existing media transport protocols such as SIP and RTSP do not support this kind of separation between the control session and the media transport. For that matter, the Speech processing resource may itself be distributed, so that the speech control entity that is being commanded by the speechsc session may not be the entity that sources or sinks the media! The picture would look something like this... +-------------+ speechsc +-------------+ | application |----------------------------| Speech | | entity | | Server | +-------------+ | Controller | : +-------------+ : : : : /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Wide Area Network /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ : : : whatever : Internal protocol : : Proprietary to speech : : server vendors Phone : : Lines +----------+ RTP or SIP +-------------+ ------|Telephony |------------------------------| Speech |+ ------| entity | | Processing ||+ +----------+ | Resource(s) ||| +-------------+|| +-------------+| +-------------+ This is a fairly common scenario with the ASR vendors new distributed architectures. Because of thse issues, protocols that assume that the control session and the media are together, such as SIP or RTSP, cannot be used for speechsc. These media transport prococols do not have any way to separate the media from the control session. A potential approach to this dilemma is the web services architecture. There is no underlying assumption that SOAP commands will be accompanied by media, so this is a step in the right direction. The speechsc protocol could simply be a set of SOAP requests to the speech server with the responses contained in the standard HTTP reply. Unfortunately, because SOAP uses the HTTP request/response protocol, this makes the interface inherently synchronous. I won't go into details here, but suffice it to say that a synchronous protocol is not appropriate for speech server control. SOAP has the right general idea, just not the right details. To address Bryan's question: > Q1: what is the best model for SPEECHSC: > - a layer OVER a media signalling protocol (SIP, RTSP, etc, depending on this lower layer >for media and session control, just like MRCP/RTSP currently does) As discussed above, speechsc cannot be placed OVER a media protocol such as SIP RTSP, etc, because speechsc SHOULD NOT CARRY MEDIA. No need to use a media protocol when there is no media to carry. We just need to be able to set up a command/ response session between the application server and the speech resources. This makes the remainder of Bryan's issues about media protocols moot... > -> in which case what is the encapsulation mechanism - RTSP has ANNOUNCE > messages, what does SIP provide for this sort of bundling? > -> and what is the "best" protocol to layer over > - an extension to an existing media signalling protocol (eg, add MRCP "verbs" as new > ones in RTSP, or add as new SIP commands...) Bryan then asks: > - [should we uuse] a new protocol incorporating both media signalling, session > control and resource control (eg Web services extensions)? Skip says: The speechsc protocol does not need media signaling (in it's most common sense), just session control with command/response messages. We do need a way for the application server to tell the speech server (or the telephony server) where to send his media, but this is about the extent of "media control" in speechsc. Bryan says: > As for the identification and resolution of resource servers, this is for me a > separate functionality to SPEECHSC itself, and there are already multiple mechanisms > existing (SLP, UDDI, etc) for service location and discovery. Skip says: Absolutely. There are already plenty of discovery/ allocation protocols out there. It would probably be useful for the speecsc group to recommend one particular solution in the specification, if only to make life easier for systems integrators. However this is probably not a critical issue in the early phases. Jean Philippe said: > SIP is little bit poor for data transportation, but it exists and clearly chosen by > 3GPP and 3GPP2. For my opinion , SPEECHSC could be something very closed from MRCP >and transported by SIP INFO method. Skip says: As above, when you don't need to transport media, why use a media transport protocol to send command/control messages? Jean Philippe said: > Speechsc, like MRCP must only define the media control part and the way how it can > be transported by SIP (and optionally by others protocols like H.225.0, RTSP, H.248, Skip says: There's no reason to go to all the trouble trying to figure out how to put media control messages on top of a media protocol, if you don't need to carry media. Jean Philippe said: > All media resources could be controlled by the same protocol (SPEECHSC). At the > streaming side, RTP/RTCP is of course engaged. I'm sure that a MutliMedia VOIP core > with optional peripheral gateways is the Next Gen architecture for Telephony. Skip says: The telephony server, or softswitch, or VOIP gateway, or whatever, will definitely need to deal with media streams. However this entity will NOT need to deal with speech resource control commands. Clearly RTP is a front-runner in the protocol race, to carry the media from the speech resource to the telephony interface. The interesting question is whether we need to encapsulate RTP in a session protocol such as SIP, or whether a basic, stripped-down RTP protocol is suficient to carry the media between the speech servers and the telephony interface. If we decide on pure RTP, then speechsc will have to take on some SIP-like qualities. This will probably add considerable to the work required to get out a spec. I suspect that it will be much easier to have speechsc simply to set up a SIP session between the two entities requiring media connections, and let SIP do the rest. This means that both the speech server and the telephony entity (softswitch, VOIP gateway, Intel/Dialogic card, etc.) will have to support the SIP protocol. Luckily, this is an absolutely STOCK SIP protocol, no extensions needed. Jean Philippe said: > An extension of MRCP could be the answer. It is a great protocol, isn't it? > And It already works over RTSP (Nuance, Speechworks, Telisma...) > Find bellow some extension of MRCP, SPEECHSC could cover: > - speaker verification, > - speaker identification, > - announcement, voice recording, > - tones detection, tones generation, > - fax, > - audio conferencing, > - video conferencing, > - chat Skip says: MRCP, or RTSP, or SIP, or extensions to these protocols can't be used for a general speechsc protocol, because of the requirement that the media and commands be completely separate from each other. MRCP or RTSP would be fine if the application entity and the telephony entity resided in the same box, but that won't be the case in many future systems. MRCP cannot deal with the problem of remote telephony servers separate from the application servers, as I described earlier in this discussion. We certainly don't want to restrict future architectures to require that the application and telephony systems must reside in the same box! Marc said: > I agree with the decomposition or unbundling model. > Although there is no needs to support a multitude of protocol stacks profiles (aka > speechsc over everything), I believe speechsc needs to enable some separation in > terms of protocol layers and service interfaces (this is also a personal good > learning of previous model like OSI, TCP/IP... which are somewhat widely adopted in > the SIP, HTTP, SOAP and other work as well). > Separation of Control pipe and media pipe is also at the heart of modern telecoms. Skip says: Absolutely! Spoken like a true believer. In fact. speechsc should be separated by more than a layered architecure. Speechsc shold be strictly a command/response protocol. No media in any of the layers. Now, within the speechsc commands you can have a request for the speech server (or the telephony server) to send a media stream somewhere. The stream can originate anywhere, and terminate anywhere else. This is a close as speechsc should get to media stream control. Marc said: > Now in terms of technology I guess there are advantages in the likes of SIP, SOAP, > XML (anyway already widely used at the speech grammar or synthesis level in the MRCP > packets for instance), with all the extensibility and programmability that they > provide. > For instance, SIP can be extended, see the SIPPING an SIMPLE work to provide open > framework for other semantic to be built on top of it. SOAP clearly provides a good > invocation model for a 'programmable' framework. Skip says: I believe that speechsc's command/response protocol can be defined as a set of XML messages. This is probably as open a way of building the protocol as any. Now this doesn't mean that SOAP is the best transport mechanism. SOAP's synchronous attributes prevent the asynchronous control functionality needed by speechsc. I expect that we will come to find that a SOAP-like xml message structure, over a more general socket-type protocol (instead of SOAP's HTTP) will be the best tradeoff for speechsc. As far as the media protocol is concerned, un-modified SIP is probably the best candidate to set up and carry the audio between the speech servers and the telephony interfaces. So, speechsc would be SOAP-like xml messages over a socket-like protocol between the application server and the speech servers. Meanwhile, un-modified SIP would set up and carry the media between the speech resources and the telephony interfaces. Skip Cave Sr. Principal Engineer Intervoice Inc. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Dec 18 02:50:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29037 for ; Wed, 18 Dec 2002 02:50:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBI7rWE16866 for speechsc-archive@odin.ietf.org; Wed, 18 Dec 2002 02:53:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI7rWv16863 for ; Wed, 18 Dec 2002 02:53:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29031 for ; Wed, 18 Dec 2002 02:50:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI7rQv16855; Wed, 18 Dec 2002 02:53:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI7q3v16777 for ; Wed, 18 Dec 2002 02:52:03 -0500 Received: from slap.mg2-lyon.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29006 for ; Wed, 18 Dec 2002 02:48:50 -0500 (EST) Received: from jpl (jpl.mg2-lyon.fr [132.147.160.27]) by slap.mg2-lyon.fr (Postfix) with SMTP id 12AF510EFD for ; Wed, 18 Dec 2002 09:38:28 +0100 (CET) From: "Jean Philippe Longeray" To: Subject: RE: [Speechsc] speechsc protocol issues Date: Wed, 18 Dec 2002 08:44:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <4A3384433CE2AB46A63468CB207E209D097BB2@zoe.office.snowshore.com> Content-Transfer-Encoding: 8bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Good morning, I agree Eric, SIP can be use everywhere, with or without media... just to have a look to 3GPP which takes advantage of SIP, whitout media. SDP or RTP mean, mostly, media, SIP doesn't. We also use H.323 for data only, X.25 for voice, J.162 for conferencing, MGCP for Modems.. One thing : I'm sure that XML and SOAP could be a very good approach (even if I prefer X.680 (ASN.1) notation, X.690 (BER) encoding and Q.771 (TCAP) for transaction, but implementation are much more expensive..). I understand also, that SPEECHSC doesn't want to care about Media Architecture, but only Application Protocol in order to control ASR, TTS... I think another WG could have a look on 3GPP, 3GPP2, MWIF, WIN(ANSI-41), CAMEL(GSM), CS.4 (PINT), because all of them have the same problem to use media resources, and propose so different solutions. If someone could propose something mostly common to access to the same thing ;-) Have a nice day. Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex Jean-philippe.longeray@netcentrex.net + 33 4 72 53 61 33 - + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 http://www.netcentrex.net -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf Of Eric Burger Sent: mercredi 18 décembre 2002 01:51 To: Skip Cave Cc: speechsc@ietf.org Subject: RE: [Speechsc] speechsc protocol issues I have to disagree. Consider the following network architecture: +------------------+ +---------------+ | SS7 Gateway | SIP | Media Gateway | | (A SIP Endpoint) |------------------------------| Controller | +------------------+ +---------------+ : : : Something : H.248 : (Diameter, H.248, J.162, ...) : : : +-------------------+ RTP +---------------+ | Media Gateway |-----------------------------| Media Gateway | | (An RTP Endpoint) | +---------------+ +-------------------+ This looks to me to be the identical configuration you describe below. There is absolutely no media being transported by SIP. That is what RTP is for. These boxes are clearly different physical boxes. SS7 gateways definitely DON'T do media. I don't get the distinction you are making. SIP and RTSP *explicitly* assume the control and media legs are separate. That was a design goal that was met. On the other hand, there is a definite *correlation* between the signaling and media stream, if a media stream is present. Let's say that differently: you can have a signaling relationship without a media relationship. Take, for example, SIMPLE (please!). That correlation is the reason we use SIP and RTSP to do dialog and playback sessions. -----Original Message----- From: Skip Cave [mailto:skip.cave@intervoice.com] Sent: Tuesday, December 17, 2002 6:34 PM To: speechsc@ietf.org Subject: [Speechsc] speechsc protocol issues Here are my comments on several of the issues discussed in the last few posts: SpeechSC & media transport The basic problem with trying to add speech server control messages to a media transport protocol such as RTSP or SIP is that in the speechsc architecture, the command channel between the appication server and the speech server DOES NOT CARRY ANY MEDIA, streaming or otherwise! So, there is no reason to use a media transport protocol such as RTSP or SIP/RTP to "pigyback" media commands on. When there is no media to carry, whay use a media protocol at all? There may be media going from the Speech resource to a telephony server (the RTP entity in Eric's picture), but no media goes to the application entity. Eric's pictutre of the blocks show it pretty well: +-------------+ | application |_________ | entity | \ +-------------+ \ speechsc : \ (no media) +-------------+ : \---------------| Speech |+ : whatever | Processing ||+ : ---------------| Resource(s) ||| : / RTP +-------------+|| : / +-------------+| +----------+ / +-------------+ | RTP | / | entity |----------- +----------+ Notice that there is no media going from the application entity to the speech resources. So, there is no need for a media transport protocol to piggyback the control commands onto. In fact, the entity requiring media streams (RTP entity) may be in a completely different location from the application entity. Existing media transport protocols such as SIP and RTSP do not support this kind of separation between the control session and the media transport. For that matter, the Speech processing resource may itself be distributed, so that the speech control entity that is being commanded by the speechsc session may not be the entity that sources or sinks the media! The picture would look something like this... +-------------+ speechsc +-------------+ | application |----------------------------| Speech | | entity | | Server | +-------------+ | Controller | : +-------------+ : : : : /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Wide Area Network /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ : : : whatever : Internal protocol : : Proprietary to speech : : server vendors Phone : : Lines +----------+ RTP or SIP +-------------+ ------|Telephony |------------------------------| Speech |+ ------| entity | | Processing ||+ +----------+ | Resource(s) ||| +-------------+|| +-------------+| +-------------+ This is a fairly common scenario with the ASR vendors new distributed architectures. Because of thse issues, protocols that assume that the control session and the media are together, such as SIP or RTSP, cannot be used for speechsc. These media transport prococols do not have any way to separate the media from the control session. A potential approach to this dilemma is the web services architecture. There is no underlying assumption that SOAP commands will be accompanied by media, so this is a step in the right direction. The speechsc protocol could simply be a set of SOAP requests to the speech server with the responses contained in the standard HTTP reply. Unfortunately, because SOAP uses the HTTP request/response protocol, this makes the interface inherently synchronous. I won't go into details here, but suffice it to say that a synchronous protocol is not appropriate for speech server control. SOAP has the right general idea, just not the right details. To address Bryan's question: > Q1: what is the best model for SPEECHSC: > - a layer OVER a media signalling protocol (SIP, RTSP, etc, depending on this lower layer >for media and session control, just like MRCP/RTSP currently does) As discussed above, speechsc cannot be placed OVER a media protocol such as SIP RTSP, etc, because speechsc SHOULD NOT CARRY MEDIA. No need to use a media protocol when there is no media to carry. We just need to be able to set up a command/ response session between the application server and the speech resources. This makes the remainder of Bryan's issues about media protocols moot... > -> in which case what is the encapsulation mechanism - RTSP has ANNOUNCE > messages, what does SIP provide for this sort of bundling? > -> and what is the "best" protocol to layer over > - an extension to an existing media signalling protocol (eg, add MRCP "verbs" as new > ones in RTSP, or add as new SIP commands...) Bryan then asks: > - [should we uuse] a new protocol incorporating both media signalling, session > control and resource control (eg Web services extensions)? Skip says: The speechsc protocol does not need media signaling (in it's most common sense), just session control with command/response messages. We do need a way for the application server to tell the speech server (or the telephony server) where to send his media, but this is about the extent of "media control" in speechsc. Bryan says: > As for the identification and resolution of resource servers, this is for me a > separate functionality to SPEECHSC itself, and there are already multiple mechanisms > existing (SLP, UDDI, etc) for service location and discovery. Skip says: Absolutely. There are already plenty of discovery/ allocation protocols out there. It would probably be useful for the speecsc group to recommend one particular solution in the specification, if only to make life easier for systems integrators. However this is probably not a critical issue in the early phases. Jean Philippe said: > SIP is little bit poor for data transportation, but it exists and clearly chosen by > 3GPP and 3GPP2. For my opinion , SPEECHSC could be something very closed from MRCP >and transported by SIP INFO method. Skip says: As above, when you don't need to transport media, why use a media transport protocol to send command/control messages? Jean Philippe said: > Speechsc, like MRCP must only define the media control part and the way how it can > be transported by SIP (and optionally by others protocols like H.225.0, RTSP, H.248, Skip says: There's no reason to go to all the trouble trying to figure out how to put media control messages on top of a media protocol, if you don't need to carry media. Jean Philippe said: > All media resources could be controlled by the same protocol (SPEECHSC). At the > streaming side, RTP/RTCP is of course engaged. I'm sure that a MutliMedia VOIP core > with optional peripheral gateways is the Next Gen architecture for Telephony. Skip says: The telephony server, or softswitch, or VOIP gateway, or whatever, will definitely need to deal with media streams. However this entity will NOT need to deal with speech resource control commands. Clearly RTP is a front-runner in the protocol race, to carry the media from the speech resource to the telephony interface. The interesting question is whether we need to encapsulate RTP in a session protocol such as SIP, or whether a basic, stripped-down RTP protocol is suficient to carry the media between the speech servers and the telephony interface. If we decide on pure RTP, then speechsc will have to take on some SIP-like qualities. This will probably add considerable to the work required to get out a spec. I suspect that it will be much easier to have speechsc simply to set up a SIP session between the two entities requiring media connections, and let SIP do the rest. This means that both the speech server and the telephony entity (softswitch, VOIP gateway, Intel/Dialogic card, etc.) will have to support the SIP protocol. Luckily, this is an absolutely STOCK SIP protocol, no extensions needed. Jean Philippe said: > An extension of MRCP could be the answer. It is a great protocol, isn't it? > And It already works over RTSP (Nuance, Speechworks, Telisma...) > Find bellow some extension of MRCP, SPEECHSC could cover: > - speaker verification, > - speaker identification, > - announcement, voice recording, > - tones detection, tones generation, > - fax, > - audio conferencing, > - video conferencing, > - chat Skip says: MRCP, or RTSP, or SIP, or extensions to these protocols can't be used for a general speechsc protocol, because of the requirement that the media and commands be completely separate from each other. MRCP or RTSP would be fine if the application entity and the telephony entity resided in the same box, but that won't be the case in many future systems. MRCP cannot deal with the problem of remote telephony servers separate from the application servers, as I described earlier in this discussion. We certainly don't want to restrict future architectures to require that the application and telephony systems must reside in the same box! Marc said: > I agree with the decomposition or unbundling model. > Although there is no needs to support a multitude of protocol stacks profiles (aka > speechsc over everything), I believe speechsc needs to enable some separation in > terms of protocol layers and service interfaces (this is also a personal good > learning of previous model like OSI, TCP/IP... which are somewhat widely adopted in > the SIP, HTTP, SOAP and other work as well). > Separation of Control pipe and media pipe is also at the heart of modern telecoms. Skip says: Absolutely! Spoken like a true believer. In fact. speechsc should be separated by more than a layered architecure. Speechsc shold be strictly a command/response protocol. No media in any of the layers. Now, within the speechsc commands you can have a request for the speech server (or the telephony server) to send a media stream somewhere. The stream can originate anywhere, and terminate anywhere else. This is a close as speechsc should get to media stream control. Marc said: > Now in terms of technology I guess there are advantages in the likes of SIP, SOAP, > XML (anyway already widely used at the speech grammar or synthesis level in the MRCP > packets for instance), with all the extensibility and programmability that they > provide. > For instance, SIP can be extended, see the SIPPING an SIMPLE work to provide open > framework for other semantic to be built on top of it. SOAP clearly provides a good > invocation model for a 'programmable' framework. Skip says: I believe that speechsc's command/response protocol can be defined as a set of XML messages. This is probably as open a way of building the protocol as any. Now this doesn't mean that SOAP is the best transport mechanism. SOAP's synchronous attributes prevent the asynchronous control functionality needed by speechsc. I expect that we will come to find that a SOAP-like xml message structure, over a more general socket-type protocol (instead of SOAP's HTTP) will be the best tradeoff for speechsc. As far as the media protocol is concerned, un-modified SIP is probably the best candidate to set up and carry the audio between the speech servers and the telephony interfaces. So, speechsc would be SOAP-like xml messages over a socket-like protocol between the application server and the speech servers. Meanwhile, un-modified SIP would set up and carry the media between the speech resources and the telephony interfaces. Skip Cave Sr. Principal Engineer Intervoice Inc. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Dec 18 04:00:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29995 for ; Wed, 18 Dec 2002 04:00:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBI93VK20968 for speechsc-archive@odin.ietf.org; Wed, 18 Dec 2002 04:03:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI93Vv20965 for ; Wed, 18 Dec 2002 04:03:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29990 for ; Wed, 18 Dec 2002 04:00:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI93Qv20919; Wed, 18 Dec 2002 04:03:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI8sBv20325 for ; Wed, 18 Dec 2002 03:54:11 -0500 Received: from e3.ny.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29751 for ; Wed, 18 Dec 2002 03:50:59 -0500 (EST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gBI8rxjk119100 for ; Wed, 18 Dec 2002 03:53:59 -0500 Received: from d27ml601.rchland.ibm.com (d27ml601.rchland.ibm.com [9.10.226.13]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gBI8rwlm124194 for ; Wed, 18 Dec 2002 03:53:58 -0500 From: Edward Epstein To: speechsc@ietf.org Message-ID: Date: Wed, 18 Dec 2002 02:53:56 -0600 X-MIMETrack: Serialize by Router on d27ml601/27/M/IBM(Release 6.0|September 26, 2002) at 12/18/2002 02:53:58 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Speechsc] Edward Epstein/Watson/IBM is out of the office. Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , I will be out of the office starting December 18, 2002 and will not return until January 6, 2003. I will be checking email during this period. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Dec 18 14:11:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16140 for ; Wed, 18 Dec 2002 14:11:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBIJESN25123 for speechsc-archive@odin.ietf.org; Wed, 18 Dec 2002 14:14:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIJESv25119 for ; Wed, 18 Dec 2002 14:14:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16130 for ; Wed, 18 Dec 2002 14:11:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIJELv25107; Wed, 18 Dec 2002 14:14:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIJDxv25090 for ; Wed, 18 Dec 2002 14:13:59 -0500 Received: from mail2.intervoice-brite.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16116 for ; Wed, 18 Dec 2002 14:10:54 -0500 (EST) Received: from 172.16.16.64 (gwsmtpsrv.intervoice.com [172.16.16.64]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with SMTP id NAA03260 for ; Wed, 18 Dec 2002 13:27:41 -0600 Received: from INTERVOICE-Message_Server by 172.16.16.64 with Novell_GroupWise; Wed, 18 Dec 2002 13:13:52 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 18 Dec 2002 13:13:27 -0600 From: "Skip Cave" To: Subject: RE: [Speechsc] speechsc protocol issues Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_7E214DE0.EB8AD97E" Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_7E214DE0.EB8AD97E Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable A quote from " Guidelines for Authors of Extensions to the Session = Initiation Protocol (SIP)" http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-06.txt "SIP is a poor control protocol. It is not meant to be used for one entity = to tell another to pick up or answer a phone, send audio using a = particular codec, or to provide a new value for a configuration parameter. = Control protocols have different trust relationships than is assumed in = SIP, and are more centralized in architecture than SIP, which is a very = distributed protocol." On another note, one requirement for speechsc would be the capability to = allow commands to be sent to a speech server with no media invoilved. For = example one may want to send a grammar to an ASR server before establishing= a call. You don't want to set up media yet, just pre-load some grammars. = SIP typically sets up media at the initial INVITE message, which is not = what we want to do. Skip Cave=20 Sr. Principal Engineer Intervoice=20 --=_7E214DE0.EB8AD97E Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: quoted-printable
A quote from " Guidelines for Authors of=20 Extensions to the Session Initiation Protocol (SIP)"
http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-06.txt=
"SIP is a poor control protocol. It is not meant to be used for one = entity=20 to tell another to pick up or answer a phone, send audio using  a=20 particular codec, or to provide a new value for a configuration parame= ter.=20 Control protocols have different trust relationships than is assumed = in=20 SIP, and are more centralized in architecture than SIP,  which = is a=20 very distributed protocol."
 
 
On another note, one requirement for speechsc would be the capability = to=20 allow commands to be sent to a speech server with no media invoilved. = For=20 example one may want to send a grammar to an ASR server before = establishing=20 a call. You don't want to set up media yet, just pre-load some grammars. = SIP=20 typically sets up media at the initial INVITE message, which is not what = we want=20 to do.
 
Skip Cave
Sr. Principal Engineer
Intervoice
--=_7E214DE0.EB8AD97E-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu Dec 19 22:59:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06010 for ; Thu, 19 Dec 2002 22:59:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBK42SO10308 for speechsc-archive@odin.ietf.org; Thu, 19 Dec 2002 23:02:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBK42Sv10305 for ; Thu, 19 Dec 2002 23:02:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05994 for ; Thu, 19 Dec 2002 22:59:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBK42Lv10294; Thu, 19 Dec 2002 23:02:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBK41jv10277 for ; Thu, 19 Dec 2002 23:01:45 -0500 Received: from gw-nl4.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05947 for ; Thu, 19 Dec 2002 22:58:22 -0500 (EST) From: stefan.bohrer@philips.com Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl4.philips.com (Postfix) with ESMTP id 42202A60A0 for ; Fri, 20 Dec 2002 05:01:23 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id FAA26276 for ; Fri, 20 Dec 2002 05:01:20 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id FAA12900 for ; Fri, 20 Dec 2002 05:01:18 +0100 (MET) To: speechsc@ietf.org Message-ID: Date: Fri, 20 Dec 2002 05:01:51 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 20/12/2002 05:02:18 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Speechsc] Stefan Bohrer/ACN/BE/PHILIPS is out of the office. Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , I will be out of the office starting 19.12.2002 and will not return until 06.01.2003. Thank you for your message. I will respond to your message when I return. In urgent cases please contact Ms. Sandra Birngruber (+49 241 8871 504, sandra.birngruber@philips.com). _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Dec 20 10:24:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29201 for ; Fri, 20 Dec 2002 10:24:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBKFRXS21339 for speechsc-archive@odin.ietf.org; Fri, 20 Dec 2002 10:27:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKFRXv21336 for ; Fri, 20 Dec 2002 10:27:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29192 for ; Fri, 20 Dec 2002 10:24:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKFOEv21247; Fri, 20 Dec 2002 10:24:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKFKXv21129 for ; Fri, 20 Dec 2002 10:20:33 -0500 Received: from rnidmail.rnid.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28932 for ; Fri, 20 Dec 2002 10:17:05 -0500 (EST) Received: from rnid.org.uk (unverified) by rnidmail.rnid.org (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Fri, 20 Dec 2002 15:16:49 +0000 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Fri, 20 Dec 2002 15:19:26 +0000 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Fri, 20 Dec 2002 15:18:41 +0000 From: "Guido Gybels" To: , , , , , , "Mike Spanner" Cc: , , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBKFKYv21130 Subject: [Speechsc] Re: Request for review and feedback on draft-ietf-speechsc-reqts-02.txt Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Dear all, David Oran wrote: <> We obviously welcome the commitment from this group with regard to ensuring that deaf and hard of hearing people will be considered in this work. Below, you'll find a number of initial comments/questions I have. We need to do a more proper analysis of the draft, but time has been lacking over here. However, in the mean time, we would like to present the following already: On 3.3 Avoid Duplicating Existing Protocols: " As a corollary to this, the SPEECHSC should not require a separate protocol to perform functions that could be easily added into the SPEECHSC protocol (like redirecting media streams, or discovering capabilities), unless it is similarly easy to embed that protocol directly into the SPEECHSC framework." It is not really clear to me what this means, i.e. what the repercussions or the scope is of the statement above. I would be grateful if somebody could give me some feedback on that. 4.2.4 Document Type Indication What is a "document type" in this context? The content is a stream, so what is meant here? Does it refer to informational content versus technical specification? 4.5 Playback Controls "The ability to increase and decrease playout volume." How important is this? The only time I can see this being useful is if your equipment has no volume control, which doesn't seem particularly likely. Far more likely is that the volume of the audio stream would be controlled by the user. Especially if users are deaf or hard of hearing, they might need to be able to control the audio at their end, even if they use it in a way that would be meaningless to hearing people. 5.1 Requesting Automatic Speech Recognition " The SPEECHSC framework MUST allow a Media Processing Entity or Application Server to request the ASR Server to perform automatic speech recognition on an RTP stream, returning the results over SPEECHSC." Does this mean that the media stream resulting from the ASR is routed over SPEECHSC, or does it mean that the results of the request (i.e., a success or failure indication) is returned over SPEECHSC? 5.5 Input Capture One must not compromise the privacy of the users of SPEECHSC based services. 6.1 Requesting SI/SV " The SPEECHSC framework MUST allow a Media Processing Entity to request the SI/SV Server to perform speaker identification or verification on an RTP stream, returning the results over SPEECHSC." Presumably, the results of the identification/validation are returned over SPEECHSC? In the context of SIP: In the event of a speech impaired user, who would prefer using an outbound text stream, how would he, as a "speaker", be identified or verified? Is there some sort of pass-through to another protocol to identify/verify him? Something that might not be covered by the document is the concept of synchronising streams. Let A be a deaf person, and B a hard-of-hearing person. A communicates only via text, and B via a lipspeaking avatar in conjunction with an audio stream. B thus has two inbound media streams. These streams must be tightly synchronised in order to be useful to B. Another possible problem is content description on an informational level ("Resource Management" paragraph in RFC3351): again, assuming for example that a TTS stream is coming in, the user agent would need to be able to identify that stream as TTS as opposed to natural voice in he/she would want to use a lipspeaking avatar with it for instance (the avatar might not be able to function on a TTS stream if it was modeled on a natural voice and extracts features that are not present in the TTS stream). I can think of a number of other occasions where content identification is required (including resource management in transcoding services), yet that issue seems to be unresolved so far. References: [2]'s URL (http://www.w3.org/TR/WD-speech-synthesis-20021202) returns a 404 Some language issues (with some reservation since I'm not a native English speaker!) 1. Introduction "This requirements document limits its focus on..." should probably be: "This requirements document limits its focus to..." "In particular, they mix the semantics of existing protocols yet are lose enough..." should be "In particular, they mix the semantics of existing protocols yet are close enough..." 4.2.2 SSML "SSML[3]" should be "SSML [2]" 4.6 Session Parameters I assume "must" should be MUST? 5.2 XML "The Speechsc framework assumes that all ASR servers support thh..." should be "The SPEECHSC framework assumes that all ASR servers support the..." 5.3.1 Grammar Specification "The Speechsc framework" should be "The SPEECHSC framework" 5.3.3 Grammar Sharing "The Speechsc framework" should be "The SPEECHSC framework" 6.4 Input Capture Again, capturing input streams could compromise the privacy of people using SPEECHSC-enabled technologies. HTH, Marry Christmas and a Happy New Year to all of you, Guido Guido Gybels RNID, Head of ICT guido.gybels@rnid.org.uk Tel +44(0)20-7294 3713 Fax +44(0)20-7296 8069 --- Royal National Institute for Deaf People 19-23 Featherstone Street LONDON EC1Y 8 SL Phone 020-7296 8000 TextPhone 020-7296 8001 Fax 020-7296 8199 ************************************************************************ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent RNID policy. If you are not the intended recipient you are advised that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify the RNID Helpdesk by telephone on: +44 (0) 207 296 8282. The Royal National Institute for Deaf People Registered Office 19-23 Featherstone Street London EC1Y 8SL No. 454169 (England) Registered Charity No. 207720 ************************************************************************ _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Dec 30 04:39:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20888 for ; Mon, 30 Dec 2002 04:39:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBU9kiJ22122 for speechsc-archive@odin.ietf.org; Mon, 30 Dec 2002 04:46:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBU9kiJ22119 for ; Mon, 30 Dec 2002 04:46:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20878 for ; Mon, 30 Dec 2002 04:39:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBU9hIJ22041; Mon, 30 Dec 2002 04:43:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBU9g1J22012 for ; Mon, 30 Dec 2002 04:42:01 -0500 Received: from ahuumrelay0.ams.ops.eu.uu.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20813 for ; Mon, 30 Dec 2002 04:34:46 -0500 (EST) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay0.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id gBU9bq922494; Mon, 30 Dec 2002 09:37:53 GMT Received: from polo (polo.hq.eloquant.com [192.168.0.131]) by weasel.hq.eloquant.com (Postfix) with SMTP id 941EA3B727; Mon, 30 Dec 2002 04:32:17 -0500 (EST) Reply-To: From: "Brian Wyld" To: "'Skip Cave'" , Subject: RE: [Speechsc] speechsc protocol issues Date: Mon, 30 Dec 2002 10:35:43 +0100 Message-ID: <027701c2afe6$d38e4350$8300010a@hq.eloquant.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0278_01C2AFEF.3552AB50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0278_01C2AFEF.3552AB50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, wrt Skip's comment below, I note that RTSP (for example) allows use of configuration setup messages outside of a media session (including for instance the ANNOUNCE message used in the current MRCP/RTSP submission) Brian [Skip] On another note, one requirement for speechsc would be the capability to allow commands to be sent to a speech server with no media invoilved. For example one may want to send a grammar to an ASR server before establishing a call. You don't want to set up media yet, just pre-load some grammars. SIP typically sets up media at the initial INVITE message, which is not what we want to do. ------=_NextPart_000_0278_01C2AFEF.3552AB50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
wrt Skip's comment = below, I=20 note that RTSP (for example) allows use of configuration setup messages = outside=20 of a media session (including for instance the ANNOUNCE message used in = the=20 current MRCP/RTSP submission)
 
Brian
[Skip] 
 On another note, = one=20 requirement for speechsc would be the capability to allow commands to = be sent=20 to a speech server with no media invoilved. For example one may want = to send a=20 grammar to an ASR server before establishing a call. You don't = want to=20 set up media yet, just pre-load some grammars. SIP typically sets up = media at=20 the initial INVITE message, which is not what we want to do.  
= ------=_NextPart_000_0278_01C2AFEF.3552AB50-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Dec 30 05:32:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21364 for ; Mon, 30 Dec 2002 05:32:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUAdSI24733 for speechsc-archive@odin.ietf.org; Mon, 30 Dec 2002 05:39:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUAdSJ24730 for ; Mon, 30 Dec 2002 05:39:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21356 for ; Mon, 30 Dec 2002 05:32:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUAdLJ24722; Mon, 30 Dec 2002 05:39:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUAcBJ24674 for ; Mon, 30 Dec 2002 05:38:11 -0500 Received: from ahuumrelay0.ams.ops.eu.uu.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21321 for ; Mon, 30 Dec 2002 05:30:53 -0500 (EST) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay0.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id gBUAXx926677; Mon, 30 Dec 2002 10:34:00 GMT Received: from polo (polo.hq.eloquant.com [192.168.0.131]) by weasel.hq.eloquant.com (Postfix) with SMTP id 010C03B727; Mon, 30 Dec 2002 05:28:25 -0500 (EST) Reply-To: From: "Brian Wyld" To: "'Jean Philippe Longeray'" , Subject: RE: [Speechsc] speechsc protocol issues Date: Mon, 30 Dec 2002 11:31:49 +0100 Message-ID: <028101c2afee$aa2872d0$8300010a@hq.eloquant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Jean-Philippe, > One thing : I'm sure that XML and SOAP could be a very good > approach (even > if I prefer X.680 (ASN.1) notation, X.690 (BER) encoding and > Q.771 (TCAP) > for transaction, but implementation are much more expensive..). I'm awaiting an updated analysis for the webServices protocol section... IMHO, there are a couple of issues with the web services approach today: - no asynchronous events from server to client (I understand this may be being looked at generally anyway, but today the only method I've seen is an ugly 'reverse service' type hack) - heavy protocol stack (lots of text, lots of bytes) - need to re-invent the media setup section (although this could be just an encapsulated SDP block?) To be honest I think that we may be better served by a specific protocol/extensions to an existing protocol rather than a generic "remote services access" type architecture which I'm not convinced is justified here. The speechsc charter is currently very narrow.... At the scope we're currently discussing, I think XML+SOAP and ASN.1/BER+TCAP are the same functionally and architecturally..... it's just one side is pure web and the other pure telecom -> the main difference is the cost and the thickness of the spec..... > I understand also, that SPEECHSC doesn't want to care about Media > Architecture, but only Application Protocol in order to > control ASR, TTS... Hmmm. I don't agree - speechsc must I think address the media architecture (which is different from processing the media....) as after all the whole objective is to process the media..... The media path will be certainly separate (as Eric has already expounded....) > I think another WG could have a look on 3GPP, 3GPP2, MWIF, > WIN(ANSI-41), > CAMEL(GSM), CS.4 (PINT), because all of them have the same > problem to use > media resources, and propose so different solutions. If someone could > propose something mostly common to access to the same thing ;-) Can I encourage you then to create a protocol analysis section for these solutions (using the template document of course and covering the same items as the other sections)? This would ensure that we didn't ignore something useful, and that they can be discussed in the same framework as other contendors. cheers, Brian > > Jean-Philippe LONGERAY > R&D Director - Service NODE > > NetCentrex > > Jean-philippe.longeray@netcentrex.net > > + 33 4 72 53 61 33 - + 33 4 72 53 61 30 > Mobile: + 33 6 76 48 34 95 > http://www.netcentrex.net > > > > -----Original Message----- > From: speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]On Behalf > Of Eric Burger > Sent: mercredi 18 décembre 2002 01:51 > To: Skip Cave > Cc: speechsc@ietf.org > Subject: RE: [Speechsc] speechsc protocol issues > > > I have to disagree. > > Consider the following network architecture: > > > +------------------+ > +---------------+ > | SS7 Gateway | SIP | > Media Gateway | > | (A SIP Endpoint) |------------------------------| > Controller | > +------------------+ > +---------------+ > : : > : Something > : H.248 > : (Diameter, H.248, J.162, ...) : > : : > +-------------------+ RTP > +---------------+ > | Media Gateway |-----------------------------| > Media Gateway | > | (An RTP Endpoint) | > +---------------+ > +-------------------+ > > This looks to me to be the identical configuration you describe below. > There is absolutely no media being transported by SIP. That > is what RTP is > for. These boxes are clearly different physical boxes. SS7 gateways > definitely DON'T do media. > > I don't get the distinction you are making. > > SIP and RTSP *explicitly* assume the control and media legs > are separate. > That was a design goal that was met. > > On the other hand, there is a definite *correlation* between > the signaling > and media stream, if a media stream is present. Let's say > that differently: > you can have a signaling relationship without a media > relationship. Take, > for example, SIMPLE (please!). > > That correlation is the reason we use SIP and RTSP to do > dialog and playback > sessions. > > > > > > -----Original Message----- > From: Skip Cave [mailto:skip.cave@intervoice.com] > Sent: Tuesday, December 17, 2002 6:34 PM > To: speechsc@ietf.org > Subject: [Speechsc] speechsc protocol issues > > > Here are my comments on several of the issues discussed in > the last few > posts: > > SpeechSC & media transport > > The basic problem with trying to add speech server control > messages to a > media transport protocol such as RTSP or SIP is that in the speechsc > architecture, the command channel between the appication > server and the > speech server DOES NOT CARRY ANY MEDIA, streaming or > otherwise! So, there is > no reason to use a media transport protocol such as RTSP or SIP/RTP to > "pigyback" media commands on. When there is no media to > carry, whay use a > media protocol at all? > > There may be media going from the Speech resource to a > telephony server (the > RTP entity in Eric's picture), but no media goes to the > application entity. > > Eric's pictutre of the blocks show it pretty well: > > +-------------+ > | application |_________ > | entity | \ > +-------------+ \ speechsc > : \ (no media) > +-------------+ > : \---------------| > Speech |+ > : whatever | > Processing ||+ > : ---------------| > Resource(s) ||| > : / RTP > +-------------+|| > : / > +-------------+| > +----------+ / > +-------------+ > | RTP | / > | entity |----------- > +----------+ > > Notice that there is no media going from the application entity to the > speech resources. So, there is no need for a media transport > protocol to > piggyback the control commands onto. In fact, the entity > requiring media > streams (RTP entity) may be in a completely different > location from the > application entity. Existing media transport protocols such > as SIP and RTSP > do not support this kind of separation between the control > session and the > media transport. > > > For that matter, the Speech processing resource may itself be > distributed, > so that the speech control entity that is being commanded by > the speechsc > session may not be the entity that sources or sinks the > media! The picture > would look something like this... > > > +-------------+ speechsc +-------------+ > | application |----------------------------| Speech | > | entity | | Server | > +-------------+ | Controller | > : +-------------+ > : : > : : > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > Wide Area Network > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > : : > : whatever : > Internal > protocol > : : > Proprietary > to speech > : : server > vendors > Phone : : > Lines +----------+ RTP or SIP +-------------+ > ------|Telephony |------------------------------| Speech |+ > ------| entity | | Processing ||+ > +----------+ | Resource(s) ||| > +-------------+|| > +-------------+| > +-------------+ > > This is a fairly common scenario with the ASR vendors new distributed > architectures. > > Because of thse issues, protocols that assume that the > control session and > the media are together, such as SIP or RTSP, cannot be used > for speechsc. > These media transport prococols do not have any way to > separate the media > from the control session. > > A potential approach to this dilemma is the web services > architecture. There > is no underlying assumption that SOAP commands will be > accompanied by media, > so this is a step in the right direction. The speechsc > protocol could simply > be a set of SOAP requests to the speech server with the > responses contained > in the standard HTTP reply. Unfortunately, because SOAP uses the HTTP > request/response protocol, this makes the interface > inherently synchronous. > I won't go into details here, but suffice it to say that a synchronous > protocol is not appropriate for speech server control. SOAP > has the right > general idea, just not the right details. > > To address Bryan's question: > > > Q1: what is the best model for SPEECHSC: > > - a layer OVER a media signalling protocol (SIP, RTSP, etc, > depending on > this lower layer > >for media and session control, just like MRCP/RTSP currently does) > > As discussed above, speechsc cannot be placed OVER a media > protocol such as > SIP RTSP, etc, because speechsc SHOULD NOT CARRY MEDIA. No > need to use a > media protocol when there is no media to carry. We just need > to be able to > set up a command/ response session between the application > server and the > speech resources. > > This makes the remainder of Bryan's issues about media > protocols moot... > > > -> in which case what is the encapsulation mechanism - RTSP has > ANNOUNCE > > messages, what does SIP provide for this sort of bundling? > > -> and what is the "best" protocol to layer over > > - an extension to an existing media signalling protocol > (eg, add MRCP > "verbs" as new > > ones in RTSP, or add as new SIP commands...) > > Bryan then asks: > > > - [should we uuse] a new protocol incorporating both media > signalling, > session > > control and resource control (eg Web services extensions)? > > Skip says: > The speechsc protocol does not need media signaling (in it's > most common > sense), just session control with command/response messages. > We do need a > way for the application server to tell the speech server (or > the telephony > server) where to send his media, but this is about the extent > of "media > control" in speechsc. > > Bryan says: > > As for the identification and resolution of resource > servers, this is for > me a > > separate functionality to SPEECHSC itself, and there are > already multiple > mechanisms > > existing (SLP, UDDI, etc) for service location and discovery. > > Skip says: > Absolutely. There are already plenty of discovery/ allocation > protocols out > there. It would probably be useful for the speecsc group to > recommend one > particular solution in the specification, if only to make > life easier for > systems integrators. However this is probably not a critical > issue in the > early phases. > > > Jean Philippe said: > > SIP is little bit poor for data transportation, but it > exists and clearly > chosen by > > 3GPP and 3GPP2. For my opinion , SPEECHSC could be > something very closed > from MRCP > >and transported by SIP INFO method. > > Skip says: > As above, when you don't need to transport media, why use a > media transport > protocol to send command/control messages? > > Jean Philippe said: > > Speechsc, like MRCP must only define the media control part > and the way > how it can > > be transported by SIP (and optionally by others protocols > like H.225.0, > RTSP, H.248, > > Skip says: > There's no reason to go to all the trouble trying to figure > out how to put > media control messages on top of a media protocol, if you > don't need to > carry media. > > Jean Philippe said: > > All media resources could be controlled by the same > protocol (SPEECHSC). > At the > > streaming side, RTP/RTCP is of course engaged. I'm sure > that a MutliMedia > VOIP core > > with optional peripheral gateways is the Next Gen architecture for > Telephony. > > Skip says: > The telephony server, or softswitch, or VOIP gateway, or > whatever, will > definitely need to deal with media streams. However this > entity will NOT > need to deal with speech resource control commands. Clearly RTP is a > front-runner in the protocol race, to carry the media from the speech > resource to the telephony interface. The interesting question > is whether we > need to encapsulate RTP in a session protocol such as SIP, or > whether a > basic, stripped-down RTP protocol is suficient to carry the > media between > the speech servers and the telephony interface. > > If we decide on pure RTP, then speechsc will have to take on > some SIP-like > qualities. This will probably add considerable to the work > required to get > out a spec. > > I suspect that it will be much easier to have speechsc simply > to set up a > SIP session between the two entities requiring media > connections, and let > SIP do the rest. This means that both the speech server and > the telephony > entity (softswitch, VOIP gateway, Intel/Dialogic card, etc.) > will have to > support the SIP protocol. Luckily, this is an absolutely > STOCK SIP protocol, > no extensions needed. > > Jean Philippe said: > > An extension of MRCP could be the answer. It is a great > protocol, isn't > it? > > And It already works over RTSP (Nuance, Speechworks, Telisma...) > > > Find bellow some extension of MRCP, SPEECHSC could cover: > > - speaker verification, > > - speaker identification, > > - announcement, voice recording, > > - tones detection, tones generation, > > - fax, > > - audio conferencing, > > - video conferencing, > > - chat > > Skip says: > MRCP, or RTSP, or SIP, or extensions to these protocols can't > be used for a > general speechsc protocol, because of the requirement that > the media and > commands be completely separate from each other. MRCP or RTSP > would be fine > if the application entity and the telephony entity resided in > the same box, > but that won't be the case in many future systems. MRCP > cannot deal with the > problem of remote telephony servers separate from the > application servers, > as I described earlier in this discussion. We certainly don't want to > restrict future architectures to require that the application > and telephony > systems must reside in the same box! > > Marc said: > > I agree with the decomposition or unbundling model. > > Although there is no needs to support a multitude of > protocol stacks > profiles (aka > > speechsc over everything), I believe speechsc needs to enable some > separation in > > terms of protocol layers and service interfaces (this is > also a personal > good > > learning of previous model like OSI, TCP/IP... which are > somewhat widely > adopted in > > the SIP, HTTP, SOAP and other work as well). > > Separation of Control pipe and media pipe is also at the > heart of modern > telecoms. > > Skip says: > Absolutely! Spoken like a true believer. In fact. speechsc should be > separated by more than a layered architecure. Speechsc shold > be strictly a > command/response protocol. No media in any of the layers. > Now, within the > speechsc commands you can have a request for the speech server (or the > telephony server) to send a media stream somewhere. The > stream can originate > anywhere, and terminate anywhere else. This is a close as > speechsc should > get to media stream control. > > Marc said: > > Now in terms of technology I guess there are advantages in > the likes of > SIP, SOAP, > > XML (anyway already widely used at the speech grammar or > synthesis level > in the MRCP > > packets for instance), with all the extensibility and > programmability > that they > > provide. > > For instance, SIP can be extended, see the SIPPING an SIMPLE work to > provide open > > framework for other semantic to be built on top of it. SOAP clearly > provides a good > > invocation model for a 'programmable' framework. > > Skip says: > I believe that speechsc's command/response protocol can be > defined as a set > of XML messages. This is probably as open a way of building > the protocol as > any. Now this doesn't mean that SOAP is the best transport > mechanism. SOAP's > synchronous attributes prevent the asynchronous control > functionality needed > by speechsc. I expect that we will come to find that a > SOAP-like xml message > structure, over a more general socket-type protocol (instead > of SOAP's HTTP) > will be the best tradeoff for speechsc. > > As far as the media protocol is concerned, un-modified SIP is > probably the > best candidate to set up and carry the audio between the > speech servers and > the telephony interfaces. So, speechsc would be SOAP-like xml > messages over > a socket-like protocol between the application server and the speech > servers. Meanwhile, un-modified SIP would set up and carry > the media between > the speech resources and the telephony interfaces. > > Skip Cave > Sr. Principal Engineer > Intervoice Inc. > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Dec 30 05:38:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21420 for ; Mon, 30 Dec 2002 05:38:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUAj6424899 for speechsc-archive@odin.ietf.org; Mon, 30 Dec 2002 05:45:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUAj6J24896 for ; Mon, 30 Dec 2002 05:45:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21417 for ; Mon, 30 Dec 2002 05:37:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUAj2J24888; Mon, 30 Dec 2002 05:45:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUAiCJ24864 for ; Mon, 30 Dec 2002 05:44:12 -0500 Received: from ahuumrelay0.ams.ops.eu.uu.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21413 for ; Mon, 30 Dec 2002 05:36:54 -0500 (EST) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay0.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id gBUAe1927131; Mon, 30 Dec 2002 10:40:01 GMT Received: from polo (polo.hq.eloquant.com [192.168.0.131]) by weasel.hq.eloquant.com (Postfix) with SMTP id 43EED3B727; Mon, 30 Dec 2002 05:34:26 -0500 (EST) Reply-To: From: "Brian Wyld" To: "'Brian Eberman'" , "'Eric Burger'" , "'Jean Philippe Longeray'" Cc: Subject: RE: [Speechsc] SPEECHSC vs 3GPP Date: Mon, 30 Dec 2002 11:37:51 +0100 Message-ID: <028201c2afef$81e135e0$8300010a@hq.eloquant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Just a point on this : this will likely require a duplication of media streams (as I am sure that current ASR products are not orientated to providing recorder functionality in parallel). This I think falls into the explicit requirement noted in Dave's requirements doc (section 9, and specifically 9.1.2) although the example given is for simultaneous ASR and SI/SV. Brian [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] > -----Message d'origine----- > De : speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]De la part > de Brian Eberman > Envoyé : Tuesday, December 17, 2002 19:56 > À : Eric Burger; Jean Philippe Longeray > Cc : speechsc@ietf.org > Objet : RE: [Speechsc] SPEECHSC vs 3GPP > > > There is one area that needs more thought that is related to voice > recording. VoiceXML requires that the tag support > termination > based on DTMF recognition against a grammar. It can also > require "hot word" > based recognition. So this kind of voice recording is more > of a recognition > terminated recording and I think we might need to put that in scope. > > -Brian > > -----Original Message----- > From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf Of Eric Burger Sent: Tuesday, December 17, 2002 10:26 AM To: Jean Philippe Longeray Cc: speechsc@ietf.org Subject: RE: [Speechsc] SPEECHSC vs 3GPP The following items are explicitly out of scope. We already have SIP, H.248, and J.162. We don't need yet another protocol to do the same thing. -----Original Message----- From: Jean Philippe Longeray [mailto:jean-philippe.longeray@netcentrex.net] Sent: Tuesday, December 17, 2002 5:00 AM [snip] Find bellow some extension of MRCP, SPEECHSC could cover: [snip] - announcement, voice recording, - tones detection, tones generation, - fax, - audio conferencing, - video conferencing, - chat SPEECHSC could be a Multimedia protocol, not only for Speech but also for Video, Data, FAX ....3G! _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc