googIPv6: false ineffective on Mac
Reported by
warren.m...@gmail.com,
Jul 12 2017
|
|||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Steps to reproduce the problem:
1. Set googIPv6: false in RTCconstraints and start connection to media server
2. Inspect chrome://webrt-internals and see the constraint is present in the offer
3. Check the icecandidates and see both IPv6 and IPv4 are present
3.
What is the expected behavior?
With the googIPv6: false constraint set you should see no IPv6 candidates in the gathered list
What went wrong?
IPv6 Candidates are collected and sent to other peer when we know they cannot be used.
This exacerbates other issues with ice checking timeout
Did this work before? N/A
Does this work in other browsers? N/A
Chrome version: 59.0.3071.115 Channel: stable
OS Version: OS X 10.12.5
Flash Version:
The googIPv6 constraint is converted to form
"value": "constraints: {{advanced: [{enableIPv6: {exact: false}}, {offerToReceiveVideo: {exact: 0}}, {offerToReceiveAudio: {exact: 0}}]}}"
as shown in the createoffer values
,
Jul 21 2017
Could someone from MTV look into this issue as we don’t have reported IP googIPv6. Adding "TE-NeedsTriageFromMTV" label for further triage.
,
Jul 31 2017
The new constraint syntax is not supported for this. Note also that passing constraints for this is nonstandard and might not be supported in the future, even with the old syntax. |
|||
►
Sign in to add a comment |
|||
Comment 1 by warren.m...@gmail.com
, Jul 18 2017I can see what is happening here now. I am using a library that now sends the RTCConstraints options object to createOffer, not peerconnection creation. They have done this as the Offer options are no longer compatible with peerconnection constraints. The real issue is that an additional class of options is required for the PC constraints, that do not include the Offer options. If the googIPv6: false is broken out into distinct options class and supplied to PC it works as expected. Sorry for this distraction, however on one level this is still not complete as the new form of this constraint {advanced: [{enableIPv6: false}]} is unable to be passed to the PC. Only the non compliant form {optional: [{googIPv6:false}]} can be used, which will then be converted to the new object form.