Subject: [MMUSIC] RTSP and NAT

From: "Enrico Balatti" <[email-masked]>
Date: Fri, 13 Jun 2003 16:50:18 +0200

Dear List Members,
 
my question is about RTSP and STUN integration to make
RTSP traffic traverse a NAT.
 
The IETF-draft <draft-ietf-mmusic-rtsp-nat-00.txt> in the section 
3.1.2 describes how a RTSP client using RTP transport over UDP can use STUN to traverse a
full cone NAT.
 
I've setup a little demo with a Full Cone NAT between a client (RTSP and STUN) and a server (RTSP and STUN).
In this situation, I've noticed that the RTP flow from the server to the client is not blocked by the NAT
therefore it seems that the steps indicated in section 3.1.2 are not necessary in this case. I think,
but I am not sure, that this is due to the fact that the RTSP client I'm using (MPEG4IP) include (according
to RTSP specification) in the transport header only the "client_port" information and not the "destination" parameter (that
includes the IP address of the client and the ports number). 
 
If the RTSP server doesn't receive the "destination" parameter in the transport header
what IP address does it uses how IP destination of the RTP flow? If it uses the IP address
from wich it receives the RTSP methods (that is the mapped IP), then this explains why the RTSP client behind a full
cone NAT receives the Video Stream (according to definition of a Full Cone NAT: any external host can send a packet to
the internal host, by sending a packet to the mapped external address.)

If my consideration are right the following statement (to add to section 3.1.2) is true:
 
>If the user is behind a full cone NAT, STUN allows the
>RTSP client to traverse the NAT with some simple client side
>adaptations. 
If the client doesn't include in the RTSP "transport header"  the "destination"
parameter then the client doesn't need any adaptation.
 
Best Regards,

Ing. Enrico M. Balatti           
Tel. 02-23954327

Fax. +39 02 23954527

 < mailto:[email-masked]> 

CEFRIEL -Network Systems Area 
Via Fucini, 2 
20133 Milano - Italy 

<  <http://www.cefriel.it/> http://www.cefriel.it/>

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 15 Jun 2003 18:30:13 +0200

Hi Enrico,

Yes, I believe you are mostly correct. But I would like to clarify a few 
things why I think there at least some client modifications.

The scenario you have when you have a client (A) behind full cone NAT to 
a RTSP server (C) and STUN server (D).
A->D: The client makes a STUN request for each UDP port the session needs.
A->C: The client makes a RTSP SETUP utilizing only client_port.

A->C: The client sends a RTSP PLAY.
C->A: RTP stream plays.

This works under a few assumptions.
1. The RTSP TCP connection gets the same public IP address as the UDP 
mappings.
2. The STUN request results in that the correct port numbers are 
received, i.e. RTP gets a even port and RTCP gets the next odd.

Of the above assumption I is commonly fulfilled. However the second, may 
not be fulfilled. Why this works does most likely depend on two things. 
1. The server does not care if it delivers RTP to odd or even port 
(Which is a good implementation strategy). 2. The streaming works 
without RTCP getting through. The RTCP that is directed at the RTP port 
number + 1, and are lost there.

The second point to make about the RTSP NAT draft is that it intended to 
be used with updated RTSP specification 
draft-ietf-mmusic-rfc2326bis-??.txt. In that draft we define new 
transport parameters for address and ports that are more flexible and 
allows to specify for each individual IP/UDP flow what address/port it 
should be sent to. This allows one to avoid making the above assumptions.

The use of the tuple of address and port is a good thing, as it ensures 
that both parameters are explicitly given. This also makes the server 
possible to define certain strategies regarding forwarding media to 
certain addresses.

The client needs adaptation to use the STUN method as it needs a STUN 
client. However no more changes are needed for this solution.

I hope this clarifies a few things.

Magnus

Enrico Balatti wrote:
> to RTSP specification) in the transport header only the 
> "client_port" information and not the "destination" parameter (that
> from wich it receives the RTSP methods (that is the mapped IP), then 
> this explains why the RTSP client behind a full
> cone NAT receives the Video Stream (according to definition of a Full 
> Cone NAT: any external host can send a packet to
>  <mailto:[email-masked]>
> 
> <http://www.cefriel.it/>

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research ERA/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