Subject: RE: [MMUSIC] Server overriding Transport parameters

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

one more thing.
Let's think of following example,

C -> S: SETUP rtsp://foo.com/bar.file RTSP/1.0
CSeq: 2
Transport: RTP/AVP/TCP;unicast

In this case, there is no interleaved keyword. If strictly checking the
above request,
server will just response with 461 error message. However, in the real
world,
many servers response like following:

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

This means in some cases, server could be smart.
What do you think of this case?

Regards,
Jaehwan, Kim

-----Original Message-----
From: 김재환(Jaehwan Kim) 
Sent: Thursday, May 16, 2002 10:47 AM
To: Tom Marshall; [email-masked]
Cc: [email-masked]
Subject: RE: [MMUSIC] Server overriding Transport parameters

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

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

---

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

> What do you think of this case?

I think if you want this behavior the client should send

Transport: RTP/AVP/TCP;unicast;interleaved

lest we cause ourselves trouble should we ever want to support RTP over
separate TCP connections.

But I think it's better for the client to pick the channel numbers the
server will transmit to, just like it picks the UDP port numbers the
server will transmit to.

--jss.