<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Please note the first link is not correct, this was my earlier mail. <a href="https://lists.freedesktop.org/archives/nice/2016-October/001337.html">https://lists.freedesktop.org/archives/nice/2016-October/001337.html</a> </div></div><div class="gmail_extra"> <div class="gmail_quote">On 14 December 2016 at 23:22, Anand Sivaram <<a href="mailto:aspnair@gmail.com" target="_blank">aspnair@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Dear All, Recently I sent a mail to the list as follows, <a href="https://mail.google.com/mail/u/0/#search/libnice/157e2552c238622e" target="_blank">https://mail.google.com/mail/u/0/#search/libnice/157e2552c238622e</a> and reported an issue based on Olivier's suggestion. <a href="https://phabricator.freedesktop.org/T7600" target="_blank">https://phabricator.freedesktop.org/T7600</a> 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 </div></div> </blockquote></div> </div>