Subject: RE: [Speechsc] speechsc protocol issues

From: "BRANDT,MARC (HP-France,ex2)" <[email-masked]>
Date: Mon, 6 Jan 2003 16:14:14 +0100

> From: Brian Wyld [mailto:[email-masked]]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "Jean Philippe Longeray" <[email-masked]>
Date: Mon, 6 Jan 2003 16:37:52 +0100

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

[email-masked]
<mailto:[email-masked]>
+ 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: [email-masked] [mailto:[email-masked]]On Behalf
Of BRANDT,MARC (HP-France,ex2)
Sent: lundi 6 janvier 2003 16:14
To: [email-masked]; [email-masked]
Subject: RE: [Speechsc] speechsc protocol issues

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
.

---

From: "Neil Deason" <[email-masked]>
Date: Mon, 6 Jan 2003 10:11:00 -0800

> From: [email-masked]
> [mailto:[email-masked]]On Behalf
> 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
> 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.

<snip>