Subject: RE: [MMUSIC] Server overriding Transport parameters

From: "???(Jaehwan Kim)" <[email-masked]>
Date: Thu, 16 May 2002 21:21:04 +0900

Actually, I believed it like you before, 
  " 'unicast/multicast' should be changed to be transport dependent. "

However, I found a server responsed incorrectly.
e.g. RTP/AVP/TCP;multicast;interleaved=0-1 when I sent RTP/AVP/TCP only.
Because RFC2326 says 'multicast is default'. So I was confused.
The server could fill the missing 'interleaved' keyword. (see my another
mail,
"one more thing...") However it did not fix 'multicast' dependent on
TCP. 
The server seemed to be halfway smart. 

If the interleaved example in RFC2326 is correct, a set of parameters 
could be arbitrarily chosen by the server. But The fact that multicast
does 
not become TCP per se does not mean that a server can determine it
without
an exact notice in the specification. ( I reported this bug on the
tracking system)

IMO, our spec. should be strict and our client should be more specific 
as well. This makes our life easier.

Regards,
--Jaehwan

-----Original Message-----
From: Rob Lanphier [mailto:[email-masked]]
Sent: Thursday, May 16, 2002 12:17 PM
To: ±èÀçÈ¯(Jaehwan Kim)
Cc: Tom Marshall; [email-masked];
[email-masked]
Subject: RE: [MMUSIC] Server overriding Transport parameters

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

On Thu, 16 May 2002, [ks_c_5601-1987] ±èÀçÈ¯(Jaehwan Kim) wrote:

> 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: Rob Lanphier <[email-masked]>
Date: Thu, 16 May 2002 11:01:49 -0700 (Pacific Daylight Time)

On Thu, 16 May 2002, ???(Jaehwan Kim) wrote:
> However, I found a server responsed incorrectly. e.g.
> RTP/AVP/TCP;multicast;interleaved=0-1 when I sent RTP/AVP/TCP only.
> Because RFC2326 says 'multicast is default'. So I was confused. The
> server could fill the missing 'interleaved' keyword. (see my another
> mail, "one more thing...") However it did not fix 'multicast' dependent
> on TCP.  The server seemed to be halfway smart.
>
> does not become TCP per se does not mean that a server can determine it
> without an exact notice in the specification. ( I reported this bug on
> the tracking system)
>

Could you propose a specific change in wording that would achieve the goal
you set out?  We may be in agreement here, but I'm not sure based on this
description.

Thanks
Rob