[Nice] public API to get selected pair

[Youness Alaoui]

On 01/22/2013 06:24 PM, Bryce Allen wrote:
> Thanks for the quick reply, comments inline.
> 
> On Tue, 22 Jan 2013 17:38:18 -0500
> Olivier Crête <olivier.crete at collabora.com> wrote:
>> Hello,
>>
>> On Tue, 2013-01-22 at 16:03 -0600, Bryce Allen wrote:
>>> I notice that there is nice_agent_set_selected_pair, but not
>>> get_selected_pair.
>>
>> You can listen to the "new-selected-pair" signal, it will tell you
>> which candidates have been selected.. But I agree it would be good to
>> add such an API for completeness.
> The signal gives you the foundations - it wasn't immediately obvious to
> me that the foundation would uniquely identify the candidate, but it
> does appear to be the case looking at the internal code. So I just need
> to iterate over nice_get_remote_candidates and
> nice_get_remote_candidates, doing strncmp on the foundations until I
> find the match for each?
> 
Yes, as per the ICE specification, the foundation must uniquely identify each
candidate. You should be able to use the get_local_candidates and
get_remote_candidates to know which one candidate has been selected.
Make sure you do call get_local_candidates and get_remote_candidates and not use
the previously received values because both local and remote candidates can
change dynamically during the connecting phase (addition of peer-reflexive
candidates).

> 
>>> If I can get the selected pair, I can destroy NiceAgent and
>>> immediately bind to the local base address and send to remote,
>>> before any intermediate firewall sessions timeout. UDT sends
>>> frequent keep alives so once the application takes over the
>>> bindings will be maintained.
>>
>> Are you aware that the libnice reliable mode is not TCP, but a custom
>> TCP-over-UDP implementation (that is compatible with the one used by
>> Google Talk). And it's definitely not compatible with UDT, which is a
>> completely different protocol. So you need to be using libnice on both
>> sides (or libjingle) to send and receive. Alternatively, you could try
>> to put libnice below UDT, but I'm not sure how the UDT code works.
>>
>> Also, if you end up using a TURN relay, you need to send through
>> libnice, as the packets are encapsulated.
> Our current plan for relay is very application specific, so we would
> not be using TURN anyway. Using libnice reliable is technically
> possible, just extra work since we already have a UDT implementation.
> Much simpler for us to use libnice to negotiate the addresses, then stop
> the agent and give control to UDT.

It might seem simpler but I expect you'll be having issues in the future. As
Olivier said, that's not the way it's supposed to work. ICE is meant to be
interactive, there will be keep alive and binding requests sent every once in a
while, your implementation would need to be able to handle those. If you go
through TURN, packets are encapsulated, and of course, the reliable mode is TCP
over UDP. If you're not using TURN (not sure what you're using then, I'm curious
to know how you can setup a relay with ICE that isn't TURN-based), and you're
not using the reliable mode, and you make sure that you control both peers and
that both stop using ICE, and you take care of your own keep-alive mechanism,
then yeah, it might work. Just know that it has never been tested before :)

> 
> Thanks again,
> Bryce
> 
> 
> 
> _______________________________________________
> nice mailing list
> nice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nice
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/nice/attachments/20130123/503dd769/attachment.pgp>