Open aboba opened 10 years ago
Some other ICE-related questions:
ICE role conflict resolution is automatic -- the application does not need to be involved in this.
https://github.com/openpeer/ortc/issues/54
^ I believe this gathering policy will satisfy your IPv4 / IPv6 scenarios.
I believe that what is proposed in #54 is far too complex. Why not make priority writable and be done with it.
That would certainly provide maximum flexibility. Even with lots of flags it's hard to enable all potentially useful policies (e.g. preferring temporary IPv6 addresses within IPv6, but still preferring IPv4 over IPv6).
On Apr 13, 2014, at 3:29 PM, Martin Thomson notifications@github.com<mailto:notifications@github.com> wrote:
I believe that what is proposed in #54https://github.com/openpeer/ortc/issues/54 is far too complex. Why not make priority writable and be done with it.
— Reply to this email directly or view it on GitHubhttps://github.com/openpeer/ortc/issues/42#issuecomment-40322112.
Is it possible to trigger code behaviour changes when a dictionary property is set? Because we need to re-prioritize ICE behaviour based upon these changes. Also I don't think it could be done as a single transaction. Do you see any issue in changing these priority attributes on the fly one-at-a-time?
Hmm, dictionary, good point. It could be made into an interface without any serious side effects, which would allow for the write-through.
Since the priority values need to be set before the ICE checks occur, I think doing this direct tweaking of priority values would be difficult. A policy handles this kind of thing OK, but like all policies, they give up some amount of flexibility.
My general feeling is that the runtime needs to handle this sort of stuff mostly internally, or else all WebRTC apps will have problems in IPv6 scenarios.
Decision was to try and resolve "happy eyeballs" first, then see if there are any use cases beyond what that should resolve.
Would make sense to have a control to check order (to be a policy)
Currently there does not appear to be a way to delete ICE candidates or change their priority.
This is particularly needed when a browser supports both IPv6 and IPv4. If it were possible to change the priority then ICE "Happy Eyeballs" (https://tools.ietf.org/html/draft-reddy-mmusic-ice-happy-eyeballs) could be implemented in an application even on browsers that did not support it natively. Also, an application could choose only to support IPv6 privacy addresses.