Subject: [MMUSIC] RTSP server behind NAT

From: [email-masked]
Date: Mon, 31 Mar 2003 19:50:30 +0200

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(?)

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 ?

Jonathan can you explain what good TURN is supposed to do to RTSP ?

regards,

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

                                                                                                                                              
                                                          To:   Thomas Zeng <[email-masked]>                                            
                                                          cc:   [email-masked]                                                               
                                                           (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                         
                                                          Subject:    Re: A reason to put RTSP server behind NAT (was RE: [MMUSIC] What is    
               Magnus Westerlund                           symmetric RTP?)                                                                    
               <[email-masked]                                                                                                
               .se>                                       Classification:                                                                     
                                                                                                                                              
               Sent by:                                                                                                                       
               [email-masked]                                                                                                          
                                                                                                                                              
               31/03/2003 10:14                                                                                                               

Hi Thomas,

I think the application in itself is a valid one. However if one
provides services that is assumed to be used from the the public net I
still think it is a reasonable thing to assume that the service provider
(nanny cam host) in this case uses a public IP address.

I think that Jonathan is right in his observation of the big question.
Will private persons run RTSP servers to provide functionality in for
example conversational calls. If the answer is yes, then we need to
address the RTSP servers behind NAT problem. However looking at the
current market it seems that the important question is how to solve the
RTSP server in public network first. If someone is ready to start
digging into solving this problem, please go ahead and provide input.
The design of the solution for public IP RTSP servers may need to
consider something out of a proposal for how to solve the private IP
RTSP server problem. However it is obvious that such a solution must
also address how to establish the control connection to the server.

Last I have one comment to what you write:

Thomas Zeng wrote:

>Of course one can ask the daycare to put the RTSP server box in the open,
>but that means additional cost (it costs $5 dollars/month to get even a
>dynamic IP address from Time-Warner cable company here in San Diego), some
>one time fee to change network topology -- not to mention security
>degradation.
>
>
I kind of react to the last thing. Security degradation: NATs does not provide any security protection, it only provides some obscurity. A NATed machine may of course not be reachable and can therefore not be be directly attacked. However this a firewall
can also provide. The major problem is the huge security gap that the deployment of a NAT creates. With NATs there is basically no guaranteed protection against hijacking or eavesdropping attacks as it is impossible to source authenticate. So saying that
removing the NAT will reduce the security I think is wrong.

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 31 Mar 2003 16:39:40 -0500

[email-masked] wrote:
 > 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.
 >

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.

 > 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 ;-)
 >

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.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com