[libnice] Invalid candidate foundation string?

Olivier Crête olivier.crete at collabora.com
Mon Jun 19 18:15:38 UTC 2017


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
-- 
Olivier Crête
olivier.crete at collabora.com


More information about the nice mailing list