Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC

From: "Neil Deason" <[email-masked]>
Date: Wed, 28 May 2003 13:55:57 -0700

Hi.

I have some comments on the usage of SDP for SPEECHSC part of the draft.

+ I would suggest an alternative format for the 'm=' line. Use a value
for the protocol that designates the underlying transport protocol, this
then allows for TCP, TLS, SCTP to be used with speechsc. For the media
format use the mime type 'application/speechsc'. Then use two SDP
attributes to describe the resource ID and channel ID. An example
written this way would therefore be:

		m=control 32416 TCP application/speechsc
		a=resourceId:speechrec
		a=channelId:32AECB234338 

+ Section 3.2 refers to setting the offerer setting the port to 0 in the
SDP when it wants to act as the client in the connection setup
procedure. However, setting a port to 0 has a defined meaning that a
stream is offered but must not be used according to RFC3264. This an
area where alignment with draft-ietf-mmusic-sdp-comedia-05.txt could
help. That recommends the offerer use a value of port 9 (the discard
port) in its offer. This work also then defines a SDP attribute to
define the client/server roles to be used in the connection set up
procedure, which could be reused here.

+ Section 3.2 refers to a client removing a 'm=' line from the SDP
description in a session to de-allocate a resource. RFC3264 describes
the mode for removing a media stream as continuing to offer it, but with
the port set to 0.

+ The SDP in Example 1 of the draft would not be legal according to RFC
2327 - the SDP in the INVITE is missing a mandatory 'm=' line. This may
not be a big deal as it was not clear to me why you would have this
preliminary offer/answer prior to establishing the resource control
channel. If there is no clear reason the exchange described in Example 1
would be unnecessary and can be removed.

+ Finally a few nits have crept in: The SIP URL used in the contact
header of the examples has an illegal whitespace in it, the SIP messages
are missing Via headers.

I have revised the examples in the draft accordingly below. They could
still use some cleaning up, but hopefully it helps illustrate the above
comments.

(Example 1 deleted - so pervious Example 2 becomes 1 etc.)

Example 1.
   C->S: 
           INVITE sip:[email-masked] SIP/2.0 
           Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9 
           Max-Forwards: 70 
           To: MediaServer <sip:[email-masked]> 
           From: sarvi <sip:[email-masked]>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314161 INVITE 
           Contact: <sip:[email-masked]> 
           Content-Type: application/sdp 
           Content-Length: ...
            
           v=0 
           o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4 
           s=- 
           c=IN IP4 224.2.17.12
           m=control 9 TCP application/speechsc
	     a=direction:active 
           a=resourceId:speechsynth
           m=audio 49170 RTP/AVP 0 96 
           a=rtpmap:0 pcmu/8000 
           a=recvonly 
     
    S->C: 
           SIP/2.0 200 OK 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           To: MediaServer <sip:[email-masked]> 
           From: sarvi <sip:[email-masked]>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314161 INVITE 
           Contact: <sip:[email-masked]> 
           Content-Type: application/sdp 
           Content-Length: ... 
            
           v=0 
           o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4 
           s=- 
           c=IN IP4 224.2.17.12
           m=control 32416 TCP application/speechsc
	     a=direction:passive
	     a=resourceId:speechsynth
	     a=channelId:32AECB234338 
           m=audio 48260 RTP/AVP 00 96 
           a=rtpmap:0 pcmu/8000 
           a=sendonly 
     
    C->S: 
           ACK sip:[email-masked] SIP/2.0 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           Max-Forwards: 70 
           To: MediaServer <sip:[email-masked]>;tag=a6c85cf 
           From: Sarvi <sip:[email-masked]>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314162 ACK 
           Content-Length: 0 

Example 2.
   C->S: 
           INVITE sip:[email-masked] SIP/2.0 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           Max-Forwards: 70 
           To: MediaServer <sip:[email-masked]> 
           From: sarvi <sip:[email-masked]>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314163 INVITE 
           Contact: <sip:[email-masked]> 
           Content-Type: application/sdp 
           Content-Length: ... 
            
           v=0 
           o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 
           s=-
           c=IN IP4 224.2.17.12
           m=control 9 TCP application/speechsc
	     a=direction:active 
	     a=resourceId:speechrec
           m=control 9 TCP application/speechsc
	     a=direction:active 
	     a=resourceId:speechsynth
           m=audio 49170 RTP/AVP 0 96 
           a=rtpmap:0 pcmu/8000 
           a=rtpmap:96 telephone-event/8000 
           a=fmtp:96 0-15 
           a=sendrecv 
     
    S->C: 
           SIP/2.0 200 OK 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           To: MediaServer <sip:[email-masked]> 
           From: sarvi <sip:[email-masked]>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314163 INVITE 
           Contact: <sip:[email-masked]> 
           Content-Type: application/sdp 
           Content-Length: 131 
            
           v=0 
           o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 
           s=-
           c=IN IP4 224.2.17.12
           m=control 32416 TCP application/speechsc
	     a=direction:passive
	     a=resourceId:speechrec
	     a=channelId:32AECB234338
           m=control 32416 TCP application/speechsc
	     a=channelId:32AECB234339
	     a=resourceId:speechsynth
	     a=direction:passive
           m=audio 48260 RTP/AVP 0 96 
           a=rtpmap:0 pcmu/8000 
           a=rtpmap:96 telephone-event/8000 
           a=fmtp:96 0-15 
           a=sendrecv 
     
    C->S: 
           ACK sip:[email-masked] SIP/2.0 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           Max-Forwards: 70 
           To: MediaServer <sip:[email-masked]>;tag=a6c85cf 
           From: Sarvi <sip:[email-masked]>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314164 ACK 
           Content-Length: 0 

Example 3.
    C->S: 
           INVITE sip:[email-masked] SIP/2.0 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           Max-Forwards: 70 
           To: MediaServer <sip:[email-masked]> 
           From: sarvi <sip:[email-masked]>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314163 INVITE 
           Contact: <sip:[email-masked]> 
           Content-Type: application/sdp 
           Content-Length: ...
            
           v=0 
           o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 
           s=-
           c=IN IP4 224.2.17.12
           m=control 0 TCP application/speechsc
	     a=direction:active
	     a=resourceId:speechrec
           m=control 9 TCP application/speechsc
	     a=direction:active
	     a=resourceId:speechsynth	
           m=audio 49170 RTP/AVP 0 96 
           a=rtpmap:0 pcmu/8000 
           a=recvonly 
     
    S->C: 
           SIP/2.0 200 OK 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           To: MediaServer <sip:[email-masked]> 
           From: sarvi <sip:[email-masked]>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314163 INVITE 
           Contact: <sip:[email-masked]> 
           Content-Type: application/sdp 
           Content-Length: 131 
            
           v=0 
           o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 
           s=-
           c=IN IP4 224.2.17.12
           m=control 0 TCP application/speechsc
	     a=direction:passive
	     a=resourceId:speechrec
	     a=channelId:32AECB234338
           m=control 32416 TCP application/speechsc
	     a=resourceId:speechsynth
	     a=channelId:32AECB234339
	     a=direction:passive
           m=audio 48260 RTP/AVP 0 96 
           a=rtpmap:0 pcmu/8000 
           a=sendonly 
     
    C->S: 
           ACK sip:[email-masked] SIP/2.0 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           Max-Forwards: 70 
           To: MediaServer <sip:[email-masked]>;tag=a6c85cf 
           From: Sarvi <sip:[email-masked]>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314164 ACK 
           Content-Length: 0 

Finally one thing I think the WG needs to be aware of is the proposed
new charter of the mmusic WG. A clear motivation there appears to be to
draw a line under what gets added to SDP as it is today and what would
be waiting for SDP NG. I think a too draconian interpretation of that
proposed charter might present a problem here. (As well as in the SIMPLE
WG).

hth,
Neil.
--
http://users.rcn.com/neildeason/

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Sarvi Shanmugham
> Sent: 21 May 2003 14:30
> To: [email-masked]
> Subject: [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: Sarvi Shanmugham <[email-masked]>
Date: Thu, 29 May 2003 13:19:09 -0700

some comments line.

>		m=control 32416 TCP application/speechsc
1.  I am fine with using TCP/SCTP/TLS as the transport field of the 
m-line and specifiying the channel-id/resource-id as an attribute of the 
m-line. That said, could you explain what we gain between using a 
transport of SPEECHSC(whisch specifies what transports are supported)  
and your suggestion of specifying TCP or SCTP in the transport field of 
the m-line. My current approach seems similar to examples used where the 
transport is claimed to be "h323".

2. Channel -id / resource format
Do you see problem with the channel id covering the resource identity 
and the channel identity?
I had done it this way, so that we have the option of requesting 
resource-id "00" to mean, on demand allocation. This returns a 
channel-id of  "32AECB23433800" where 00 means on-demand resource usage. 
There is no specific resourece that is being reserved or allocated.

This then allows an ASR or TTS or SI or SV command to be issued. The 
just need to have a channel-id of "32AECB234338XX" where XX is the 
resource identifier.

It also has the added benefit of figuring out from the chhanel -id what 
type of resource is being controlled.

>procedure, which could be reused here.
Agreed. I will make the appropriate changes in the next revision.

>the mode for removing a media stream as continuing to offer it, but with
Agreed. I will make the appropriate changes in the next revision.

>would be unnecessary and can be removed.
I was just trying to demonstrate that there could be times in the SIP 
session when there is no m-lines becuase there is no resources used or 
media between the client and the server. This may most likely happen mid 
session than at the beginning. the SIP session may add m-line for the 
different resources as need and m-lines for audio as needed by the 
resource. The client could allocate and deallocate resources(m-lines) as 
needed within in the session. This might mean that there are times, 
 when the client has released the all the individual resources but may 
want to allocate it as part of the session at a later point. At these 
points I don't want to have to destroy the whole SIP session and 
recreate it.
Anyway, atleast thats what I was trying to do. If this is illegal in 
SIP, I will remove it or find an alternative for this.

>header of the examples has an illegal whitespace in it, the SIP messages
I will incorporate these into the next revision.

Thx,
Sarvi