[libnice] Invalid candidate foundation string?

[Juan Navarro]

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 
registered?

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:
> Hi,
>
> 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..
>
> Olivier
>
> On Mon, 2017-06-19 at 18:57 +0200, Juan Navarro wrote:
>> Hello,
>>
>> 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
>> that
>> the hyphen ("-") is not allowed in a candidate name, according to
>> the
>> ICE RFC.
>>
>> More specific details:
>> * discovery.c uses the template "remote-%u" to generate foundation
>> names
>> for ICE candidates.
>> * RFC 5245 section 15.1 defines "foundation" as a string composed of
>> ALPHA, DIGIT, '+' or '/' characters (but specifically, no '-'
>> character).
>> * 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
>> character
>> '-' is added to the list of accepted characters.
>>
>> Can this be considered a bug of libnice? In other case please point
>> me
>> to some resource which explains this.
>>
>> Thanks,
>> Juan
>> _______________________________________________
>> nice mailing list
>> nice at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/nice