Subject: [Speechsc] speechsc protocol issues

From: "Skip Cave" <[email-masked]>
Date: Tue, 17 Dec 2002 17:34:22 -0600

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.