@praveen.kd23 maybe preparing a Merge Request with your patch will help the discussion. I think this is a very important enhancement to libnice. The problem you're fixing is quite common according to our experience.
@praveen.kd23 thanks that makes a lot of sense
priv_add_new_check_pair
The above method adds a new candidate pair to conncheck_list (List of available pairs) only if its priority is less than the current selected pair . When LAN and Wifi remote candidates were available , only RemoteLAN-local pair is added in conncheck_list , this causes conn_check_update_selected_pair
method to fail since RemoteWifi-local candidate pair is not present in the conncheck_list .
The idea is to add all the available candidate pairs in conncheck_list and select the pair based on USE-CANDIDATE attribute .
@praveen.kd23 this looks interesting! Basically you're making a controlled libnice agent honor incoming USE-CANDIDATE, regardless of current selected pair priority. IIRC this is a violation of the RFC, however IMHO it makes more sense for a passive agent to just follow the controlling endpoint decisions, rather than make assumptions on pair priorities. Could you please clarify the meaning of the change in the other method too?
Hi , we are facing the same issue in our servers(always act as controlled mode) .
conn_check_update_selected_pair
priv_add_new_check_pair
In both of the above methods , candidate pairs priority is checked regardless of the agent's mode ,this is restricting the agent to update to the new pair upon receiving use_candidate . Have added a agent's mode check in both of the methods and the issue resolved .
I would greatly appreciate it if you could take a moment to review the changes .
https://github.com/libnice/libnice/compare/master...praveen-kd-23:libnice:master
Olivier Crête (2c72599d) at 04 Mar 20:37
version 0.1.22.1
Olivier Crête (0343d62c) at 04 Mar 20:37
version 0.1.22
Olivier Crête (ae3eb16f) at 04 Mar 20:37
version 0.1.22
This is one possible approach to break the circular dep between gstreamer and libnice. What do you think?
The previous one produced XML so large that libxml choked on it.
Olivier Crête (4d14e613) at 19 Feb 22:29
tests: Reduce the printing a little to please libxml
The previous one produced XML so large that libxml choked on it.
Although this is the smallest problem when it comes to RFC8489 support, it could've been zero padded since the beginning, since RFC 5389 never specified what the padding should be.
For whatever reason it was ' ' (ascii 20) up until now.
Servers which support only RFC 8489 would reject requests generated by libnice due to this, even though the messages are RFC8489 conform, with the only exception in padding.
Padding is defined in rfc8489 as MUST be zero and MUST be ignored - https://www.rfc-editor.org/rfc/rfc8489.html#section-14
While in RFC 5389, padding MUST be ignored, but MAY be any value - https://datatracker.ietf.org/doc/html/rfc5389#section-15
Due to working with servers which assume that STUN requests are RFC8489 conform, their expected hash is calculated with zeroes, so it differs from what libnice is sending.
It would help us immensely to get this merged so that we can ensure compatibility.
Olivier Crête (2de74727) at 19 Feb 20:20
Change padding to be rfc8489 conform
A receiver that doesn't ignore it is invalid, but indeed we should set it to 0. I think using ' '
was an entirely arbitrary choice.
Although this is the smallest problem when it comes to RFC8489 support, it could've been zero padded since the beginning, since RFC 5389 never specified what the padding should be.
For whatever reason it was ' ' (ascii 20) up until now.
Servers which support only RFC 8489 would reject requests generated by libnice due to this, even though the messages are RFC8489 conform, with the only exception in padding.
Padding is defined in rfc8489 as MUST be zero and MUST be ignored - https://www.rfc-editor.org/rfc/rfc8489.html#section-14
While in RFC 5389, padding MUST be ignored, but MAY be any value - https://datatracker.ietf.org/doc/html/rfc5389#section-15
Due to working with servers which assume that STUN requests are RFC8489 conform, their expected hash is calculated with zeroes, so it differs from what libnice is sending.
It would help us immensely to get this merged so that we can ensure compatibility.
Do you have logs of the candidates that you feed libnice? If you do, can you check when it happens if the "priority" field is 0 ?