Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC

From: "Brian Wyld" <[email-masked]>
Date: Tue, 3 Jun 2003 15:05:17 +0200

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

---

From: "Neil Deason" <[email-masked]>
Date: Fri, 6 Jun 2003 12:01:54 -0700

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 
> 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
> 
> > De : [email-masked] [mailto:[email-masked]]De la
> > part de Sarvi Shanmugham Envoye : Wednesday, May 21, 2003 23:30
> > A : [email-masked]
> > 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.
> >
> [email-masked] https://www1.ietf.org/mailman/listinfo/speechsc
>

---

From: "Brian Wyld" <[email-masked]>
Date: Tue, 10 Jun 2003 09:42:47 +0200

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?

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? Although as
Neil says the environment around speechsc is likely to include SIP, a) this
cannot be enforced 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....)

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

Brian

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

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 10 Jun 2003 07:44:13 -0400

--On Tuesday, June 10, 2003 9:42 AM +0200 Brian Wyld 
<[email-masked]> wrote:

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

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

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

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

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: "Brian Wyld" <[email-masked]>
Date: Tue, 10 Jun 2003 18:16:24 +0200

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

> De : David R. Oran [mailto:[email-masked]]
> Envoye : Tuesday, June 10, 2003 13:44
> A : [email-masked]; Neil Deason; 'Sarvi Shanmugham';
> [email-masked]

---

From: David Oran <[email-masked]>
Date: Tue, 10 Jun 2003 12:36:42 -0400

> speechsc, and hence is not a burden for a speechsc implementation"
Well, I think that is in fact a fair summary on the server side, but my 
argument was a bit different on the client side (you'd need SIP anyway for 
other things the client was doing and integration would be arguably easier 
than for another protocol).

> Whilst some might dispute this, I don't think this is a true statement
> seems unneccessary to me.  Integrating a SIP stack is not a simple
> activity (and generally more expensive if its free!).
>
I won't dispute this either. We are just coming down on different sides of 
a discussion about engineering tradeoffs and what best tracks the direction 
of the technology and industry adoption.

> specifically (maybe by cut-n-paste from RTSP) rather than suck in the
> entire SIP protocol.
>
Minor terminology quibble. I think it's hard to dispute that from a 
*specification* point of view it's easier to say "use SIP; describe 
SPEECHSC servers in SDP thusly", than it is to respecify the entire 
rendezvous and session management state machine of even such a simple 
protocol as RTSP. Implementation is another matter of course, and that's 
where the rubber meets the sky...

> 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......
>
I personally think this is an acceptable alternative, and would be 
perfectly happy to adopt this if we can get WG consensus on such a 
proposal. However... we do have a concrete proposal on the table which uses 
SIP. As someone already noted, it's up to you to offer a concrete (i.e. 
written Internet draft) counter proposal.

> A+
Cheers, Dave.

> 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......
>
>> > complient stack, or just the bits that seem to be needed by speechsc?
>> > Do we define a "speechsc profile" to avoid such a problem?
>> >
>> >> 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.
>> >>
>> >> supported. The draft could be made more explicit about that and
>> >> keeping the layers suitably delineated should be a design goal.
>> >>
>> >> Cheers,
>> >> Neil.
>> >>

---

From: Sarvi Shanmugham <[email-masked]>
Date: Tue, 10 Jun 2003 09:38:21 -0700

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:

>>>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
>>    
>>
>>>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
>>    
>>
>>>really a requirement that a producer of a speechsc
>>>      
>>>
>>client/server must both
>>    
>>
>>>3/ not-SIP : as Neil says, one could substitute ANOProtocol for
>>>      
>>>
>>SIP and it
>>    
>>
>>>>wheel for initiation, modification and termination of speechsc
>>>>        
>>>>
>>sessions.
>>    
>>
>>>>I don't see anything new needed in SIP for speechsc sessions.
>>>>        
>>>>
>>It is pure
>>    
>>
>>>>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
>>    
>>
>>>>assume a model where a priori knowledge from some other
>>>>        
>>>>
>>mechanism allows
>>    
>>
>>>>>messages to setup/control the media that are specific to
>>>>>          
>>>>>
>>speechsc.....
>>    
>>
>>>>>Brian
>>>>>
>>>>>>requirements document. But addresses most of the others.
>>>>>>            
>>>>>>
>>>>>This document
>>>>>          
>>>>>
>>>>>>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
>>>>>>
>>>>>>            
>>>>>>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Jun 2003 08:54:27 +0200

Hi Brian,

I would like to give some comments on why RTSP may not be the best 
choice even if you are only using the SETUP part.

- RTSP uses a lot of RTTs. RTSP requires at least two RTT, if more than 
one media stream needs to be established.

- There exist no specification for secured transport of RTSP yet.

- The NAT traversal in RTSP is not as mature and with less work going on 
than for SIP.

- Currently no stable and good specification exist. RFC 2326 is not that 
much to have.

Best Regards

Magnus Westerlund

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]