Cullen Jennings wrote:
Different overlay might want to have different ways of deciding how to
find TURN servers and identifying what servers should be TURN
servers._______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
I think this issue should be split up:
1) should service discovery be part of the base protocol? If so, what
service discovery algorithm should be specified? (the current draft
mentions ReDIR and describes a very simple mechanism for discovering
TURN servers, which should work well for a known density of TURN servers)
2) should a mechanism for identifying the ability to be a TURN server be
specified?
It adds complexity, but I'm afraid that there should probably be a
mandatory service discovery algorithm for (1). The existing algorithm
in Section 9 actually isn't too bad if you can estimate the density
parameters in advance. It's certainly easier than requiring everything
to implement ReDIR. Is it good enough?
I would really, really like to label (2) as out of scope for the base
(or mandatory portion of) protocol.
Bruce
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
