Subject: RE: [MMUSIC] Server overriding Transport parameters

From: 김재환(Jaehwan Kim) <[email-masked]>
Date: Thu, 16 May 2002 10:47:18 +0900

I believe the former, too.
Addition to this, the server response should be changed even if server
is omnipotent.

> S -> C: RTSP/1.0 200 OK
> CSeq: 2
> Date: 05 Jun 1997 18:57:18 GMT
> Transport: RTP/AVP/TCP;interleaved=0-1
==>
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

Rationale : default cast method is multicast in RFC2326.
Therefore, above response may cause another problem.

Moreover, the interleaved example in RFC2326 should be corrected.

Regards,
-Jaehwan

-----Original Message-----
From: Tom Marshall [mailto:[email-masked]]
Sent: Thursday, May 16, 2002 1:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [MMUSIC] Server overriding Transport parameters

On Wed, May 15, 2002 at 01:26:01PM +0200,
[email-masked] wrote:
> Hi,
> 
> When doing SETUPs, RFC 2326 states that "The Transport header
specifies the
> transport parameters acceptable to the client for data transmission;
the
> response will contain the transport parameters selected by the server.
"
> 
> Does "selected by the server" refers to one parameter set selected
from the
> client's submitted sets, or does it refers to a set of parameters
> arbitrarily chosen by the server (e.g. based on its
configured/authorized
> transport capabilities) ??

I believe the former.

> e.g. if one configured a server that only handles interleaved
transport,
> would the following dialog be correct:
> 
> C -> S: SETUP rtsp://foo.com/bar.file RTSP/1.0
> CSeq: 2
> Transport: RTP/AVP/UDP;unicast;client_port=4556-4557,
> RTP/AVP/TCP;multicast;client_port=4556-4557;source=224.25.136.178
> 
> S -> C: RTSP/1.0 200 OK
> CSeq: 2
> Date: 05 Jun 1997 18:57:18 GMT
> Transport: RTP/AVP/TCP;interleaved=0-1
> 
> or should the server respond with an error code & indicate that it
cannot
> SETUP with the proposed parameters ??

The client did not give the server a choice of interleaved so it should
return a 461 error.

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

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

---

From: Rob Lanphier <[email-masked]>
Date: Wed, 15 May 2002 20:17:18 -0700 (Pacific Daylight Time)

There's some subtleties to take into account here.

The intention is that the client sends a list of transport specifications,
and the server responds by selecting one, and filling in any missing
parameters.

For example, there's no way for the client to specify what the server
UDP ports should be.

The example in the specification is probably correct.  The default
"unicast/multicast" should be changed to be transport dependent.
"RTP/AVP/TCP;multicast" is a non-sequitor.

Rob

---

From: Jonathan Sergent <[email-masked]>
Date: Wed, 15 May 2002 20:23:00 -0700

> "RTP/AVP/TCP;multicast" is a non-sequitor.

It will be hard to specify a meaningful default in general since RTSP
does not specify the full list of allowed transports.  I think it would
be better to lose the default and just require it to be specified; this
is simpler IMO.

Sorry for missing the RTSP teleconference this morning... oops.