Subject: [Speechsc] speechsc model [was RE: SPEECHSC vs 3GPP]

From: "Eric Burger" <[email-masked]>
Date: Tue, 17 Dec 2002 10:22:13 -0500

On the use of SIP for MRCP transport: draft-robinson-mrcp-sip-00 is what drove me to realize that the MRCP tunneling approach was broken.  That is not to say that it would be wrong to raise MRCP into SIP.  However, given the existing semantics for RTSP and TTS, that may be a better way to go.  On the other hand, the answer to your question is, "yes": the Robinson draft shows SIP for signaling, not media.

On the speechsc model, how does this look:

             +-------------+
             | application |_________
             |   entity    |         \
             +-------------+          \
                    :                  \    speechsc    +-------------+
                    :                   \---------------| Speech      |+
                    : whatever                          | Processing  ||+
                    :                    ---------------| Resource(s) |||
                    :                   /     RTP       +-------------+||
                    :                  /                 +-------------+|
              +----------+            /                   +-------------+
              |   RTP    |           /
              |  entity  |-----------
              +----------+

The speechsc perspective on the world has really only three logical elements.  There is an application entity, which can be (for example ONLY) an application server, a VoiceXML browser, a SALT browser, a Java Bean, a handset, a media server, etc.  There is a RTP entity, which is a source of RTP for the speech processing resource, which can be (for example ONLY) a phone, a media gateway, a VoiceXML or SALT browser, etc.  Speech processing resources are the ASR, TTS, and SI/SV engines.  Note the application entity and RTP entity may be combined, decomposed, or have various bits decomposed and combined.

Do we care about rearranging or embellishing these three basic components?  I don't think it will materially affect the protocol analysis.

-----Original Message-----
From: Jean Philippe Longeray [mailto:[email-masked]]
Sent: Tuesday, December 17, 2002 2:33 AM
To: Skip Cave; [email-masked]
Cc: Eric Burger
Subject: RE: [Speechsc] SPEECHSC vs 3GPP

Hi skip,

You're right, I didn't say something different. 

Like MRCP, SPEECHSC is a media command protocol. SIP is not only a streaming protocol, It can be used as a transport protocol, like HTTP, X.224, ... If SIP transports SDP, it becomes a streaming protocol, but what don't you thing it's not possible to transport SPEECHSC messages in SIP Content.

In your document, something is missing: You need something to find an Resource Server (ASR, SVI, TTS), and I propose to use SIP softswitching,
This softswitch could be inserted between your Application Execution Server and all others voice resource (It could be ASR, TTS, SVI, but also Audio/Video streaming, conferencing, ....)

I think that draft-robinson-mrcp-sip-00 is a great example that I want to say. Do you agree Eric?

Best regards.

Jean-Philippe LONGERAY 
R&D Director - Service NODE

NetCentrex 

[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: Skip Cave [mailto:[email-masked]]
Sent: lundi 16 décembre 2002 20:47
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Speechsc] SPEECHSC vs 3GPP

Eric, Jean,

It's good that we agree. I believe that there has been some confusion in the past that SpeechSC is a media streaming protocol. We need to list the basic issues to make sure that we clear up that misconception: 

1) SpeechSC is NOT a media streaming protocol.
2) The SpeechSC protocol is strictly a command/response protocol, carrying commands and returning responses from application servers to speech servers. The SpeechSC protocol will never be a media transport protocol, and will never carry any type of media. 
3) Even though the SpeechSC protocol is not a media transport protocol, the SpeechSC protocol can be used to COMMAND speech servers to set up streaming with another server using some type of streaming protocol (like SIP). Which streaming protocol is used will be determined as part of the SpeechSC's work.

For example, in my attached architecture diagram, the SpeechSC protocol allows an Application Server commanding an ASR server to set up a SIP session between the ASR server and a telephony platform (see attached figure). Note that there is a SpeechSC command/control session between the Application Server and the ASR Server, but there is no streaming media going betweeen the Application & ASR Servers. There IS a standard SIP session between the Speech server and the Telephony platform, that was set up by commands given in the SpeechSC protocol. This SIP session does NOT carry any commands other than standard SIP setup/teardown commands. 

An example of the command/response sequence in a SpeechSC Command stream would be:

Request from Application server to Directory Services for an ASR server
Reply from Directory Services To Application Server giving info on specific ASR Server
Command from Application Server to ASR Server to set up a specific command/ response session for a call (one command session per call context)
Response from ASR Server to Application Server acknowledging the completion of the session set-up.
Command from Application Server to selected ASR server to set up SIP session with a specific Telephony Server. The App Server gives the ASR server the addresses of the Telephony Server so the App Server can set up the SIP session. 
(ASR Server sets up SIP Session to Telephony Server))
Response from ASR Server indicating successful SIP session setup.
Command from Application Server to ASR Server to set up grammars and start recognition on ASR Server.
Response from ASR Server to Application Server reporting a grammar match or timeout from ASR Server.
etc. 

Again, this is shown in mu attached diagram.

Skip Cave 
Sr. Principal Engineer
Intervoice Inc.

>>> "Eric Burger" <[email-masked]> 12/16/02 08:29AM >>>
From a personal perspective, the MRCP over SIP proposal was what pushed me over the edge to fix MRCP.  I would be hard pressed to try to convince the IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, ...  We need to pick the one that makes the most sense.

-----Original Message-----
From: Jean Philippe Longeray [mailto:[email-masked]]
Sent: Monday, December 16, 2002 3:12 AM
To: Skip Cave; Eric Burger
Cc: [email-masked]
Subject: RE: [Speechsc] SPEECHSC vs 3GPP

Hi Skip,

Nice to have some news from Intervoice...

I agree. SIP  will never provide  multimedia control functionnalities, but I'm sure it's a great protocol from transport (and mandatory for 3G).
WG has to define a couple of protocols, like MRCP/RTSP. What do you think of SPEECHSC/SIP, which can be very closed from MRCP/SIP.

Regards.

Jean-Philippe LONGERAY 
R&D Director - Service NODE

NetCentrex 

[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: Skip Cave [mailto:[email-masked]]
Sent: vendredi 13 décembre 2002 19:38
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Speechsc] SPEECHSC vs 3GPP

Jean, Eric,

I don't think SIP will support the separated media/control requirements I posted earlier. You will need a control protocol, and a separate media protocol. I expect that it will take a new protocol to meet these requirements.

Skip Cave
Sr. Principal Engineer
Intervoice Inc. 

>>> "Jean Philippe Longeray" <[email-masked]> 12/13/02 01:25AM >>>
Thanks Eric for this analyze,

I agree. H.248 doesn't seems to be the right answer for MRFC/MRFP, even if
special packages can be provided.

For my opinion, SIP is the correct answer for transport layer (since it's
used everywhere in 3GPP and 3GPP2), and SPEECHSC could (should?) be used for
resource control.

Concerning SPEECHSC, 3.3 "Avoid Duplicating Existing Protocols", I would
like to add some remarks:

In case of you would like to insert a routing mechanism (a SIP soft-switch)
between Media Processing Entity / Application server and Resource server
(ASR, SI/SV, TTS, Announcement server), I could be interesting to have a
single transport protocol, like SIP, instead of several incompatible
protocols (RTSP for example) for the closes functionalities. I think it is
easier to add some redundancy, rather than conserving "old" protocols like
RTSP.

It seems to be very important to make distinctions between each layers of
model.
Something like UDP/SIP/SPEECHSC or TCP/SIP/SPEECHSC or SCTP/SIP/SPEECHSC,
could be an answer.

Regards.

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: Eric Burger [mailto:[email-masked]]
Sent: vendredi 13 décembre 2002 03:13
To: Jean Philippe Longeray
Cc: IETF SPEECHSC (E-mail)
Subject: RE: [Speechsc] SPEECHSC vs 3GPP

The Mp interface is (1) not the right concept and (2) is itself (IMHO) not
the correct choice for 3GPP's needs, either.

With respect to (1), Mp is trying to be an analog to the MGC/MG
decomposition for a media server, where the MRFC is a "media server
controller" and the MRFP is a "media server [processor]".  The types of
resources are bearer packet processors (e.g., tone detection, prompt
playing, and recording).  The protocol is a low-level device control
protocol (e.g., allocate a resource, allocate a RTP port, connect the port
to the resource, wait for a signal, etc.).  speechsc is a higher-level
protocol, concerned with things like 'establish session' and 'recognize
speech'.

In fact, early in the days of MRCP/speechsc, people wanted to extend the
speechsc scope to do device control.  The answer has consistently been to
use H.248 for device control.

With respect to (2), AFAIK, no one has ever built a MRFC.  I believe this is
because unlike a media gateway, where there are definite decomposition
benefits, there are really few if any benefits to decomposing the MRF.  In
fact, there are clear benefits to using the native application interface
(SIP), rather than the native gateway interface (H.248) for interfacing the
AS and CSCF to the MRF.

-----Original Message-----
From: Jean Philippe Longeray [mailto:[email-masked]]
Sent: Tuesday, December 10, 2002 5:53 AM
To: IETF SPEECHSC (E-mail)
Subject: [Speechsc] SPEECHSC vs 3GPP

Hi,

Do you ever compare SPEECHSC and MRFC/MRFP interface in 3GPP (TS 24.229
Rel5) architecture.

It looks like  SPEECHSC  is very closed from Mp interface (H.248).

Could SPEECHSC works with 3GPP (www.3gpp.org) , 3GPP2 (www.3gpp2.org) ,
3G.IP (www.3gip.org),  MWIF (www.mwif.org)?

Regards.

Jean-Philippe LONGERAY
R&D Director - Service NODE

NetCentrex

[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

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc
_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc
_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "Jean Philippe Longeray" <[email-masked]>
Date: Tue, 17 Dec 2002 17:58:59 +0100

Thank you eric,

1) What do you think of:

             +-------------+
             | application |_________
             |   entity    |         \
             +-------------+        +-------------+
                    :               + Soft switch +
                    :               +-------------+
                                       \     speechsc   +-------------+
                    :                   \---------------| Speech      |+
                    : whatever                          | Processing  ||+
                    :                    ---------------| Resource(s) |||
                    :                   /     RTP       +-------------+||
                    :                  /                 +-------------+|
              +----------+            /                   +-------------+
              |   RTP    |           /
              |  entity  |-----------
              +----------+

In this case Soft switch can be used to select the right speech processing
resource.

2) As speech processing resources, you think :
- ASR
- TTS
- speaker verif.

Do you think we could be able to use also : streaming audio, video, fax
(T.38)

3) "Whatever" could be MGCP, or H.248

4) RTP entity could be :
- RTP Proxy
- RTP conference
- RTP duplicator
- RTP transcoder

Best regards.

Jean-Philippe LONGERAY

NetCentrex

-----Original Message-----
From: Eric Burger [mailto:[email-masked]]
Sent: mardi 17 décembre 2002 16:22
To: [email-masked]
Cc: Jean Philippe Longeray; Skip Cave
Subject: speechsc model [was RE: SPEECHSC vs 3GPP]

On the use of SIP for MRCP transport: draft-robinson-mrcp-sip-00 is what
drove me to realize that the MRCP tunneling approach was broken.  That is
not to say that it would be wrong to raise MRCP into SIP.  However, given
the existing semantics for RTSP and TTS, that may be a better way to go.  On
the other hand, the answer to your question is, "yes": the Robinson draft
shows SIP for signaling, not media.

             +-------------+
             | application |_________
             |   entity    |         \
             +-------------+          \

The speechsc perspective on the world has really only three logical
elements.  There is an application entity, which can be (for example ONLY)
an application server, a VoiceXML browser, a SALT browser, a Java Bean, a
handset, a media server, etc.  There is a RTP entity, which is a source of
RTP for the speech processing resource, which can be (for example ONLY) a
phone, a media gateway, a VoiceXML or SALT browser, etc.  Speech processing
resources are the ASR, TTS, and SI/SV engines.  Note the application entity
and RTP entity may be combined, decomposed, or have various bits decomposed
and combined.

Do we care about rearranging or embellishing these three basic components?
I don't think it will materially affect the protocol analysis.

-----Original Message-----
From: Jean Philippe Longeray [mailto:[email-masked]]
Sent: Tuesday, December 17, 2002 2:33 AM
To: Skip Cave; [email-masked]
Cc: Eric Burger
Subject: RE: [Speechsc] SPEECHSC vs 3GPP

Hi skip,

Like MRCP, SPEECHSC is a media command protocol. SIP is not only a streaming
protocol, It can be used as a transport protocol, like HTTP, X.224, ... If
SIP transports SDP, it becomes a streaming protocol, but what don't you
thing it's not possible to transport SPEECHSC messages in SIP Content.

In your document, something is missing: You need something to find an
Resource Server (ASR, SVI, TTS), and I propose to use SIP softswitching,
This softswitch could be inserted between your Application Execution Server
and all others voice resource (It could be ASR, TTS, SVI, but also
Audio/Video streaming, conferencing, ....)

I think that draft-robinson-mrcp-sip-00 is a great example that I want to
say. Do you agree Eric?

Best regards.

Jean-Philippe LONGERAY

NetCentrex

-----Original Message-----
From: Skip Cave [mailto:[email-masked]]
Sent: lundi 16 décembre 2002 20:47
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Speechsc] SPEECHSC vs 3GPP

Eric, Jean,

It's good that we agree. I believe that there has been some confusion in the
past that SpeechSC is a media streaming protocol. We need to list the basic
issues to make sure that we clear up that misconception:

1) SpeechSC is NOT a media streaming protocol.
2) The SpeechSC protocol is strictly a command/response protocol, carrying
commands and returning responses from application servers to speech servers.
The SpeechSC protocol will never be a media transport protocol, and will
never carry any type of media.
3) Even though the SpeechSC protocol is not a media transport protocol, the
SpeechSC protocol can be used to COMMAND speech servers to set up streaming
with another server using some type of streaming protocol (like SIP). Which
streaming protocol is used will be determined as part of the SpeechSC's
work.

For example, in my attached architecture diagram, the SpeechSC protocol
allows an Application Server commanding an ASR server to set up a SIP
session between the ASR server and a telephony platform (see attached
figure). Note that there is a SpeechSC command/control session between the
Application Server and the ASR Server, but there is no streaming media going
betweeen the Application & ASR Servers. There IS a standard SIP session
between the Speech server and the Telephony platform, that was set up by
commands given in the SpeechSC protocol. This SIP session does NOT carry any
commands other than standard SIP setup/teardown commands.

An example of the command/response sequence in a SpeechSC Command stream
would be:

Request from Application server to Directory Services for an ASR server
Reply from Directory Services To Application Server giving info on specific
ASR Server
Command from Application Server to ASR Server to set up a specific command/
response session for a call (one command session per call context)
Response from ASR Server to Application Server acknowledging the completion
of the session set-up.
Command from Application Server to selected ASR server to set up SIP session
with a specific Telephony Server. The App Server gives the ASR server the
addresses of the Telephony Server so the App Server can set up the SIP
session.
(ASR Server sets up SIP Session to Telephony Server))
Response from ASR Server indicating successful SIP session setup.
Command from Application Server to ASR Server to set up grammars and start
recognition on ASR Server.
Response from ASR Server to Application Server reporting a grammar match or
timeout from ASR Server.
etc.

Skip Cave
Sr. Principal Engineer
Intervoice Inc.

>From a personal perspective, the MRCP over SIP proposal was what pushed me
over the edge to fix MRCP.  I would be hard pressed to try to convince the
IESG that there is a need for MRCP/RTSP, MRCP/SIP, MRCP/foo, ...  We need to
pick the one that makes the most sense.

-----Original Message-----
From: Jean Philippe Longeray [mailto:[email-masked]]
Sent: Monday, December 16, 2002 3:12 AM
To: Skip Cave; Eric Burger
Cc: [email-masked]
Subject: RE: [Speechsc] SPEECHSC vs 3GPP

Hi Skip,

I agree. SIP  will never provide  multimedia control functionnalities, but
I'm sure it's a great protocol from transport (and mandatory for 3G).
WG has to define a couple of protocols, like MRCP/RTSP. What do you think of
SPEECHSC/SIP, which can be very closed from MRCP/SIP.

Regards.

Jean-Philippe LONGERAY

NetCentrex

-----Original Message-----
From: Skip Cave [mailto:[email-masked]]
Sent: vendredi 13 décembre 2002 19:38
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Speechsc] SPEECHSC vs 3GPP

Jean, Eric,

I don't think SIP will support the separated media/control requirements I
posted earlier. You will need a control protocol, and a separate media
protocol. I expect that it will take a new protocol to meet these
requirements.

Skip Cave
Sr. Principal Engineer
Intervoice Inc.

Regards.

Jean-Philippe LONGERAY

NetCentrex

-----Original Message-----
From: Jean Philippe Longeray [mailto:[email-masked]]
Sent: Tuesday, December 10, 2002 5:53 AM
To: IETF SPEECHSC (E-mail)
Subject: [Speechsc] SPEECHSC vs 3GPP

Hi,

Regards.

Jean-Philippe LONGERAY

NetCentrex