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

From: "BRANDT,MARC (HP-France,ex2)" <[email-masked]>
Date: Tue, 17 Dec 2002 18:31:22 +0100

could you clarify the definition of softswitch in this architecture
and the possible interface between App entity and the sosw ?

> -----Original Message-----
> From: Jean Philippe Longeray
> [mailto:[email-masked]]
> Sent: Tuesday, December 17, 2002 5:59 PM
> To: Eric Burger; [email-masked]
> Cc: Skip Cave
> Subject: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP]
> 
> 
> 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
> 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: 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.
> 
> 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
_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

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

I think that it is very similar to establish a session between a SPR (Speech
Processing resource) and an AE (Application equipment) than to establish a
connection between two others components (like a SIP GW and an AE).
You always need to route messages between 2 entities. DNS is not a good
answer, softswitch could be.

Example

INVITE [email-masked] SIP 2.0
From : <[email-masked]>
To : <[email-masked]>

...

Can be routed by any soft switch, to find ASR resource... so interface
between AE/SOSW is SIP and between SOSW/SP is SIP also.

By experience, I know that sharing Resources between many AE is a great
challenge!

Regards.

Jean-Philippe LONGERAY

NetCentrex

-----Original Message-----
From: BRANDT,MARC (HP-France,ex2) [mailto:[email-masked]]
Sent: mardi 17 décembre 2002 18:31
To: Jean Philippe Longeray; Eric Burger; [email-masked]
Cc: Skip Cave
Subject: RE: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP]

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

(www.3gpp2.org) ,

Regards.

Jean-Philippe LONGERAY

NetCentrex