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 P2PSIP at ietf.org 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 P2PSIP at ietf.org https://www.ietf.org/mailman/listinfo/p2psip