Subject: RE: [MMUSIC] Server overriding Transport parameters

From: "???(Jaehwan Kim)" <[email-masked]>
Date: Fri, 17 May 2002 17:45:59 +0900

Hello Rob,

As I submitted to RTSP bug tracking system...
	In 'transport' header field, multicast keyword is default.

	In the example of '10.12 Embedded (Interleaved) Binary 
	Data' in RFC2326, even though this transport type is 
	TCP, there is no unicast keyword.

	Generally multicast can not be used in TCP.

	Therefore, the example of '10.12 Embedded 
	(Interleaved) Binary Data' in RFC2326 must be changed.

	or 

	The default cast method should be changed as unicast.

This is my thought. But the originator thinks...

	 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.

Can I look upon this thought as 'In TCP, unicast is implicitly default'.
Then, can you make it 'explicit'?

I am not sure what is 'default' in the  RTP over RTSP interleaved TCP
  1) In transport syntax, default is 'multicast'. (without any
exception)
  2) Our knowledge based default is 'unicast'.

Basically, I can aggree with your thought, but several times, 
I suffered from this unclear situation. We can support
default unicast in TCP, but I am not assure that other vendors follow 
this implicit idea because of a lack of syntax.
It will be hard to specify a meaningful default in general.

If the originator's idea can be written in RFC explicitly(in syntax),
the example in the specification would be perfect right.

Regards,
--Jaehwan

On Fri, 17 May 2002, Rob Lanphier wrote:
>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.

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