Subject: [Speechsc] SPEECHSC & usage of SIP

From: Skip Cave <[email-masked]>
Date: Wed, 04 Dec 2002 19:33:27 -0600

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.