[libnice] NiceAgentRecvFunc invoked for data no matter the source

Lorenzo Miniero lminiero at gmail.com
Fri Aug 22 01:09:41 PDT 2014


Hi Youness,

thanks for the clarification. .Yes, I thought that candidate switching may
be involved, I was just surprised to see libnice reacting to data coming
from a source that was not part of the negotiation and so, as you say, not
authenticated.

So that part is indeed a bug. I'll open an issue as you suggested. No way
to mitigate it until it is fixed, then?

Lorenzo

2014-08-22 0:22 GMT+02:00 Youness Alaoui <kakaroto at kakaroto.homelinux.net>:

> Hi,
>
> That's a feature, because while it's usually the same, sometimes your
> selected pair may be different from the peer's selected pair. Or simply
> because one interface was disconnected and the peer switched to a different
> pair, etc.. If libnice receives data from a valid peer, it will send you
> the data, it's normal. The 'selected pair' is mostly used for sending.
> However, there is also a bug here, it is currently forwarding back to the
> application any data it can't parse. It should only do it if the data came
> from an already authenticated pair. I suggest you file a bug report about
> this : https://bugs.freedesktop.org/enter_bug.cgi?product=Nice
>
> Thanks,
> Youness.
>
>
>
> On Thu, Aug 21, 2014 at 12:51 PM, Lorenzo Miniero <lminiero at gmail.com>
> wrote:
>
>> Hi,
>>
>> I don't know if this is a known bug or feature, as I couldn't find any
>> reference in the documentation, so I'll try and ask here.
>>
>> I noticed that, after a successful ICE setup using libnice, apparently
>> the NiceAgentRecvFunc callback I set is invoked for a specific component
>> even when data is not coming from the peer candidate that was selected. To
>> make a practical and reproduceable exampe, I tried setting up a media
>> session and, after a successful ICE setup, I used the nc command to send
>> data to the port my application had selected. Surprisingly, the callback
>> was notified, and the data was available, while I expected the library to
>> ignore this external data as it was not part of the "connection"
>> established between the two parties. Again, not sure if it's a bug or a
>> feature, but in my case it's pretty awkward as I have no way to understand
>> whether the message came from who I meant or not.
>>
>> Is there any way to force libnice to do this kind of filtering and
>> actually enforce the "connection" that was negotiated? or, as an
>> alternative, can I "resolve" the "sender" somehow and do this at an
>> application level, if needed?
>>
>> Thanks,
>> Lorenzo
>>
>> _______________________________________________
>> nice mailing list
>> nice at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nice
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20140822/17cf8504/attachment.html>


More information about the nice mailing list