I guess you are using an Office 365 subscription with Skype for Business, i.e. a cloud setup. I personally have never been able to get any V&V connection work with my account either; any attempts are always failing with 486 or 488 error. As far as I understand the developer(s) maintaining the SIPE media stuff do not use SfB but older or non-cloud Lync setups.
Furthermore V&V failures are most likely not caused by SIPE. Correct operation requires up-to-date versions of nice, farstream, purple and gstreamer plus that all necessary features are implemented and working in those packages too. Debug logs from SIPE alone are not enough to debug such issues.
Because of the above reasons I'm leaning towards changing this report to be a feature request or close it, because it can't be fixed by changes in SIPE. But I leave that decision up to the media developers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Attached are two debug logs. One calling from SIPE to Windows SfB client (rejected with 488), one to Android SfB client (rejeced immediaely with 486, remote party didn't see any call window).
hello, same problem here. I got the line "Unsupported session description" and the 488 error from ubuntu 16.04 with pidgin-sipe 1.20.1 (apt-get version).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 the foundation as :
Foundation: An arbitrary string that is the same for two candidates
that have the same type, base IP address, protocol (UDP, TCP>,
etc.), and STUN or TURN server. If any of these are different,
then the foundation will be different.
And we get candidates like this (same foundation, different IP) :
a=candidate:10 1 UDP 519045631 52.112.7.33 59847 typ relay raddr 192.168.2.106 rport 39113
a=candidate:10 2 UDP 519045630 52.112.7.17 54443 typ relay raddr 192.168.2.106 rport 48006
I need to investigate why this is happening, but a first look seems to indicate
the bug is coming from libnice.
Youness has created three commits in libnice master on 2017-11-28 which are supposed to address the connectivity problem, and to give them a try you'll have to build the yet unreleased libnice code yourself. (I don't have this issue with our company's SfB servers, and thus can't test the fix.)
Since this is something that must be tackled outside SIPE code, feel free to close the ticket.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Jakub. I've update the package on my system to 0.1.14-70-gfb2f1f7 from libnice git repository.
The problem doesn't seem to be fixed. Can you verify from the log if those changes had any effects? Some of the alternate server changes are behind runtime flags, so maybe they weren't activate in my setup?
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:
From the log I can't tell whether it's libnice who sends us candidates twice or if SIPE duplicates them somewhere further down the line. Please make a new log with current git head, which now has more extesive logging.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
50017 is a regular host port, but 50013 comes from this:
(Pidgin:22457): libnice-DEBUG: Agent 0x556ca4283ac0: Adding UPnP port 192.168.122.1:50013
So it looks like UPnP support in libnice is broken, giving us candidates conflicting with regular STUN discovery. This would also explain why I'm not seeing any duplicates in my own logs as I don't have UPnP enabled in my router.
I guess the easiest way to check it is for you to rebuild libnice without UPnP (pass --disable-gupnp to configure). If it helps, I can let SIPE turn UPnP off programatically for now when creating a call.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SIPE now drops duplicates from the candidate list. With this change in place I have been able to make audio calls to a SfB client on a colleagues Android phone.
PLEASE NOTE: my tests were only successful after I updated my system to libnice-0.1.14 plus the following 3 upstream patches:
UPDATE it looks like that 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).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 if you're using "cloud" Skype for Business from Office 365 you absolutely need the libnice HEAD (and the attached patch is recommended). In other cases it depends whether your company SfB uses alternate TURN servers.
I guess you are using an Office 365 subscription with Skype for Business, i.e. a cloud setup. I personally have never been able to get any V&V connection work with my account either; any attempts are always failing with 486 or 488 error. As far as I understand the developer(s) maintaining the SIPE media stuff do not use SfB but older or non-cloud Lync setups.
Furthermore V&V failures are most likely not caused by SIPE. Correct operation requires up-to-date versions of nice, farstream, purple and gstreamer plus that all necessary features are implemented and working in those packages too. Debug logs from SIPE alone are not enough to debug such issues.
Because of the above reasons I'm leaning towards changing this report to be a feature request or close it, because it can't be fixed by changes in SIPE. But I leave that decision up to the media developers.
"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.
Attached are two debug logs. One calling from SIPE to Windows SfB client (rejected with 488), one to Android SfB client (rejeced immediaely with 486, remote party didn't see any call window).
The diagnostic for the 488 error is:
hello, same problem here. I got the line "Unsupported session description" and the 488 error from ubuntu 16.04 with pidgin-sipe 1.20.1 (apt-get version).
Stefan's logs show the same issues with srflx and UDP candidate IP addresses that Youness Alaoui (libnice contributor) was analyzing recently:
Youness has created three commits in libnice master on 2017-11-28 which are supposed to address the connectivity problem, and to give them a try you'll have to build the yet unreleased libnice code yourself. (I don't have this issue with our company's SfB servers, and thus can't test the fix.)
Since this is something that must be tackled outside SIPE code, feel free to close the ticket.
Thanks Jakub. I've update the package on my system to 0.1.14-70-gfb2f1f7 from libnice git repository.
The problem doesn't seem to be fixed. Can you verify from the log if those changes had any effects? Some of the alternate server changes are behind runtime flags, so maybe they weren't activate in my setup?
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:
From the log I can't tell whether it's libnice who sends us candidates twice or if SIPE duplicates them somewhere further down the line. Please make a new log with current git head, which now has more extesive logging.
Here you go...
As far as I can tell the duplicates are passed up from farstream:
Last edit: Stefan Becker 2018-01-29
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).
I applied that one additional patch and still see duplicates.
EDIT attached debug log following instructions from github tieto/sipe
Last edit: Stefan Becker 2018-01-30
Hmm, libnice gives us two server reflexive candidate pairs with the same foundation which differ only in base port:
50017 is a regular host port, but 50013 comes from this:
So it looks like UPnP support in libnice is broken, giving us candidates conflicting with regular STUN discovery. This would also explain why I'm not seeing any duplicates in my own logs as I don't have UPnP enabled in my router.
I guess the easiest way to check it is for you to rebuild libnice without UPnP (pass --disable-gupnp to configure). If it helps, I can let SIPE turn UPnP off programatically for now when creating a call.
I disabled the UPNP support in libnice (also visible in the log), but unfortunately the duplicates are still there and the call ends in 488 error.
Workaround implemented in git commit 50f63c7d.
SIPE now drops duplicates from the candidate list. With this change in place I have been able to make audio calls to a SfB client on a colleagues Android phone.
PLEASE NOTE: my tests were only successful after I updated my system to libnice-0.1.14 plus the following 3 upstream patches:
Closing as FIXED.
UPDATE it looks like that 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).
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.
More precisely if you're using "cloud" Skype for Business from Office 365 you absolutely need the libnice HEAD (and the attached patch is recommended). In other cases it depends whether your company SfB uses alternate TURN servers.
The bug and proposed patch in libnice Phabricator: https://phabricator.freedesktop.org/T7923
Thanks Jakub. I can confirm that with the proposed fix the duplicates are gone.