From mailnull@www1.ietf.org Mon Jan 6 10:15:37 2003 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 KAA05184 for ; Mon, 6 Jan 2003 10:15:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06FPrs23670 for speechsc-archive@odin.ietf.org; Mon, 6 Jan 2003 10:25: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 h06FPrJ23667 for ; Mon, 6 Jan 2003 10:25:53 -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 KAA05177 for ; Mon, 6 Jan 2003 10:15: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 h06FMLJ23502; Mon, 6 Jan 2003 10:22: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 h06FLpJ23428 for ; Mon, 6 Jan 2003 10:21:51 -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 KAA05115 for ; Mon, 6 Jan 2003 10:11:03 -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 B07FC1E7; Mon, 6 Jan 2003 16:14:16 +0100 (MET) Received: by garonne.grenoble.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 6 Jan 2003 16:14:16 +0100 Message-ID: <468579AFDE99E74DB926952FCDE3D657065EF4B5@dumas.grenoble.hp.com> From: "BRANDT,MARC (HP-France,ex2)" To: brian.wyld@eloquant.com, speechsc@ietf.org Subject: RE: [Speechsc] speechsc protocol issues Date: Mon, 6 Jan 2003 16:14:14 +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: , > From: Brian Wyld [mailto:brian.wyld@eloquant.com] > IMHO, there are a couple of issues with the web services > approach today: > - no asynchronous events from server to client ( I tend to agree that a pure/mere web services model is maybe difficult to meet all the speechsc reqs (not taking into account possible evolutions). imho this is mainly a limitation of the underlying HTTP mapping. A mapping of message invocation on top of/in association with a richer protocol, e.g. like a SIP, might provide easier ways to meet these command/response/notify models speechsc need. A session oriented transport provides a richer and more extensible invocation model, enabling mid-communications exchanges and notifications. > - heavy protocol stack (lots of text, lots of bytes) would you think it is really a SOAP overhead or more generally the use of XML ? (which is in any case widely used elsewhere in the requests, SSML, grammar... ). Also most of IETF candidates are text-based. > > 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 .... This is also where speechsc might provide some better tuned messages that would not require the whole (soap-like) overhead, but limited to very frequent and common functions across resources, leaving the rest of the framework extensible to represent any kind of invocations without specifications burden (with maybe evolution that could cope with new optimized messages introduction over time). One must not mix the 'genericity' of an existing technology like web services and the somewhat generic, I prefer extensible, needs that invoking a media resources require. I agree that web services as is would meet all the reqs with difficulty, but there are good aspects in different technos that speechsc could combine. Speechsc can provide very specific and tuned capacities using existing technology, and especially for the functions that are independent of the type of resources. And at the same time provide extensibility for plugging new media resources semantic very easily and under the openness and control of the applications. > Brian W > > 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 I agree with the disagreement, speechsc shall build the protocol on top of an architecture and not vice versa. The protocol is surely used to serve the applications, but in a distributed and architected framework for media/speech resources as specified so far. > > > > 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. Yes, that was typically the intention when mentioning SOAP. HTTP might not be the right mapping, but the extensibility of the messaging framework has some key interests. > > Skip says: > > 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. > > > > While not forgetting that unmodified-but-fully-extended SIP (e.g. sipping/simple extensions) can provide an asynchronous or command/response/notify model and carry semantic messages as well. Including capabilities that you can set up a session without setting up the media immediately, you can also suspend the media, thus leaving the room for early communications/invocations of functions (see for instance 3rd party call control ....). And also transport mid-session data. (to the analogy of RTSP/MRCP ANNOUNCE). _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Jan 6 10:43:59 2003 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 KAA05802 for ; Mon, 6 Jan 2003 10:43:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06FsGx25506 for speechsc-archive@odin.ietf.org; Mon, 6 Jan 2003 10:54: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 h06FsGJ25503 for ; Mon, 6 Jan 2003 10:54: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 KAA05772 for ; Mon, 6 Jan 2003 10:43:26 -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 h06Fs4J25484; Mon, 6 Jan 2003 10:54: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 h06FrSJ25441 for ; Mon, 6 Jan 2003 10:53:28 -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 KAA05753 for ; Mon, 6 Jan 2003 10:42:38 -0500 (EST) Received: from jpl (jpl.mg2-lyon.fr [132.147.160.27]) by slap.mg2-lyon.fr (Postfix) with SMTP id 159CF10F25 for ; Mon, 6 Jan 2003 17:34:22 +0100 (CET) From: "Jean Philippe Longeray" To: Subject: RE: [Speechsc] speechsc protocol issues Date: Mon, 6 Jan 2003 16:37:52 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <468579AFDE99E74DB926952FCDE3D657065EF4B5@dumas.grenoble.hp.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 Happy new year to WorkGroup! Marc Brandt says : "Mapping of message invocation on top of/in association with a richer protocol, e.g. like a SIP, might provide easier ways to meet these command/response/notify models speechsc need. A session oriented transport provides a richer and more extensible invocation model, enabling mid-communications exchanges and notifications" >>>> Sure! Marc Brandt says : "I agree with the disagreement, speechsc shall build the protocol on top of an architecture and not vice versa. The protocol is surely used to serve the applications, but in a distributed and architected framework for media/speech resources as specified so far" >>>> Great! It's a good news for me, that's why I've proposed a simple architecture : SIP +-------------+ ---------| application |_________ H.323 | entity | \ SIP(speechsc/other) +-------------+ +------------------------+ : + Media Resource Locator + : +------------------------+ \ SIP(speechsc/other) +-------------+ : \------------------------| Speech |+ : H.248,MGCP | Processing ||+ : ------------------------| Resource(s) ||| : / RTP +-------------+|| : / +-------------+| +----------+ / +-------------+ RTP | RTP | / ----------| Relay |----------- +----------+ RTP relay : Replicator, coder and / or conference bridge for Voice resources (Recording voice and ASR at same time for example, regenerating silent packets for ASR, managing RTCP, RSVP and QOS, mixing TTS and audio, ...) Media resource locator : Is like a "gatekeeper" or "Registrar" for Resources (load balacing, rights, ...) Speech processing resources : Includes all kind of resources (Video, Audio, ASR, TTS,...). Application entity : VXML interpretor, prioprietary SCE ... 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 BRANDT,MARC (HP-France,ex2) Sent: lundi 6 janvier 2003 16:14 To: brian.wyld@eloquant.com; speechsc@ietf.org Subject: RE: [Speechsc] speechsc protocol issues > From: Brian Wyld [mailto:brian.wyld@eloquant.com] > IMHO, there are a couple of issues with the web services > approach today: > - no asynchronous events from server to client ( I tend to agree that a pure/mere web services model is maybe difficult to meet all the speechsc reqs (not taking into account possible evolutions). imho this is mainly a limitation of the underlying HTTP mapping. A mapping of message invocation on top of/in association with a richer protocol, e.g. like a SIP, might provide easier ways to meet these command/response/notify models speechsc need. A session oriented transport provides a richer and more extensible invocation model, enabling mid-communications exchanges and notifications. > - heavy protocol stack (lots of text, lots of bytes) would you think it is really a SOAP overhead or more generally the use of XML ? (which is in any case widely used elsewhere in the requests, SSML, grammar... ). Also most of IETF candidates are text-based. > > 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 .... This is also where speechsc might provide some better tuned messages that would not require the whole (soap-like) overhead, but limited to very frequent and common functions across resources, leaving the rest of the framework extensible to represent any kind of invocations without specifications burden (with maybe evolution that could cope with new optimized messages introduction over time). One must not mix the 'genericity' of an existing technology like web services and the somewhat generic, I prefer extensible, needs that invoking a media resources require. I agree that web services as is would meet all the reqs with difficulty, but there are good aspects in different technos that speechsc could combine. Speechsc can provide very specific and tuned capacities using existing technology, and especially for the functions that are independent of the type of resources. And at the same time provide extensibility for plugging new media resources semantic very easily and under the openness and control of the applications. > Brian W > > 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 I agree with the disagreement, speechsc shall build the protocol on top of an architecture and not vice versa. The protocol is surely used to serve the applications, but in a distributed and architected framework for media/speech resources as specified so far . > > > > 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. Yes, that was typically the intention when mentioning SOAP. HTTP might not be the right mapping, but the extensibility of the messaging framework has some key interests. > > Skip says: > > 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. > > > > While not forgetting that unmodified-but-fully-extended SIP (e.g. sipping/simple extensions) can provide an asynchronous or command/response/notify model and carry semantic messages as well. Including capabilities that you can set up a session without setting up the media immediately, you can also suspend the media, thus leaving the room for early communications/invocations of functions (see for instance 3rd party call control ....). And also transport mid-session data. (to the analogy of RTSP/MRCP ANNOUNCE). _______________________________________________ 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 Jan 6 13:12:37 2003 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 NAA09197 for ; Mon, 6 Jan 2003 13:12:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06IMwh02835 for speechsc-archive@odin.ietf.org; Mon, 6 Jan 2003 13:22:58 -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 h06IMwJ02832 for ; Mon, 6 Jan 2003 13:22:58 -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 NAA09165 for ; Mon, 6 Jan 2003 13:11: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 h06IJ6J02623; Mon, 6 Jan 2003 13:19: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 h06IIbJ02600 for ; Mon, 6 Jan 2003 13:18:37 -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 NAA09074 for ; Mon, 6 Jan 2003 13:07:44 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for [132.151.6.1]) with SMTP; 6 Jan 2003 18:10:04 UT Received: from gbnewp1014m ([172.25.1.88]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.4905); Mon, 6 Jan 2003 18:11:02 +0000 From: "Neil Deason" To: "BRANDT,MARC \(HP-France,ex2\)" , , Subject: RE: [Speechsc] speechsc protocol issues Date: Mon, 6 Jan 2003 10:11:00 -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) In-Reply-To: <468579AFDE99E74DB926952FCDE3D657065EF4B5@dumas.grenoble.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 06 Jan 2003 18:11:02.0431 (UTC) FILETIME=[F8E242F0:01C2B5AE] 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: speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]On Behalf > Of BRANDT,MARC (HP-France,ex2) > > > From: Brian Wyld [mailto:brian.wyld@eloquant.com] > > IMHO, there are a couple of issues with the web services > > approach today: > > - no asynchronous events from server to client ( > > I tend to agree that a pure/mere web services model is maybe > difficult to meet all the speechsc reqs (not taking into account > possible evolutions). > > imho this is mainly a limitation of the underlying HTTP mapping. > A mapping of message invocation on top of/in association with > a richer protocol, e.g. like a SIP, might provide easier ways to meet these > command/response/notify models speechsc need. A session oriented > transport provides a richer and more extensible invocation model, > enabling mid-communications exchanges and notifications. SIP is a poor choice as a transport protocol for SOAP. SIP is intended for initiating, modifying and terminating sessions. To achieve this it has features such as forking requests to multiple hosts, sending SIP messages over UDP, which make it non-optimal as a generic data transfer protocol. But there are a few ways that you could try to make this work, while still leveraging benefits of SIP in the overall solution: - If you have mainly RPC style messaging + asynchronous events you can use SIP to set up a SOAP/HTTP session in one direction (C->S) and SIP's event framework for SUBSCRIBE/NOTIFY in the other direction (S->C). - Use SIP to set up SOAP/HTTP sessions in both directions to allow bi-directional p2p SOAP messaging. Just as you use SIP to set up RTP streams in both direction in a duplex audio session. - Use SIP to set up a SOAP/BEEP session. That would give you a framework that is powerful enough to do just about anything. Of those possibilities I think the last one is the most interesting. Cheers, Neil. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Jan 13 03:32:54 2003 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 DAA04360 for ; Mon, 13 Jan 2003 03:32:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0D8kQj04656 for speechsc-archive@odin.ietf.org; Mon, 13 Jan 2003 03:46: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 h0D8kQJ04653 for ; Mon, 13 Jan 2003 03:46:26 -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 DAA04351 for ; Mon, 13 Jan 2003 03:32: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 h0D8kFJ04632; Mon, 13 Jan 2003 03:46: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 h0D8jDJ04588 for ; Mon, 13 Jan 2003 03:45:13 -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 DAA04339 for ; Mon, 13 Jan 2003 03:31:09 -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 EC6FDC4 for ; Mon, 13 Jan 2003 09:34:27 +0100 (MET) Received: by garonne.grenoble.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 13 Jan 2003 09:34:27 +0100 Message-ID: <468579AFDE99E74DB926952FCDE3D657067AB80E@dumas.grenoble.hp.com> From: "BRANDT,MARC (HP-France,ex2)" To: speechsc@ietf.org Subject: RE: [Speechsc] speechsc protocol issues Date: Mon, 13 Jan 2003 09:34:23 +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: , Initially on this thread I put a question re the MMUSIC activity below. I have not seen yet opinions of SPEECHSC on that ? (other refs: 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 ) > -----Original Message----- > From: Orit Levin [mailto:orit@radvision.com] > Sent: Wednesday, December 18, 2002 4:48 PM > To: 'Colin Perkins'; mmusic@ietf.org > Cc: minutes@ietf.org; jo@tzi.uni-bremen.de > Subject: RE: [MMUSIC] Draft MMUSIC minutes from Atlanta > > > > According to my recollection, the chairs expressed their will > to consult the > IETF authorities regarding the place this kind of work should > take and come > back with the answer. > > Thanks, > Orit Levin > Chief Architect > RADVISION > Phone: +1.201.6896330 > Video: +1.201.6896430 > > > > XML Schema for Media Control > ...skip > > Jonathan Rosenberg noted that this might be a perfect > candidate for a > > SOAP protocol, signalled in SDP? Henning agreed that > SOAP works today, > > but there is a need for a way of associating SOAP > connections with a > > media stream, in SDP. Orit asked where should we do SOAP > work, since > > it is unclear if MMUSIC is the appropriate forum? The > answer seems to > > depend on the form of the final solution. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic Marc Brandt - mailto:Marc.Brandt@hp.com Hewlett-Packard - OpenCall Business Unit http://www.hp.com/go/opencall/ _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu Jan 16 13:43:08 2003 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 NAA20045 for ; Thu, 16 Jan 2003 13:43:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GIwLX13990 for speechsc-archive@odin.ietf.org; Thu, 16 Jan 2003 13:58: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 h0GIwKJ13987 for ; Thu, 16 Jan 2003 13:58:21 -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 NAA20016 for ; Thu, 16 Jan 2003 13:42:37 -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 h0GIwBJ13975; Thu, 16 Jan 2003 13:58: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 h0GIviJ13931 for ; Thu, 16 Jan 2003 13:57:44 -0500 Received: from ha1.kirusa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19996 for ; Thu, 16 Jan 2003 13:42:00 -0500 (EST) Received: from kirusa.com (lanuser67.kirusa.com [192.168.220.67] (may be forged)) (authenticated bits=0) by ha1.kirusa.com (8.12.3/8.12.3) with ESMTP id h0GIjLEv079980 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 16 Jan 2003 13:45:22 -0500 (EST) (envelope-from sibal@kirusa.com) X-Authentication-Warning: ha1.kirusa.com: Host lanuser67.kirusa.com [192.168.220.67] (may be forged) claimed to be kirusa.com Message-ID: <3E26FDC3.7010804@kirusa.com> Date: Thu, 16 Jan 2003 13:45:23 -0500 From: Sandeep Sibal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: speechsc@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Speechsc] end-pointing 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 SpeechSC, as I understand it, is intended to be a control protocol that has been separated from the media/RTP streams - by design. While this separation is elegant, it can also be problematic when there is a need to align/synchronize the dispatch of SpeechSC control messages (e.g., start recognition) with the end-pointing of speech in the audio streams generated by push-to-talk systems. I was wondering if this issue has been already addressed by this group. BTW, this came up in a discussion on SALT and SpeechSC with Eric, and Eric suggested I send this out to the group. Nothing SALT-specific in the observation though. Sandeep. -- Sandeep Sibal Founder & CTO, Kirusa +1 908-464-4467 x2000 Mobile: +1 908-416-8500 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu Jan 16 15:22:06 2003 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 PAA22961 for ; Thu, 16 Jan 2003 15:22:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GKbLG21260 for speechsc-archive@odin.ietf.org; Thu, 16 Jan 2003 15:37: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 h0GKbLJ21249 for ; Thu, 16 Jan 2003 15:37:21 -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 PAA22958 for ; Thu, 16 Jan 2003 15:21: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 h0GKb8J20969; Thu, 16 Jan 2003 15:37: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 h0GKatJ20767 for ; Thu, 16 Jan 2003 15:36:55 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22950 for ; Thu, 16 Jan 2003 15:21:08 -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: Thu, 16 Jan 2003 15:24:28 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2DF720@zoe.office.snowshore.com> Thread-Topic: [Speechsc] speechsc protocol issues Thread-Index: AcK64djWk0k6jvI8TKyxeqOR/9eGVwCu1qxw From: "Eric Burger" To: "BRANDT,MARC (HP-France,ex2)" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GKatJ20768 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 Is there any pertinence of floor control to ASR/TTS/SV? > -----Original Message----- > From: BRANDT,MARC (HP-France,ex2) [mailto:marc.brandt@hp.com] > Sent: Monday, January 13, 2003 3:34 AM > To: speechsc@ietf.org > Subject: RE: [Speechsc] speechsc protocol issues > > > > Initially on this thread I put a question re the MMUSIC > activity below. > I have not seen yet opinions of SPEECHSC on that ? > > > (other refs: > XML Schema for Media Control in the mmusic minutes > http://www1.ietf.org/mail-archive/working-groups/mmusic/curren > t/msg01105.htm > l > draft-levin-mmusic-xml-media-control-00.txt > http://www.ietf.org/internet-drafts/draft-levin-mmusic-xml-med > ia-control-00. > txt > ) > > > > -----Original Message----- > > From: Orit Levin [mailto:orit@radvision.com] > > Sent: Wednesday, December 18, 2002 4:48 PM > > To: 'Colin Perkins'; mmusic@ietf.org > > Cc: minutes@ietf.org; jo@tzi.uni-bremen.de > > Subject: RE: [MMUSIC] Draft MMUSIC minutes from Atlanta > > > > > > > > According to my recollection, the chairs expressed their will > > to consult the > > IETF authorities regarding the place this kind of work should > > take and come > > back with the answer. > > > > Thanks, > > Orit Levin > > Chief Architect > > RADVISION > > Phone: +1.201.6896330 > > Video: +1.201.6896430 > > > > > > > XML Schema for Media Control > > ...skip > > > Jonathan Rosenberg noted that this might be a perfect > > candidate for a > > > SOAP protocol, signalled in SDP? Henning agreed that > > SOAP works today, > > > but there is a need for a way of associating SOAP > > connections with a > > > media stream, in SDP. Orit asked where should we do SOAP > > work, since > > > it is unclear if MMUSIC is the appropriate forum? The > > answer seems to > > > depend on the form of the final solution. > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > Marc Brandt - mailto:Marc.Brandt@hp.com > Hewlett-Packard - OpenCall Business Unit > http://www.hp.com/go/opencall/ > _______________________________________________ > 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 Thu Jan 16 15:26:04 2003 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 PAA23084 for ; Thu, 16 Jan 2003 15:26:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GKfKl21721 for speechsc-archive@odin.ietf.org; Thu, 16 Jan 2003 15:41: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 h0GKfKJ21718 for ; Thu, 16 Jan 2003 15:41:20 -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 PAA23059 for ; Thu, 16 Jan 2003 15:25: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 h0GKf9J21699; Thu, 16 Jan 2003 15:41: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 h0GKeWJ21664 for ; Thu, 16 Jan 2003 15:40:32 -0500 Received: from crufty.research.bell-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23034 for ; Thu, 16 Jan 2003 15:24:46 -0500 (EST) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0GKS8LI007470; Thu, 16 Jan 2003 15:28:08 -0500 (EST) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0GKS2I77585; Thu, 16 Jan 2003 15:28:02 -0500 (EST) Received: from lucent.com (bass.research.bell-labs.com [135.104.32.232]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id PAA1920317; Thu, 16 Jan 2003 15:28:00 -0500 (EST) Message-ID: <3E2715D0.7A236BE8@lucent.com> Date: Thu, 16 Jan 2003 15:28:00 -0500 From: Qiru Zhou Reply-To: qzhou@research.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh-CN,zh-TW MIME-Version: 1.0 To: Sandeep Sibal CC: speechsc@ietf.org Subject: Re: [Speechsc] end-pointing References: <3E26FDC3.7010804@kirusa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Sandeep, Separate control from media stream has been practical in many speech engine implementations, including several popular APIs such as JSAPI and MS SAPI 4/5. Of course, you need some signaling or events generated from audio object (the provider of receiver of audio streams for speech engines) in soft real time. This separation gives more flexibilty for component based speech engine implementation, but needs some more work to align/synch the message as you said. Basically, I prefer asynchronized control verses synchronized speech engine control since it has better scalability and gives more flexibility for advanced feature implementation and have better . And you can always synchronize them at higher level for a synchronized interface. Please let me know if I addressed your concern or not. -- Qiru Sandeep Sibal wrote: > > SpeechSC, as I understand it, is intended to be a control protocol that > has been separated from the media/RTP streams - by design. > > While this separation is elegant, it can also be problematic when there > is a need to align/synchronize the dispatch of SpeechSC control messages > (e.g., start recognition) with the end-pointing of speech in the audio > streams generated by push-to-talk systems. > > I was wondering if this issue has been already addressed by this group. > > BTW, this came up in a discussion on SALT and SpeechSC with Eric, and > Eric suggested I send this out to the group. Nothing SALT-specific in > the observation though. > > Sandeep. > > -- > Sandeep Sibal > Founder & CTO, Kirusa > +1 908-464-4467 x2000 > Mobile: +1 908-416-8500 > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc -- ============================================================================== Qiru Zhou (http://www.multimedia.bell-labs.com) Multimedia Technology Research Bell Laboratories, Lucent Technologies 600 Mountain Avenue, 2D428, Murray Hill, NJ 07974, USA tel +1 908 582 4562 | fax +1 908 582 7308 | qzhou@research.bell-labs.com ============================================================================== _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Jan 21 13:45:49 2003 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 NAA08343 for ; Tue, 21 Jan 2003 13:45:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LJ3Tk07964 for speechsc-archive@odin.ietf.org; Tue, 21 Jan 2003 14:03: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 h0LJ3TJ07961 for ; Tue, 21 Jan 2003 14:03:29 -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 NAA08296 for ; Tue, 21 Jan 2003 13:45:18 -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 h0LJ3IJ07924; Tue, 21 Jan 2003 14:03: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 h0LJ2KJ07849 for ; Tue, 21 Jan 2003 14:02:20 -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 NAA08223 for ; Tue, 21 Jan 2003 13:44:09 -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; 21 Jan 2003 18:46:35 UT Received: from gbnewp1014m ([172.25.1.88]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.4905); Tue, 21 Jan 2003 18:47:37 +0000 From: "Neil Deason" To: "Eric Burger" , "BRANDT,MARC \(HP-France,ex2\)" , Subject: RE: [Speechsc] speechsc protocol issues Date: Tue, 21 Jan 2003 10:47:34 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <4A3384433CE2AB46A63468CB207E209D2DF720@zoe.office.snowshore.com> X-OriginalArrivalTime: 21 Jan 2003 18:47:37.0338 (UTC) FILETIME=[9158BDA0:01C2C17D] 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 > From: speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]On Behalf Of Eric Burger > > Is there any pertinence of floor control to ASR/TTS/SV? This draft is about control of video streams in SIP environments. You may be thinking of http://www.ietf.org/internet-drafts/draft-wu-sipping-floor-control-03.tx t. Any how - direct relevance probably not and now doesn't feel like the time to expand the Speechsc problem space. But a solution for Speechsc that provides an extensible framework that is applicable across the wider MPE|AS<->MS interface would be kinda cool. Some MS support additional capabilities, such as video, conferencing, etc., in addition to ASR/TTS/SV so single control interface would be a good thing. > > From: BRANDT,MARC (HP-France,ex2) [mailto:marc.brandt@hp.com] > > > > Initially on this thread I put a question re the MMUSIC activity below. > > I have not seen yet opinions of SPEECHSC on that ? I think the summation that SOAP is an interesting candidate for media control is relevant to Speechsc, it could provide the type of extensible framework alluded to above. I think Henning's concern about associating SOAP connections with the media stream in SDP is a solvable problem (http://www.ietf.org/mail-archive/working-groups/sipping/current/msg0352 9.html). As for where in the IETF could this be worked on - for ASR/TTS/SV right here. Cheers, Neil. > > > > (other refs: > > XML Schema for Media Control in the mmusic minutes > > http://www1.ietf.org/mail-archive/working-groups/mmusic/curren > > t/msg01105.htm > > l > > draft-levin-mmusic-xml-media-control-00.txt > > http://www.ietf.org/internet-drafts/draft-levin-mmusic-xml-med > > ia-control-00. > > txt > > ) > > > > > > > -----Original Message----- > > > From: Orit Levin [mailto:orit@radvision.com] > > > Sent: Wednesday, December 18, 2002 4:48 PM > > > To: 'Colin Perkins'; mmusic@ietf.org > > > Cc: minutes@ietf.org; jo@tzi.uni-bremen.de > > > Subject: RE: [MMUSIC] Draft MMUSIC minutes from Atlanta > > > > > > > > > > > > According to my recollection, the chairs expressed their will > > > to consult the > > > IETF authorities regarding the place this kind of work should > > > take and come > > > back with the answer. > > > > > > Thanks, > > > Orit Levin > > > Chief Architect > > > RADVISION > > > Phone: +1.201.6896330 > > > Video: +1.201.6896430 > > > > > > > > > > XML Schema for Media Control > > > ...skip > > > > Jonathan Rosenberg noted that this might be a perfect > > > candidate for a > > > > SOAP protocol, signalled in SDP? Henning agreed that > > > SOAP works today, > > > > but there is a need for a way of associating SOAP > > > connections with a > > > > media stream, in SDP. Orit asked where should we do SOAP > > > work, since > > > > it is unclear if MMUSIC is the appropriate forum? The > > > answer seems to > > > > depend on the form of the final solution. > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > Marc Brandt - mailto:Marc.Brandt@hp.com > > Hewlett-Packard - OpenCall Business Unit > > http://www.hp.com/go/opencall/ > > _______________________________________________ > > 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