Jakub Adam

If your SfB admins have assigned a phone number to your account, you can call mobiles and landlines from Pidgin as well: select Accounts -> your SfB account -> Call a phone number... and type in the number in the international format (starting with '+' and the country code). I've just tried to ring my phone for the first time in many months and the call went through fine.

The bug and proposed patch in libnice Phabricator: https://phabricator.freedesktop.org/T7923

I got access to an Office 365 account and could finally reproduce the candidate duplication myself. It seems the issue was caused by one of the libnice changes that implement the ALTERNATE_SERVER mechanism. If anyone wants to try I attached a patch (not yet upstream) that should prevent the bogus candidates form being generated. to be able to successfully call a SfB client running on Windows you'll need to fast forward libnice from 0.1.14 all the way to current HEAD (git commit fb2f1f7). More precisely...

Hmm, libnice gives us two server reflexive candidate pairs with the same foundation which differ only in base port: (14:32:35) sipe: 22 2 1 845415166 62.121.61.82 50017 1 192.168.122.1 50017 (14:32:35) sipe: 22 1 1 845415167 62.121.61.82 50013 1 192.168.122.1 50013 (14:32:35) sipe: 22 2 1 845415166 62.121.61.82 50017 1 192.168.122.1 50017 (14:32:35) sipe: 22 1 1 845415167 62.121.61.82 50013 1 192.168.122.1 50013 50017 is a regular host port, but 50013 comes from this: (Pidgin:22457): libnice-DEBUG:...

So the duplicates come already from Farstream/libnice... I see Youness has one more pending libnice merge request for this commit, but it looks like a fix for something else. With all the patches applied locally I don't get any candidate duplicates in SIPE (and without them as well).

The patches seem to have fixed the wrong candidate IPs, but I see another problem with the candidate list. Some pairs (all srflx) are duplicated in the SDP message: a=candidate:11 1 TCP-ACT 845808127 86.60.143.206 50006 typ srflx raddr 192.168.122.1 rport 50006 a=candidate:11 1 TCP-ACT 845808127 86.60.143.206 50006 typ srflx raddr 192.168.122.1 rport 50006 a=candidate:11 2 TCP-ACT 845808127 86.60.143.206 50006 typ srflx raddr 192.168.122.1 rport 50006 a=candidate:11 2 TCP-ACT 845808127 86.60.143.206...

Stefan's logs show the same issues with srflx and UDP candidate IP addresses that Youness Alaoui (libnice contributor) was analyzing recently: The first thing I noticed, is that the srvflx IP is actually the relay IP, not the external IP, and that the relay UDP candidates have a different IP address for component 1 and component 2. In theory, components 1 and 2 should share the same IP address (but different ports) for the same foundation, so that's probably what the real issue is. The RFC defines...

"488 Not Acceptable Here" may also mean the Skype client doesn't recognize the format of our SDP message, but the posted log doesn't include any message bodies to analyze. To obtain the full log please run Pidgin with PURPLE_UNSAFE_DEBUG=1 as described here.