Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC

From: "Rajiv Dharmadhikari" <[email-masked]>
Date: Tue, 10 Jun 2003 18:26:33 -0700

Sorry to jump in late here as I wrote the SIP chapter in protocol evaluation draft for Speechsc. 
 
I agree with the approach of using SIP for Speechsc session establishment and having a separate channel for Speechsc messages. For all the benefits described below (server location, scalability etc.), SIP is perfect for establishing sessions for Speechsc. Most of the VoiceXML or SALT browsers will have SIP stack to manage media streams from/to media server and ASR/TTS servers. Therefore, I do not think SIP will make the Speechsc client implementaion anymore bulky. 
 
-Rajiv

-----Original Message-----
From: Sarvi Shanmugham [mailto:[email-masked]]
Sent: Tuesday, June 10, 2003 9:38 AM
To: [email-masked]
Cc: David R. Oran; Neil Deason; [email-masked]
Subject: Re: [Speechsc] Protpcol proposal for SPEECHSC

Here is my take on using SIP.
    1. It fits very well with what we are doing. Even better than RTSP as in MRCP which many people have called a kludgy/ugly etc. and I can see where they are coming from.
    2. A protocol such as SPEECHSC, needs a session level protocol that does the following.
          1. Locate a server or farm.
          2. Discover capabilities.
          3. Reach the server.
          4. Establish a session.
          5. Add/Remove media and speechsc control pipes. 
          6. Support Redirection/Transfer/Load balancing
          7. Support scalability(RTSP does seem to allow the sharing of a TCP/SCTP connection between the client and server between multiple RTSP/MRCP sessions).
          8. Potentially..... allow the setup of a control pipe between the ASR and TTS server for efficient barge-in support. This is a MAY BE. I don't want to turn this into a discussion of if this the right or wrong approach.
          Now all of the above requirements, would basically mean that session message additions directly to SPEECHSC would get us a session protocol very close to SIP. So why reinvent the wheel. 
          More over the conference control which controls yet another media resource for conferencing seems to be going along these lines. 

         Though I very much considered RTSP as well, I felt SIP would be a much better fit and would be a much more welcome choice with the rest of IETF.

Sarvi

Brian Wyld wrote:

Hi David,

I'll brutally resume your arguements as:

"SIP should be supplied natively by all OS's on which you might run

speechsc, and hence is not a burden for a speechsc implementation"

Whilest some might dispute this, I don't think this is a true statement

today; and tomorrow is another country as one might (mis)quote..... Making

this assumption and basing the operation and acceptance of speechsc on it

seems unneccessary to me.  Integrating a SIP stack is not a simple activity

(and generally more expensive if its free!).

Sorry, but I still think that it's easier to specify the media setup

specifically (maybe by cut-n-paste from RTSP) rather than suck in the entire

SIP protocol.

Maybe we should instead specify the use of RTSP as the media setup agent, as

most folks with MRCP experience will have such an implementation already and

it is known to serve the needs of mrcp......

A+

Brian

PS> I note that to achieve an operation MRCP server today, it is neccessary

to implement very little of RTSP and none of the media state machinary (no

play, record etc). In fact, only SETUP and TEARDOWN are really required, and

the 'tunnel message' ANNOUNCE......

[Brian Wyld] [ [email-masked]]

[Directeur General R&D]

[Eloquant SA] [+33 476 77 46 92] [ www.eloquant.com]

[advanced solutions for telecoms and IT services]

-----Message d'origine-----

De : David R. Oran [ mailto:[email-masked]]

Envoye : Tuesday, June 10, 2003 13:44

A :  [email-masked]; Neil Deason; 'Sarvi Shanmugham';

[email-masked]

Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC

--On Tuesday, June 10, 2003 9:42 AM +0200 Brian Wyld

 <mailto:[email-masked]> <[email-masked]> wrote:

Hi,

I quite like the idea of separating the media setup and

speechsc operation

completely as Sarvi has proposed. However, I think this

together with SIP

is going to give us big headaches when it comes to real implementations

and interoperability...

1/ SIP-in-speechsc : SIP is a protocol that has lot of stuff

that speechsc

does not need - does a speechsc client or server have to supply

a full SIP

complient stack, or just the bits that seem to be needed by speechsc? Do

we define a "speechsc profile" to avoid such a problem?

I suspect that once we deviate from 3261 compliance, we are

buying tons of

potential problems with interoperability and complex

specification. While I

have seen the profile approach taken in a number of fora, in the IETF tis

is generally considered to be inimical to the goal of interoperability

which is very high on the IETF's list of criteria for protocol

specification.

2/ SIP-commercial : SIP stacks might be generally available, but is it

really a requirement that a producer of a speechsc

client/server must both

create a speechsc stack and acquire a full SIP stack as well?

If we decide to go this path, then yes. However, 3261-compliant

SIP stacks

are quite easy to obtain and there are multiple open source versions

(vovida.org, iptel.org). As one of the "SIP bigots", my defense here is

that us crazy's really expect SIP to be ubiquitous - of the same

universal

deployment as DTTP, FTP, Telnet, SMTPm so depending on a SIP stack is a

perfectly natural and reasonable thing to do, especially if it simplifies

the rest of the problem space, which in this case it seems to do quite

nicely.

Although as

Neil says the environment around speechsc is likely to include SIP, a)

this cannot be enforced

well...we can enforce it if we so choose. It is unlikely that a service

enviroment which employs SPEECHSC would lack FTP, or HTTP, or DNS. This

proposal adds SIP to the list of things needed.

Also, it seems that the argument that SIP is an extra burden probably

applies to the server side, but not really to the client side. Nearly all

the envinroments we cite for SPEECHSC are ones in which speech

services are

being provided within the context of preparing for a session

establishment

of some sort, or during such sessions. I would have to construct some

artificial examples to justify a SPEECHSC client which did not

also employ

SIP.

For servers, your argument carries more weight, since a SPEECHSC

server may

be just a dedicated back-end box which does not itself initiate or

terminate other sessions. In analyzing the tradeoff, I still come down on

the SIP side of the equation because SPEECHSC servers are likely to be

general-purpose computers, running general-purpose OSs, with a rich

programming environment in which embedding SIP should be

somewhere between

easy and trivial.

and b) the SIP stack elements may be present in

the environment, but not neccessarily in the speechsc elements. In

particular, the speechsc server is unlikely to have a SIP stack in most

cases (IMHO bien sur - none of my MRCP servers have a SIP stack....)

True, but they wound up with nearly all of an RTSP stack, no?

3/ not-SIP : as Neil says, one could substitute ANOProtocol for

SIP and it

should work - however, as there is no mechanism to inform the client or

server of such a substitution this will ensure non-interoperability

between vendors..... (a Bad Thing)

This said, if we can avoid SIP causing either 'bloat' or an

interoperability nightmare, maybe by creating a 'speechsc profile' then

I'm not against it generally....

I suspect something which mandates less than 3261 compliance will

not have

an easy time getting through the IESG. On the other hand, I would have no

objection to the spec including guidance of the sort "note that a

speechsc

server has no need to ever initiate a SIP session and hence will be

responding to INVITES but not generating them".

Brian

[Brian Wyld] [ [email-masked]]

[Directeur General R&D]

[Eloquant SA] [+33 476 77 46 92] [ www.eloquant.com]

[advanced solutions for telecoms and IT services]

-----Message d'origine-----

De : Neil Deason [ mailto:[email-masked]]

Envoye : Friday, June 06, 2003 21:02

A :  [email-masked]; 'Sarvi Shanmugham';  [email-masked]

Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC

Hi.

There are benefits to using SIP with speechsc because the architectural

model for speechsc is complementary to the disaggregated application

component model which SIP promotes. Plus it avoids re-inventing the

wheel for initiation, modification and termination of speechsc

sessions.

Speechsc and SIP are synergistic and often likely to be deployed within

a common environment. Therefore having this form of defined working

relationship is a good thing.

I don't see anything new needed in SIP for speechsc sessions.

It is pure

reuse. RFC 3261 and RFC 3264 say what is and isn't allowed for SIP and

the offer/answer model for SDP. The only additions required

would be for

SDP. The IETF promotes a modular multi-protocol approach, so I

am afraid

the question of whether it means another stack is somewhat irrelevant.

The real question that needs to be asked is does SIP perform the job

required and the answer appears to be yes.

Now, all that said, I don't think you should have to use SIP to use

speechsc anymore than you have to use SIP to use RTP. If you want to

assume a model where a priori knowledge from some other

mechanism allows

a client and server to use speechsc between them that should be

supported. The draft could be made more explicit about that and keeping

the layers suitably delineated should be a design goal.

Cheers,

Neil.

-----Original Message-----

From:  [email-masked]

[ mailto:[email-masked]] On Behalf Of Brian Wyld

Sent: 03 June 2003 06:05

To: Sarvi Shanmugham;  [email-masked]

Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC

Hi Sarvi,

My initial feedback (before having read the doc in detail) is

that I was somewhat surprised to see the use of SIP messages

for the media setup. This did not corrospond to what I had

thought was the trend of the discussion here, to bypass

resuse of such a media protocol and create directly a new

speechsc protocol for this also. (which would probably use

SDP however).

The major issue I see with your use of SIP

INVITE/BYE/REINVITE etc is that adds a lot of _potential_

complexity (it pulls in an entire SIP stack), for very little

gain in real functionality. I really don't see the use in

having all the potential SIP stuff and then having to define

exactly what is and isn't allowed.....

I'd go for a simpler model where we just define new speechsc

messages to setup/control the media that are specific to

speechsc.....

Brian

[Brian Wyld] [ [email-masked]]

[Directeur General R&D]

[Eloquant SA] [+33 476 77 46 92] [ www.eloquant.com]

[advanced solutions for telecoms and IT services]

-----Message d'origine-----

De :  [email-masked] [ mailto:[email-masked]]De la

part de Sarvi Shanmugham Envoye : Wednesday, May 21, 2003 23:30

A :  [email-masked]

Objet : [Speechsc] Protpcol proposal for SPEECHSC

Hi

     Please find attached a proposal for a SPEECHSC protocol. This

leverages the MRCP specification. But removes the

tunnelling aspects

of the protocol. I have also submitted this document to the

internet

drafts repository and should be available from there soon.

The current version does not address SI and SV aspects of the

requirements document. But addresses most of the others.

This document

is meant to be a starting point for a possible direction that the

SPEECHSC protocol could take. Based on interest and

comments received,

we can proceed to add SI and SV capabilities in a following

version of

the draft.

Any thoughts.

Sarvi

_______________________________________________

Speechsc mailing list

[email-masked]  https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________

Speechsc mailing list

[email-masked]

https://www1.ietf.org/mailman/listinfo/speechsc

------------------------

David R. Oran

Cisco Systems

7 Ladyslipper Lane

Acton, MA 01720

Office: +1 978 264 2048

VoIP: +1 408 571 4576

Email:  [email-masked]