Subject: RE: [Speechsc] SPEECHSC & usage of SIP

From: "Eric Burger" <[email-masked]>
Date: Thu, 5 Dec 2002 22:23:26 -0500

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

---

From: "Neil Deason" <[email-masked]>
Date: Sat, 7 Dec 2002 14:37:41 -0800

> -----Original Message-----
> From: Skip Cave [mailto:[email-masked]]
>
> 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.
>
> 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
> 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.

> 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

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.

> 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:[email-masked] SIP/2.0
    To: sip:[email-masked]
    From: [email-masked]
    Call-ID: [email-masked]
    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
[email-masked]                    Suite 345
Ubiquity Software Corporation           Redwood City, CA
http://www.ubiquity.net                 USA