Subject: Re: [MMUSIC] How to indicate the RTSP client to use TCPtransportinstead of UDP?

From: Magnus Westerlund <[email-masked]>
Date: Mon, 20 Nov 2006 14:24:12 +0100

Jaehwan Kim skrev:
> Folks,
> 
>  
> 
> Because I have some actual experience, I would like to share it with you. But correct me if I am wrong:
> 
> 1.       RTP/AVP/TCP;unicast;interleaved=0-1 is the right form. 
> 
> 2.       RFC 2326 has RTP/AVP/TCP;interleaved=0-1. It was fixed in 2326bis to have unicast. Multicast is default in this header field.
> 
> 3.       Old Realplayer has RTP/AVP/TCP only. This is wrong because there is no unicast
> 
> 4.       Current Realplayer has RTP/AVP/TCP;unicast. It looks ok because anyway interleaved is optional.
> 
> 5.       Therefore, some might think that RTP/AVP/TCP is the same as RTP/AVP/TCP;interleaved
> 
> 6.       However, it is basically not true. I got an agreement from ISMA in 2003 that we need to think of future extension than ‘interleaved’. Moreover, now it looks that some draft using just RTP/AVP/TCP(similar to as Fan’s independent TCP) is working on in somewhere else in MMUSIC. Here ‘interleaved’ only means an embedded RTP over RTSP solution as described in RFC 2326 section 10.12
> 
> 7.       When there is only RTP/AVP in client, server can’t change it to RTP/AVP/TCP, according to standard and we agreed it here in MMUSIC long ago; it can only choose one of the list.
> 
> 8.       From my knowledge and testing, the current PC version Realplayer can support interleaved. But some Symbian versions can’t handle it. Anyway if there is no RTP/AVP/TCP from client Request, server can not use it.
> 
> 9.       Because a player like Realplayer regards RTP/AVP/TCP as RTP/AVP/TCP;interleaved, my server responds with RTP/AVP/TCP;unicast;interleaved=0-1 when it got RTP/AVP/TCP;unicast or just RTP/AVP/TCP. And I found that Helix Server also responds like this.
> 
> 10.   Therefore, now we can assume that RTP/AVP/TCP might be the same as RTP/AVP/TCP;unicast;interleaved=0-1
> 
> 11.   We need a new parameter when a new method is defined as independent TCP.  Because the characteristic of UDP is different from TCP, we can not simply convey RTP AS IS over TCP, thereby some other profile or a way of transport method should be defined. For instance, RTP/AVP/TCP;unicast;foo-TCP  can be used. Then the assumption of 10 would be possible.
> 
Hi,

I am catching up on old RTSP related emails and to checks if any of the
discussion should be reflected into the next draft version of RTSP 2.0.

In my view of this discussion of this topic there are some confusion
related to the version. First of all independent TCP is not defined in
IETF at all for RTSP 1.0. For 2.0 it is specified in the last versions
of the draft.

I also don't see a need to add any text in RTSP 2.0 for handling
independent TCP streams. This as the current draft specifies clearly
that unless "interleaved=x-y" is included then independent TCP is meant.

If you think some changes to rfc2326bis is needed please tell me what.

cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 20 Nov 2006 14:33:49 +0100

Jaehwan Kim skrev:
>>> Jaehwan Kim wrote:
>>> 11.   We need a new parameter when a new method is defined as 
>>> independent TCP.  Because the characteristic of UDP is different 
>>> from TCP, we can not simply convey RTP AS IS over TCP, 
>>> thereby some other profile or a way of transport method should 
>>> be defined. (snip)
> 
>> From: Kylin Wei [mailto:[email-masked]]
>> I think this problem had been resolved in rfc2326bits.(snip)
>> Please refer to section B.2.2 of rfc2326bits. (snip)
> 
> I see. The next 2326bis, version 14, would have RFC4571 more clearly. It
> looks that SDP, example, syntax of Transport should be properly
> refurnished, though.
> 

Yes, we have added an issue in the tracker for this.

Cheers

Magnus Westerlund