[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] RTSP ICE (was Re: New I-D on ICE for non-SIP protocols: NICE)
Rémi Denis-Courmont skrev:
> * PGP Signed by an unknown key: 02/19/2008 at 06:38:27 PM
> Le Tuesday 19 February 2008 14:35:26 Magnus Westerlund, vous avez écrit :
>> I mostly agree, but making things simpler than they are also doesn't not
>> help. I think ICE in RTSP can be done more straight forward than in
>> SIP O/A. There will clearly be a few situations where one can make make
>> trade-offs.
>
> Sure. I assume what we want is NAT (and stateful firewall) traversal,
> conenctivity error detection and return routability checks.
>
> Now that I think about it more... There is one thing is, "plain" ICE would be
> clearly be overkill whenever the server is in the unencumbered public
> Internet. On the other hand, if I understand ICE-Lite is not sufficient (no
> return routability checks/DoS protection).
>
> As for when the server is behind a NAT, "plain" ICE will NOT be sufficient:
> UPnP, NAT-PMP or static port forwarding will be needed for the RTSP control
> connections in the first place. That is yet another (unavoidable) extra
> intricacy and limitation that is not dealt with in RTSP-NAT, as far as I
> remember (the I-D has expired). As much as I don't like to rely on any of
> these 3, it would seem we have to :-( I wonder why not use these same port
> forwarding scheme for the media flows. Now, this essentially turns the NATted
> RTSP server into a public RTSP server, which is a HUGE simplification of the
> problem. Am I missing something?
I don't think you are missing something. However, we are splitting up
the problem where it can be done. It is clear that the return
routability check and support for clients behind NATs are priority one.
Priority two is to support servers behind NATs. ICE will allow NAT
traversal for the media using datagram (primarily UDP) also for servers
behind NATs. Then the second problem for RTSP servers behind NATs is how
the clients will reach them. This is clearly a unresolved problem, but
it is separate from the media traversal. Thus we take one problem at a
time. If someone likes to suggest something on how the resolve them I
really would appreciate it.
[SNIP]
Lets discuss this in the context of the draft that will come out today.
I think we considered most of the issues. The Froozen algorithm is still
an open issue that will need discussion.
>
>
> By the way, is there any RTSP ad-hoc?
>
I think there will be one. At least one on RTSP NAT. However, I need to
see what wholes there are in my IETF week to have it.
Cheers
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic at ietf.org
http://www.ietf.org/mailman/listinfo/mmusic