[libnice] Invalid candidate foundation string?
juan.navarro at gmx.es
Mon Jun 19 23:38:10 UTC 2017
I think that generating invalid data as a means of indicating an
internal condition is always wrong, regardless of what is the intention
of that indication...
The RFC indicates that the foundation of a new peer-reflexive candidate
"[...] is set to an arbitrary value, different from the foundation for
all other remote candidates". No doubt that using invalid characters is
an effective way to achieve this, but it seems to me that the spec
wasn't thinking on this technique when they wrote it.
Maybe choosing something like "remote/%u", and then traversing the
currently known remote candidates to ensure that it wasn't already
In my case, the wrong candidate arrives from the signal
"new-selected-pair-full", which in my opinion is totally fine and not
only for debugging purposes but as part of the normal expected operation
of the library. However, this signal comes with invalid data. As I
understand it, this signal exists to inform the application of how a new
candidate pair has been nominated and selected, and it should carry
valid information at all times.
If the decision about using these invalid foundation strings is firm,
then I would request that the documentation explains this design
decision, and user applications will have to use an extended version of
the expected BNF to account for the character '-'.
On 19/06/17 20:15, Olivier Crête wrote:
> It's a bug and it's not.
> So those remote-%u candidates are only used for peer reflexive remote
> candidates, those are never sent over the wire. They only exist locally
> (and we announce them for debugging purposes). So I don't think we need
> to create a valid string. The nice advantage of not having a valid
> string is that we're sure not to clash with real ones, the less nice
> thing is that it does get caught in your check and might confuse other
> code too..
> On Mon, 2017-06-19 at 18:57 +0200, Juan Navarro wrote:
>> my application has been rejecting some candidates received from the
>> NiceAgent's signal "new-selected-pair-full", based on a regular
>> expression we use to validate them. It turns out that the remote
>> candidate has a foundation name such as "remote-1", and it seems
>> the hyphen ("-") is not allowed in a candidate name, according to
>> ICE RFC.
>> More specific details:
>> * discovery.c uses the template "remote-%u" to generate foundation
>> for ICE candidates.
>> * RFC 5245 section 15.1 defines "foundation" as a string composed of
>> ALPHA, DIGIT, '+' or '/' characters (but specifically, no '-'
>> * RFC 5234 appendix B.1 defines ALPHA to be the usual ASCII letters
>> ([A-Za-z]) and DIGIT to be the ASCII digits ([0-9]).
>> I haven't been able to find any update to these RFCs where the
>> '-' is added to the list of accepted characters.
>> Can this be considered a bug of libnice? In other case please point
>> to some resource which explains this.
>> nice mailing list
>> nice at lists.freedesktop.org
More information about the nice