Peter Saint-Andre wrote:
Or shall we expect the client to ask about services (e.g., TURN servers) only at the moment it is attempting to prepare candidates for a negotiation?
I think yes. Looking through my code I was thinking a little more about shared secret allocation manner. Here are my points:
In the case of a shared secret per session, we have troubles with s2s users, since there is no session in s2s and we don't know how to delete stale shared secrets. So I think the easiest solution is to create a new unique username/password pair per <credentials> requests (and thus per single allocation), but this requires from a server to clean the secret if the allocation was not created in meaningful amount of time (to avoid credentials table overflow from rogue users) as well as clean the secret after the corresponding allocation completes. I prefer this way because it is easier to implement on a server side ;) I have only the question to client implementors: is it possible to keep a credentials per allocation and perform an allocation almost immediately after <credentials> response, doesn't it introduce implementation problems?
-- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
