Subject: Re: ICE-for-RTSP? (was Re: [MMUSIC] RTSP: Integrated SETUP vs SIP/SDP Offer/answer)

From: "Xavier Marjou" <[email-masked]>
Date: Thu, 11 Jan 2007 18:14:26 +0100

> 1/ ICE-for-RTSP could, in principle, be designed to work for RTSP 1.0
> (and RTSP 2.0), with no changes to either.
>
>> 2/ ICE-for-RTSP could, in principle, be designed to work for RTSP 2.0,
> with no changes (but not for RTSP 1.0).
>
> 3/ ICE-for-RTSP could, in principle, be designed to work for RTSP 2.0,
> but requiring some small additional changes to RTSP 2.0.
>
> 4/ ICE-for-RTSP could not be designed to work for RTSP 2.0 without
> significant changes, so therefore it would make more sense to wait
> for a future "RTSP 3.0" (using SIP offer/answer), so that we could
> use more of the existing ICE-for-SIP work.

Alternatives 1/, 2/, and 3/ are evolutions in the RTSP protocol that
will "only" help negotiating NAT traversal for audio and video
streams.
Alternative 4/ would help negotiating NAT traversal not only for audio
and video streams, but also for the RTSP stream.

Today, with RTSP 1.0 or 2.0, the main limitation is that an RTSP
server located behind a NAT can not be accessed (default case) or can
be accessed by anybody (if the RTSP port has been open on the NAT).

With 4/, we could create a "conditional access" to an RTSP server.
Let's consider the following use-case: a user A wants to be the only
person who can access his streaming server located at his home B
behind a residential NAT.

The mechanism would be the following: The streaming server B is made
of an RTSP server and of a SIP UA with a SIP outbound connection. User
A sends a SIP INVITE in order to reach server B, and also in order to
propose an SDP offer for a session with an RTSP stream. B can accept
or reject the INVITE, possibly based on the Identity of A. In case B
accepts the INVITE, B sends a TCP-SYN towards A to open an "RTSP" TCP
binding "its" front-end NAT. The RTSP client of user A can thus open
the TCP connection with the RTSP server, as the NAT could then be
traversed.

I think it should be possible to allow this in the context of sip-rtsp
convergence and RTSP 2.0, although some few details would need to be
discussed.

Cheers,
Xavier

PS: Although out-of-scope, one could also think about "HTTP" instead
of "RTSP" ;-)

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