Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC

From: "Neil Deason" <[email-masked]>
Date: Tue, 3 Jun 2003 13:06:50 -0700

Hi Sarvi.

-----Original Message-----
From: Sarvi Shanmugham [mailto:[email-masked]] 
Sent: 29 May 2003 13:19
To: Neil Deason
Cc: [email-masked]
Subject: Re: [Speechsc] Protpcol proposal for SPEECHSC

some comments line.

Neil Deason wrote:

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 

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". 
 
It allows the offerer to seek an explicit transport from the answerer,
e.g. TLS if security was important. If I understand it this SPEECHSC
proposal just says that TCP MUCT be supported and SCTP MAY be for the
actual session. Therefore which is actually used needs to be explicitly
described in the SDP.

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. 
 
I dont think there is a problem with this. I just split these out as SDP
attributes are essentially free so there is no cost in having 2 over 1.
Being less terse than hex for the resource ID also seemed to fit with
the rest of the proposal. However, it probably comes down to no more
than issue of taste.
 
Cheers,
Neil.  

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

Agreed. I will make the appropriate changes in the next revision.

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

Agreed. I will make the appropriate changes in the next revision.

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

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.

+ 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 will incorporate these into the next revision.

Thx,
Sarvi

---

From: Tom Taylor <[email-masked]>
Date: Tue, 03 Jun 2003 16:29:30 -0400

Actually, SDP specifies zero or more media descriptions in a session description, 
meaning that the example shown is legal.

> Hi Sarvi.
[snip]
>     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.
[snip]

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

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

Hi Tom.

You are correct. Re-reading RFC2327 shows that the 'm=' line is only
manadatory if there are any media level description lines used. So
provided you only use session level descriptors zero 'm=' lines would be
OK.

Thanks,
Neil.

> From: Tom Taylor [mailto:[email-masked]]
> Sent: 03 June 2003 13:30
> To: Neil Deason
> Cc: 'Sarvi Shanmugham'; [email-masked]
> >>+ 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.
> >