[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] non-SIP ICE: useful or not?
Jonathan Rosenberg skrev:
I'd like to get some discussion going around this question prior to the
meeting. Please take a look at:
http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-ice-nonsip-01.txt
The main question: is a draft like this sufficiently useful to produce
or not? Given its main audience are the (relatively few) protocol
designers of things using ICE, there is an argument to be made we don't
really need this. I'd especially welcome comments from Miika, Magnus,
Hannes and other folks actually producing documents that would use the
contents here.
Comments on details welcome too, though secondary I think to the main
question.
Okay, lets start with the main question.
I find this document quite useful as a guide to what points to think
about. It takes some work to figure this out, even when one is quite
used to ICE operations. I think it will help others that are talking the
ICE route for NAT traversal.
Other comments:
- In section 2, the draft talks about the need for a rendezvous server.
Looking at RTSP, it currently doesn't fulfill the requirement in this
aspect. To get the full functionality to reach a server behind a NAT
something like a RTSP proxy in which a server can register is one
possible solution. In which case one would fulfill the requirements. I
wonder if one should soften the wordings in the last paragraphs of 2 to
also protocols that has more limited rendevous mechanisms but traversal
problems for there direct traffic.
- Figure 2, has two "client 1"
- Section 3, isn't a goal to have reuse on the media plane when possible.
- Section 5.1.2: "However, they may be overly conservative
for certain applications."
I think that this text should be rewritten to be a little less positive
to respecifying the pacing parameters. I am quite okay that if one
really have certain requirements that one discuss this.
- Section 5.1.3: I think that multiple STUN and TURN servers make more
sense to talk about in the context of multihoming, than for multilayer
NAT. This because of the inherent addressing problems in the
intermittent layer with potentially overlapping private address spaces.
- Section 5.1.6: I actually think Capability Query is on of the better
as it reduces the resource utilization for everyone. However, there are
clearly cases when that round-trip may become problematic. But there are
quite many cases where capability exchange can be done in registration
and lookup phases of the signaling protocols.
- Section 5.3: I think that one should have some discussion on the
possibility to use only triggered checks if one ICE agent always is
reachable. Very similar considerations to the Lite deployment, but in
this case with DDoS protection. First of all having that sender verify
routability, and secondly to reduce the inherent risk ICE enabled server
represent when actively initiating STUN connectivity checks.
- Section 5.4.1: In the RTSP context we have realized that depending on
the general RTSP state it is optimal to use different type of
nominations. When in a non-media sending state aggresive is better as we
can use the RTSP PLAY signalling to determine when to start using the
aggressively nominated candidates. When in a media sending state regular
seems better to remove the glitches. Maybe something to add to the
considerations.
Cheers
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Färögatan 6 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic