[libnice] Findings: Peer to Peer srflx candidate Connectivity issues observed

[Anand Sivaram]

Please note the first link is not correct, this was my earlier mail.
https://lists.freedesktop.org/archives/nice/2016-October/001337.html

On 14 December 2016 at 23:22, Anand Sivaram <aspnair at gmail.com> wrote:

> Dear All,
>
> Recently I sent a mail to the list as follows,
> https://mail.google.com/mail/u/0/#search/libnice/157e2552c238622e
> and reported an issue based on Olivier's suggestion.
> https://phabricator.freedesktop.org/T7600
>
> I have done quite a bit of analysis to find out how things work with
> different versions of libnice and these are my finding.
>
>
> Application used:
> ================
> Modified simple_example code to reproduce the issue with the
> following change
>
> 1) Using nice_agent_add_local_address() only the specified
> local interface is chosen.  This is used because I could only
> include eth0 IP address and filter out eth1 IP address.
>
> 2) Updated print_local_data() so that I could print a combination
> of host/srflx/relay candidates. That way only candidates I am
> interested in are getting printed and I need to only copy/paste
> them to the peer.
>
>
> Setup Used:
> ==========
> 1) Using two separate Internet connection from two separate ISPs,
> connected a normal home WiFi router in each of them.
> These routers have Port Restricted Cone NAT
>
> 2) Two Debian PCs connected to each of these routers using their eth0
> interface.
>
> 3) One of these PCs have a second ethernet eth1 which is connected
> to the other network.  I could filter out this interace using
> nice_agent_add_local_address() as given above.
> This way I could ssh/copy/paste between these two PCs easily.
>
> 4) I am mainly interested in using the srflx candidates generated
> in each peers.
>
>
> Main Finding:
> ============
> 1) I went from 0.1.13-15-ga2e25cf to 0.1.13-155-g2803a0b
> (tip of the master branch), did a kind of binary search between
> these two versions.  Found that until 0.1.13-85-g0a6c779
> it was fine and between 0.1.13-86-g1ab9d7c and 0.1.13-131-gdc1e1b7
> it was getting connected but one way data and from 0.1.13-132-g71f7ed3
> to 0.1.13-155-g2803a0b, it was not getting connected at all properly.
>
> 2) That was the example application.  For my actual
> application I reverted back to libnice 0.1.13-15-ga2e25cf
> and audio/video are working now across different networks.
>
> 3) These finding are only when I used/forced srflx candidates between
> the peers.  If I forced to use host and relay candidates, there
> were no problems in any of these versions.
>
>
> Observation Summary:
> ===================
>
> 0.1.13-155-g2803a0b
> to
> 0.1.13-132-g71f7ed3
> Normally the command prompt is supposed to be seen after copy/paste
> of candidates list between each client.
> But *no* command prompt is seen in these.
> Looks like ICE connection was not successful.
>
> 0.1.13-131-gdc1e1b7
> to
> 0.1.13-86-g1ab9d7c
> Command prompt appears after getting connected as ICE gets connected.
> Only controlling(master) could send to controlled(slave)
> but not in the opposite direction.
>
> 0.1.13-85-g0a6c779
> to
> 0.1.13-15-ga2e25cf
> worked, tried many times to confirm it.
>
> Thanks and Regards
>
> Anand
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/nice/attachments/20161214/3366ff1d/attachment.html>