Subject: RE: [Speechsc] speechsc protocol issues

From: "Eric Burger" <[email-masked]>
Date: Tue, 17 Dec 2002 19:50:59 -0500

I have to disagree.

Consider the following network architecture:

       +------------------+                              +---------------+
       |   SS7 Gateway    |            SIP               | Media Gateway |
       | (A SIP Endpoint) |------------------------------|   Controller  |
       +------------------+                              +---------------+
                :                                                :
                : Something                                      : H.248
                : (Diameter, H.248, J.162, ...)                  :
                :                                                :
       +-------------------+           RTP               +---------------+
       |   Media Gateway   |-----------------------------| Media Gateway |
       | (An RTP Endpoint) |                             +---------------+
       +-------------------+

This looks to me to be the identical configuration you describe below.  There is absolutely no media being transported by SIP.  That is what RTP is for.  These boxes are clearly different physical boxes.  SS7 gateways definitely DON'T do media.

I don't get the distinction you are making.

SIP and RTSP *explicitly* assume the control and media legs are separate.  That was a design goal that was met.

On the other hand, there is a definite *correlation* between the signaling and media stream, if a media stream is present.  Let's say that differently: you can have a signaling relationship without a media relationship.  Take, for example, SIMPLE (please!).

That correlation is the reason we use SIP and RTSP to do dialog and playback sessions.

-----Original Message-----
From: Skip Cave [mailto:[email-masked]]
Sent: Tuesday, December 17, 2002 6:34 PM
To: [email-masked]
Subject: [Speechsc] speechsc protocol issues

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

---

From: "Jean Philippe Longeray" <[email-masked]>
Date: Wed, 18 Dec 2002 08:44:06 +0100

Good morning,

I agree Eric, SIP can be use everywhere, with or without media... just to
have a look to 3GPP which takes advantage of SIP, whitout media.

SDP or RTP mean, mostly, media, SIP doesn't. We also use H.323 for data
only, X.25 for voice, J.162 for conferencing, MGCP for Modems..

One thing : I'm sure that XML and SOAP could be a very good approach (even
if I prefer X.680 (ASN.1) notation, X.690 (BER) encoding and Q.771 (TCAP)
for transaction, but implementation are much more expensive..).

I understand also, that SPEECHSC doesn't want to care about Media
Architecture, but only Application Protocol in order to control ASR, TTS...

I think another WG could have a look on 3GPP, 3GPP2, MWIF, WIN(ANSI-41),
CAMEL(GSM), CS.4 (PINT), because all of them have the same problem to use
media resources, and propose so different solutions. If someone could
propose something mostly common to access to the same thing ;-)

Have a nice day.

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 Eric Burger
Sent: mercredi 18 décembre 2002 01:51
To: Skip Cave
Cc: [email-masked]
Subject: RE: [Speechsc] speechsc protocol issues

I have to disagree.

This looks to me to be the identical configuration you describe below.
There is absolutely no media being transported by SIP.  That is what RTP is
for.  These boxes are clearly different physical boxes.  SS7 gateways
definitely DON'T do media.

SIP and RTSP *explicitly* assume the control and media legs are separate.
That was a design goal that was met.

On the other hand, there is a definite *correlation* between the signaling
and media stream, if a media stream is present.  Let's say that differently:
you can have a signaling relationship without a media relationship.  Take,
for example, SIMPLE (please!).

That correlation is the reason we use SIP and RTSP to do dialog and playback
sessions.

-----Original Message-----
From: Skip Cave [mailto:[email-masked]]
Sent: Tuesday, December 17, 2002 6:34 PM
To: [email-masked]
Subject: [Speechsc] speechsc protocol issues

Here are my comments on several of the issues discussed in the last few
posts:

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.

             +-------------+
             | application |_________
             |   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...

                 : whatever                                :   Internal
protocol
                 :                                         :   Proprietary
to speech
                 :                                         :   server
vendors

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.

>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.

> 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.

> 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.

>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?

> 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.

> 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.

> - tones detection, tones generation,

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!

> 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.

> 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.

---

From: "Brian Wyld" <[email-masked]>
Date: Mon, 30 Dec 2002 11:31:49 +0100

Hi Jean-Philippe,

> for transaction, but implementation are much more expensive..).

I'm awaiting an updated analysis for the webServices protocol section...

IMHO, there are a couple of issues with the web services approach today:
 - no asynchronous events from server to client (I understand this may be
being looked at generally anyway, but today the only method I've seen is an
ugly 'reverse service' type hack)
 - heavy protocol stack (lots of text, lots of bytes)
 - need to re-invent the media setup section (although this could be just an
encapsulated SDP block?)

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 which I'm not convinced is justified
here. The speechsc charter is currently very narrow....

At the scope we're currently discussing, I think XML+SOAP and ASN.1/BER+TCAP
are the same functionally and architecturally..... it's just one side is
pure web and the other pure telecom -> the main difference is the cost and
the thickness of the spec.....

> Architecture, but only Application Protocol in order to

Hmmm. I don't agree - speechsc must I think address the media architecture
(which is different from processing the media....) as after all the whole
objective is to process the media..... The media path will be certainly
separate (as Eric has already expounded....)

> propose something mostly common to access to the same thing ;-)

Can I encourage you then to create a protocol analysis section for these
solutions (using the template document of course and covering the same items
as the other sections)? This would ensure that we didn't ignore something
useful, and that they can be discussed in the same framework as other
contendors.

cheers,

Brian

> From: [email-masked]
> [mailto:[email-masked]]On Behalf
> Of Eric Burger
>                 : Something
>    : H.248
>                     :                   /     RTP
>                     :                  /
>                  : whatever                                :
>  Internal
>  Proprietary
> > - a layer OVER a media signalling protocol (SIP, RTSP, etc,
> depending on
> this lower layer
> > - an extension to an existing media signalling protocol
> (eg, add MRCP
> "verbs" as new
> > - [should we uuse] a new protocol incorporating both media
> signalling,
> session
> > 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
> > 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
> > 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:
> > 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
> > An extension of MRCP could be the answer. It is a great
> protocol, isn't
> it?
> > Although there is no needs to support a  multitude of
> protocol stacks
> profiles (aka
> > 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
> > Separation of Control pipe and media pipe is also at the
> heart of modern
> telecoms.
>
> Skip says:
> > 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.