Subject: [MMUSIC] RTSP NAT: Using ICE in RTSP - Proposal

From: Magnus Westerlund <[email-masked]>
Date: Fri, 02 May 2003 17:24:58 +0200

Hi,

I think we are having a good discussion. However to come to some 
conclusion we should try to compare the pro and cons of STUN/ICE and 
Symmetric RTP. To do this I think people would need to understand a bit 
better how STUN/ICE would work with RTSP. Therefore I have created the 
following proposal:

1. The client retrieves the SDP from the ICE enabled server. This SDP 
contains indication that the server supports ICE and gives the 
address/ports for each media and its necessary UDP streams. This may 
require a SDP extension or possibly the c= and port numbers can be used. 
This will however require the server to send media streams from well 
known ports. Many sessions will go over the same ports.

2. The client analysis the SDP and determines the number of local UDP 
ports it will need. For each port it also installs a STUN server with 
authentication requirement using a authentication tag. From these ports 
the client then tries to connect to the server's announced ports for 
respective media flow. If successful the NAT binding nearest the server 
is learned. Also other addressed can be collected, like public STUN 
addresses and TURN address.

3. Client creates a SETUP request where he includes a number of 
transport header specifications. The client may offer more than one 
normal transport configuration, but for each such it will need to create 
multiple copies. Each copy contains the different possible destination 
addresses that it has learned in falling priority order. The client also 
includes in the transport specification the ICE indicator carrying the 
authentication tag necessary to use the clients STUN servers.

4. The server receives the SETUP request and selects which transport 
specification configuration it would like to accept, i.e. all 
specifications that are the same except for destination address/port. 
For all specifications in the configuration the server tries to STUN 
these addresses/clients. Depending on the answers:
  A. The server successful connects to the clients STUN server: The 
server selects the specification with highest priority that yields a 
successful response and include that address/port in the SETUP 
response's transport headers destination field. The media is ready to be 
played.
  B. The server fails to reach the client. It uses a new error coded to 
inform the client of this. At the same time it includes a updated SDP 
which contains all addresses that it is reachable on. The server might 
have learned some new since the initial SDP. The client when receiving 
this tries again by going to point 2 and repeat the whole. If it fails 
multiple times the server and client lacks connectivity.

As seen above the addition of ICE to RTSP will require the following 
standardization work:
- Possible SDP extensions to inform client that it is ICE capable.
- A Transport header parameter for the authentication tag.
- A new RTSP error code and specification on body (SDP) return.

New protocol mechanisms that will be required to implement:
Server:
    - Full STUN server
    - limited STUN client
    - HMAC for STUN authentication
    - SDP extensions MID + ICE necessities
    - SDP generation on the fly of more parameters.
    - RTSP error code and ICE extension

Client:
    - Limited STUN server
    - Limited STUN client
    - HMAC
    - SDP extensions MID + ICE necessities
    - RTSP error code and ICE extension

Properties:
- Solve NAT connectivity discovery for basically all cases as long as a 
TCP connection between them can be established in the first hand. This 
include Servers behind NATs (A proxy (DNS ALG) between address domains 
will be required to get TCP through).
- Prevents DOS attack possibilities as receiving client requires to do 
STUN responses on its media reception ports.
- Will increase the setup delay with at least the time it takes the 
server to perform its STUN requests.
- Forces servers to use a few well known media ports.
- Depends on being able to do a demultiplexing between UDP packet 
contents first byte to determine if packet is media or STUN message.

Please consider this proposal. Feedback about shortcomings, errors, and 
possible improvements are welcome.

Best Regards

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