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

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

The concept is OK.  The terminology is a non-starter.  Most people assume a softswitch is a media gateway controller.  See <http://www.softswitch.org/>.

However, I again ask, does having an application switch (to use Internet terminology) have any bearing on speechsc?  It shouldn't.  The whole point of using IP is that transport and distribution is transparent to our application-layer [sic; I know we're tsv] protocol.

> -----Original Message-----
> From: Jean Philippe Longeray
> [mailto:[email-masked]]
> Sent: Tuesday, December 17, 2002 12:39 PM
> To: BRANDT,MARC (HP-France,ex2); Eric Burger; [email-masked]
> Cc: Skip Cave
> Subject: RE: [Speechsc] RE: speechsc model [was RE: SPEECHSC vs 3GPP]
> 
> 
> 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
> 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: 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]
> 
> 
> 
> 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: "BRANDT,MARC (HP-France,ex2)" <[email-masked]>
Date: Tue, 17 Dec 2002 22:27:48 +0100

I tend to agree that routing the speechsc control messages among several
resources is an important need, and that sharing resources among
applications certainly leaves room to some valuable solutions.
This is the key problems that product implementers need to deliver.
But also as expressed in the speechsc
requirements this may certainly rely on existing protocol properties
(service discovery, location servers, dns....), which for instance
SIP clearly takes advantage of, like in your example (a class of ASR
in the URI and so on).

I also tend to agree that the presence, or not, of intermediate
nodes in the architecture is more an implementation choice
and that speechsc shall not prevent nor enforce such a needs.
As long as they do not bring a clear functional needs to the architecture,
I mean not simply (although not so simple ;-) for handling scalability
or other properties of the solution.
This can typically be of value to some product solutions, like the load
balancers, the cache servers were for the web and so on...
What was put in the requirements is that speechsc may define extra 
mechanisms for load balancing but this may not impose a new box 
for every possible implementation, but only extra facility so that
the underlying framework can do the routing more efficiently.

> Sent: Tuesday, December 17, 2002 7:00 PM
> Cc: BRANDT,MARC (HP-France,ex2); [email-masked]
> The concept is OK.  The terminology is a non-starter.  Most 
> people assume a softswitch is a media gateway controller.  
> See <http://www.softswitch.org/>.
> 
> However, I again ask, does having an application switch (to 
> use Internet terminology) have any bearing on speechsc?  It 
> shouldn't.  The whole point of using IP is that transport and 
> distribution is transparent to our application-layer [sic; I 
> know we're tsv] protocol.
>