Subject: [MMUSIC] RTSP 2.0: Use of independent TCP

From: Magnus Westerlund <[email-masked]>
Date: Tue, 05 Dec 2006 10:15:48 +0100

In working on an updated draft the following issues has been found.

First, I want to ensure that everyone is fine with having the server 
being able to take both an active and a passive role in the TCP 
connection establishment. That way the client can select. However it is 
recommended that the client takes the active role.

Secondly: I below propose new stricter text for how the client and 
server should behave after a successful SETUP negotiation for 
independent TCP. This is to avoid the issue of what the server would do 
if the TCP connections wasn't established when receiving the play  request:

Section B.2.2
After sending (receiving) a 2xx reply for a SETUP method for a non-
    interleaved RTP/AVP/TCP media stream, the active party SHOULD
    initiate the TCP connection as soon as possible. The client SHALL NOT
    send a PLAY request prior to the establishment of all the TCP
    connections negotiated using SETUP for the session. In case the
    server receives a PLAY request in a session that has not yet
    established all the TCP connections, it SHALL respond using the 464
    "Data Transport Not Ready Yet" (Section  13.4.16) error code.

13.4.16 464 Data Transport Not Ready Yet

    The data transmission channel to the media destination is not yet
    ready for carrying data. However the responding entity still expects
    that the data transmission channel will be established at this point
    in time. Note however that this may result in a permanent failure
    like 462 "Destination Unreachable".

    An example when this error may occur is in the case a client sends a
    PLAY request to a server prior to ensuring that the TCP connections
    negotiated for carrying media data was successful established (In
    violation of this specification). The server would use this error
    code to indicate that the requested action could not be performed due
    to the failure of completing the connection establishment.

This will go into the next version unless some one comments on it.

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: Kylin Wei <[email-masked]>
Date: Wed, 06 Dec 2006 11:05:06 +0800

Perhaps independent TCP is a good idea, but I'm still unclear about in which
case we will use it.

Firstly, in non-NAT condition we will not use independent TCP because of the
efficiency. We must use the UDP transport.

Secondly, in NAT condition we can't use independent TCP because mapped TCP
originator address is different than the original address offered in SETUP
Transport header field. So media server will reject TCP connect request. In
addition, most media servers disallow the cases where client's RTP receiver
has a different public IP address than that of the RTSP Client. So even if
we use ALG or TURN we can't solve this problem.

In a word, I think the availability of using independent TCP to traverse NAT
is very limited.

Kylin Wei 
> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Tuesday, December 05, 2006 5:16 PM
> To: mmusic (E-mail)
> Subject: [MMUSIC] RTSP 2.0: Use of independent TCP
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 06 Dec 2006 10:38:28 +0100

> efficiency. We must use the UDP transport.

I agree that unless you have other reasons for using TCP, then UDP is 
better. However in cases content is fragile and the error rate is high 
there would be a point of using a reliable transport.

> we use ALG or TURN we can't solve this problem.

I think you are missing the possibility to have the server being passive 
and the client being active. Thus having the client initiate all TCP 
connections towards the server that is in the open. Thus these TCP 
connections are behaving like the original RTSP or an HTTP connection. 
Therefore I don't see any problems of having this work in all scenario 
with public servers and NATed clients.

But I agree that TCP for media should be used in a limited fashion. 
However using direct connections between the server and the client in 
case one uses TCP does have advantages in cases there are proxies involved.

Cheers

Magnus Westerlund

---

From: Kylin Wei <[email-masked]>
Date: Thu, 07 Dec 2006 10:51:59 +0800

> connections are behaving like the original RTSP or an HTTP connection.

I think you misunderstood my meaning. For example, a media end host is
behind a symmetric NAT and a media server is in the open. From media
server's perspective, the public IP address of RTSP client may be
202.102.11.1, but the public IP address of independent TCP (RTP receiver)
may be 202.102.22.2, although they both originate from the same end. But
media server can't determine that these two connection originate from the
same end by their public IP address, so it will reject the connect request
of independent TCP. 
Can you tell me how to solve this problem?

Kylin Wei 
> Sent: Wednesday, December 06, 2006 5:38 PM
> To: Kylin Wei
> Cc: mmusic (E-mail)
> Subject: Re: [MMUSIC] RTSP 2.0: Use of independent TCP
> 
> Kylin Wei skrev:

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 07 Dec 2006 10:29:07 +0100

> Can you tell me how to solve this problem?

Because the NAT that does this is broken. A NAT really should only use 
one external IP address per internal IP address when creating bindings. 
That way the problem that you state doesn't occur. I agree that this 
mechanism does not resolve the issue you state. But this is a corner 
case. A corner case which is only solved with a full fledged NAT 
traversal mechanism that also is capable of verifying that claimed 
destinations really belong to the end-point and can't be spoofed. 
Without that there will be a huge security issue.

Also I don't think media over TCP should be used primarily for NAT 
traversal. The main reason to use it is for content that actually needs 
the reliability.

Cheers

Magnus Westerlund