Subject: Re: [MMUSIC] RTSP server behind NAT

From: [email-masked]
Date: Tue, 1 Apr 2003 14:04:12 +0200

>NATs on both sides does not always require a relay on the public
>Internet. It only does if both NATs are symmetric. If at least one is
>full cone, port restricted, etc., then the relay can be avoided. ICE
>will make this determination for you, and only use TURN if connectivity
>cannot be established directly.

I understand: one always need at least one public server,
but in some cases that server does not have to "relay" i.e. process the data,
instead the system is configured so that data flows directly from peer to peer.

> ...consider the model where SIP is used to establish
> the session, and then RTSP is introduced for the control aspects.
.........
>Thoughts?

Implementing SIP looks like a *lot* of work !-)

regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.platform4.philips.com

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 02 Apr 2003 09:58:39 +0200

Hi,

I understand that there is interest to fix RTSP's NAT traversal 
capabilities to handle cases when both parties using private address 
spaces with NATs between them. This will require work from the one 
interested in this. With these assumptions you must also look into the 
problem of how to connect with TCP to the RTSP server in the first 
place. This seem to require RTSP proxies on the borders between 
different address domains. However I assume that a lot of these 
information can be had by looking how SIP solves the problem.

I have some comments about TURN and RTSP. On the way to San Francisco I 
managed to analyze TURN and how it fits with RTSP. The major hurdle here 
is that the media destination address will be totally different from 
where the TCP connection comes from. If we are going to continue with 
our assumptions about when it is okay to send to another address we need 
the mechanism to determine that the destination accepts the data.

When it comes to a solution of the problem of having servers on NATed 
addresses the ones doing the work will need to look into how to solves 
this problem. There seem to exist a couple of different ways to solve 
the problem.
1. Incorporate ICE into RTSP SETUP procedures. Includes need for doing 
multiple ICE rounds. This is similar to the Offer Answer problem for RTSP.
2. change RTSP to use SIP style session initiation. This work I think is 
similar to actually defining RTSP 2.0 and might be a rather grand work. 
I see need for having to determine which part of SIP that is needed. 
What extensions in SIP that will be needed to allow the media control 
part of RTSP to work as before. Also the whole integration between a 
normal conversational service and media control services needs to be 
looked into. I don't think it is a simple problem. Otherwise IETF would 
not have taken this time to even come close to a working conference 
solution.
3. Other alternatives. Does it exist other possible solutions?

My conclusion is that the peer-to-peer RTSP over NATed networks will not 
be solved in a short time frame. And there is need to solve how to 
handle RTSP when only the client is in a private network. My proposal 
would be to progress the work simultaneously. I strongly believe that we 
can create something that work in time frame of the updated RTSP 
specification for public servers. There is of course important to align 
the work and ensure that either the whole public server work is a 
reusable for the peer-to-peer work, or at least does not create 
problems. I know that a single solution are normally better, but I think 
market forces will again make themselves remembered.

Best Regards

Magnus

Jonathan Rosenberg wrote:

>
>
> [email-masked] wrote:
> > Magnus, I concur with Thomas,
> >
> > Since we have telephone handsets that can encode video in real time,
> > Since we have PCs at home with WebCams, Since all these are behind
> > NATs, Since multicast (and SSM) will not be
> > available/desirable/permitted in many cases, We need to make sure
> > that a  RTSP server can exist in these environements, as RTSP is the
> > obvious peer-to-peer video protocol to use.
> >
> > I suspect the key issue is that we have to assume that both end
> > points (peers) are behind NATs and then I am afraid that the solution
> > requires a "public" server in the middle.
> >
> > At this moment I suspect that TURN is one possible candidate(?)
>
> will make this determination for you, and only use TURN if 
> connectivity cannot be established directly.

>
> >
> > Some kind of a "reversed" RTSP relay could also do the trick;
> >> From the second peer (receiver of streams) point on view that relay
> >> would be a plain RTSP server.
> > The special trick is that the first peer (origin of streams) would
> > need to contact this public gateway to "expose" that it has something
> > to stream... And here comes the "reversed" weird stuff: That first
> > peer acts as a RTSP server but it *initiates* the first TCP
> > connection to the RTSP relay and that relay acts as a RTSP client but
> > it is listening on some TCP port...
> >
> > It assumes that there is some way for the first peer to tell the
> > second peer that the streams are available at that relay server.
> > Email could do that, or a voice call, or pigeons ;-)
> >
> > Not sure if/how  this is similar/different to what is intended with
> > TURN ?
>
> TURN is similar, in that both sides need to rendezvous at a central 
> server. However, only one side needs to know about TURN. The other 
> will rendezvous by simply sending media to the TURN server.
>
>
> >
> > Jonathan can you explain what good TURN is supposed to do to RTSP ?
>
> It would support the case of the RTSP client and server both behind 
> separate, symmetric NAT.
>
> To support it, you need only make sure that RTSP allows the client to 
> specify the IP/port on which it will receive media. This is the same 
> thing you would need to do to support STUN.
>
> Getting back to this general issue of peer-to-peer RTSP, in my view 
> this is the ideal case to consider the model where SIP is used to 
> establish the session, and then RTSP is introduced for the control 
> aspects. This way, RTSP does not have to reinvent all the work that is 
> being done in SIP for nat/fw traversal, and all the applications where 
> the media streaming is integrated with person to person communications 
> is very easy.
>
> I think that there are no changes to RTSP to support this. We would 
> need some kind of SIP or SDP extensions to signal the usage of RTSP as 
> a control for another media stream, and then use SDP extensions to 
> pass any RTSP information needed to make this work (for example, the 
> session ID).
>
> Thoughts?
>
> -Jonathan R.
>

-- 

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]

---

From: Thomas Zeng <[email-masked]>
Date: Thu, 3 Apr 2003 12:11:14 -0800

Magnus:

On the high level,  I agree that the first focus of RTSP taskforce should be
to solve the easy problem: RTSP server in the open
IP public network, clients are behind NAT.

- thomas

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Tuesday, April 01, 2003 11:59 PM
To: [email-masked]
Subject: Re: [MMUSIC] RTSP server behind NAT

Hi,

Best Regards

Magnus

-- 

Magnus Westerlund