-
Notifications
You must be signed in to change notification settings - Fork 24
Daily blurbs
If you're not feeling adventurous and instead of testing the very latest Pidgin and Sipe would prefer just infrequent verified updates, you can try new sipe-collab stable PPA.
Only fixes for serious bugs will go to the stable PPA, and new features will appear only after spending enough time in regular PPA, whose operation remains unchanged. Every release of a package into stable PPA will also have its release notes and a changelog, something we have been missing up to now.
Stable PPA is available only on Ubuntu 16.04 LTS.
If you already use sipe-collab PPA and would like to switch to stable, I recommend uninstalling your present packages and removing the original PPA from your repository list first:
sudo apt-get purge libnice10 pidgin-data remmina-common libwinpr2 gir1.2-gplugin-0.0 libgplugin0
sudo apt-add-repository --remove ppa:sipe-collab/ppa
Then you can proceed with adding the stable PPA and installing the packages again:
sudo apt-add-repository ppa:sipe-collab/stable
sudo apt-get update
sudo apt-get install pidgin-sipe pidgin
A new package repository for Debian 8 (Jessie) is available since today on openSUSE Build Service. To add the repo as root:
wget -O- http://download.opensuse.org/repositories/home:/xhaakon:/sipe/Debian_8.0/Release.key | apt-key add -
echo "deb http://download.opensuse.org/repositories/home:/xhaakon:/sipe/Debian_8.0/ ./" > /etc/apt/sources.list.d/obs-sipe.list
and then
apt-get update
apt-get install pidgin pidgin-sipe
Issues preventing screen sharing with Skype for Business should be solved, including previously mentioned backward compatibility break in libnice. Updated packages are just being built on Launchpad.
There is #67 which still remains open, but it happens only under known conditions when Pidgin is handing presenter role to SfB client. Thus, it shouldn't be too limiting in the meantime before fix is devised.
- Analyzing media compatibility with Skype for Business (UCCAPI/16.0.4339.1000 OC/16.0.4351.1000)
- calling
- audio works both ways
- Pidgin can see video from SfB, opposite direction still doesn't work
- noticed that when SfB is the call initiator, its camera image sometimes freezes for the whole duration of the call
- applicationsharing
- sharing desktop from Pidgin works
- SfB added new media stream which apparently contains the screencast as H264 video. Sipe has to ignore this stream in order to continue using RDP.
- it appears SfB no longer supports legacy FINGERPRINT calculation using custom CRC lookup table as described in [MS-ICE2] 3.1.4.8.2; switch to ordinary CRC table needs to be implemented in libnice. This breaks backward compatibility with previous versions of libnice (and that means also Sipe and Pidgin). [MS-ICE2] describes a compatibility mode which is not yet implemented in libnice.
- calling
-
Sipe
-
Pidgin
-
GStreamer plugins base upstream
-
Sipe upstream
-
Farstream upstream
-
Pidgin upstream
-
Refurbished Voice/Video settings tab in Pidgin preferences has been deployed to sipe-collab PPA. It has a simplified interface with just a single 'Device' combo box for each audio/video input/output. If you have e.g. a USB headset in addition to your PC sound card or multiple webcams, you can now also select which device you want to use during the call. This functionality was previously lost with Pidgin's transition to GStreamer 1.0.
The combo boxes are dynamic and should update automatically when new device is plugged in.
Under the hood the settings tab employs GstDeviceMonitor to receive the available devices and detect when a device is added or removed.
-
Sipe upstream (filetransfer fixes)
-
Rework of Pidgin media device selection (continuation)
- Fixed problem from yesterday with glimagesink always creating new output window
- GStreamer upstream ticket https://bugzilla.gnome.org/show_bug.cgi?id=764947
- deployed in PPA; should improve experience when running Sipe in a VM
- Began looking into output video quality issues and how to remove workarounds in Pidgin's media pipeline.
- Pidgin upstream
- libnice upstream
- investigating issue with video rendering using glimagesink picked through autovideosink which causes weird behavior when Pidgin is running in QEMU VM.
- Replied on review of my older libnice patch, some minor refactoring was needed.
- Got in touch with company's responsible Lync support team, described our TURN problem. Somebody will look into the server logs.
- Was preparing outgoing FT Sipe patches for upstream inclusion.
- Implementing peer info exchange RTCP extension from MS-RTP discovered in Wireshark dumps. Sending that piece of information in our sender reports should order remote participants (like incoming RDP session) to use less bandwidth in order to comply with limitations on our relay-allocated TCP port.
- Public holiday.
-
What we know about the TURN (Edge Server) data disconnections
- it most probably has to do with bandwidth limitations imposed on the relay connections
- only some relays actively drop the connections that overuse the bandwidth; if more servers are available in a single Lync deployment, it may be possible for the users to work around the issue by redirecting their traffic only to those that don't do the data accounting (a line in /etc/hosts may be enough, will have to test this in our network once Niklas creates a test conference in the federated company environ.)
- by a combination of a value of BANDWIDTH parameter in TURN allocate request and active limiting of traffic on the Sipe client by means of token bucket algorithm I was able to get outgoing file transfer up to ~250KiB/s which seems to be similar to what speeds Lync client is able to achieve through the same relay. Application sharing is still a problem though, I think mainly because the sharing quality is set too high and thus also more bandwidth is needed. By simple fiddling with the settings I so far wasn't able to make FreeRDP use lower data rate.
-
What can be done
- extend libnice with a proper implementation of some algorithm for control of the traffic flow (token bucket, ...); this should allow file transfers through relays
- expose BANDWIDTH parameter from TURN allocate response in libnice, farstream and Pidgin API so that the application is notified when TURN server wants to impose some bandwidth usage restrictions on the connection; we want to switch the token bucket algorithm on only when it's necessary, not during e.g. pc2pc desktop sharing.
- no fix for desktop sharing is readily available so far. Users might be able to route their media traffic to a different server (needs testing).
-
Big update of PPA
- Farstream
- GPlugin
- FreeRDP
I have dropped patches which where applied upstream from their respective packages.
-
Initial support for incoming video is now available in PPA Sipe.
- absolutely needs the latest Farstream
- only PC2PC calls were tested and supported so far.
- picture quality is not stellar, but seems on par with Lync peer to peer video
- there are still pending issues with Pidgin media pipeline. I had to remove several elements that were causing the media flow to hang, but I don't undertand why they started causing trouble.
- OpenGL and VA-API outputs don't work very well; set "X Window System" or "X Window System (Xv)" in Voice/Video Pidgin preferences instead
-
Pidgin upstream
-
Sipe upstream
-
Pidgin upstream
-
Debugging and cleanup of incoming video support in Sipe
-
Fix XVideo rendering in Pidgin 3
In order to enable client shadow decorations, GtkDialog from GTK+ 3.0 uses ARGB visual which by default gets inherited by its child widgets. XVideo adaptors on the other hand often support just depth 24 and rendering video through xvimagesink onto a widget inside a GtkDialog then results in no visible output. The patch ensures the default system visual of the drawing area doesn't get overridden by the widget's parent.
- Implemented MS-RTP VSR. Sipe sends the request and Lync starts sending video.
- Trouble with capability negotiation on codec bin pads; Pidgin GStreamer pipeline hangs; needs more investigation.
-
Incoming video - implementing MS-RTP Video Source Request (continuation)
-
Trouble attaching host USB webcam into QEMU (libvirt) Windows 7 guest
Solution:
- VM USB controller model must be USB3
- in the VM install this driver
- Incoming video
- assessment of Farstream and GStreamer source codes in order to find the best way to implement Video Source Request from [MS-RTP]. We'll subclass FsRtpConference and connect to "on-sending-rtcp" signal of its internal RTP sessions. Inside the handler we can append extra application-specific RTCP messages.
- preparations for Farstream update in the PPA once VSR is implemented.
-
Conference disconnections when traffic is routed via TURN relay
Implemented couple of missing MS-TURN attributes in libnice, but to no avail. We found out the issue is not specific to application sharing and shows also during file transfers through a relay. This will allow us to capture network traffic from both sending and receiving side and its comparison may give us more clues as to what's wrong. Giving up for now and focusing on video; investigation will continue sometime next week.
-
Debugging conference desktop disconnects with Ove
I think we've narrowed down the possible culprit to MS AV relay server. Pidgin connects to relay (usually port 443) and requests allocation of a port on that server which other parties then can use to communicate with our client. Conferencing server correctly discovers the route through the relay and starts using it for sending and receiving RDP data, however it seems the relay shortly after that shuts down the port we have allocated, making it seem to us that we're still connected and able to send data, but no RDP traffic is coming.
This behavior probably applies only to certain versions of relay server software. We've tried some servers that are available in our companies and some are reliable and never drop the connection, whereas other would always disconnect us after a short while. There must be some new properties in MS-TURN protocol we're not using in Sipe which affect the lifetime of allocated server port. [MS-TURN] describes some attributes I'm going to experiment with tomorrow, before finally moving to video.
- libnice
- fix NULL dereference in nice_socket_is_base_of() and nice_socket_is_reliable()
- responded to upstream review of https://phabricator.freedesktop.org/D785
- Again looking at "appshare terminated with ms-diagnostics-public: 31"
- found out it's possible to trigger the response by stopping Pidgin in debugger for a couple of seconds while remote desktop is being displayed, so the meaning of the message isn't probably anything more elaborate than "generic timeout"
- Wireshark dump shows TCP connection is kept in established state all the time, Pidgin closes it with FIN only after BYE with "ms-diagnostic 31" is received from Lync server
- conferencing server simply stops sending us RDP data at some point with no apparent reason; we still can send data to server through the open connection
- TURN messages and TCP framing of RDP data looks correct, no noticeable data corruption during transfer which could cause that server stops talking to us
-
Re-iterate recent libnice patches with upstream maintainers
- unfortunately how they modified my change doesn't fix the problem at all
- I commented with even more thorough explanation, hopefully we'll finally come to an understanding this time
- https://phabricator.freedesktop.org/D785
-
Continued analysing Ove's conference disconnection problem from earlier
- not much can be googled about ms-diagnostics-public: 31;reason="Call terminated on a mid-call media failure where one endpoint is of unknown type", happens sometimes with 3rd party media hardware but no solution was ever found but replacing that gadget.
- Possible causes:
- libnice writing garbage into output data stream (STUN message mixed into RDP data?)
- libnice incorrectly extracting incoming RDP data from network frames (truncate/add extra bytes)
- FreeRDP bug (likely not, protocol error would show in remmina log and our RDP client would disconnect first, which isn't the case)
- RTCP messages not being sent?
- probably has something to do with the fact TURN relays are involved (host-host connections don't disconnect like this).
- Analyzing problem with audio connectivity to conferencing server in both inter- and intra-net
- libnice behaving strangely again, RTP and RTCP components picking different routes; debugging and packet sniffing whole day
- so far without conclusive result, will continue tomorrow.
- Reviewed Bernhard's Freerdp2 Debian package; small fixes contributed as pull requests; complete FreeRDP update in PPA.
- Struggle with scheduling conference on customer server, wild test of a meeting across federated Lync environments, many crashes.
-
Fixed Ove's bug where it wasn't possible to connect to a conference call using a meeting link:
-
Updated official Debian pidgin-sipe package to 1.20.1; waiting for sponsored upload
-
Pidgin pull requests:
Fixes are deployed in the PPA. Since GNOME Keyring integration is working now, users are advised to switch to this password store instead of Pidgin internal storage, which saves plaintext secrets in
~/.purple
. See Pidgin settings in Tools > Preferences > Password Storage. -
Analysis of conference connection failure due to invalid meeting link sent by Ove
Turns out HTML document Sipe downloads from the Lync meeting URL not always contains required focus URI and Stefan has removed the fallback method which used to guess the focus URI from meeting URL, because it could fail with an error message which was unhelpful to the user. Still, it seems we may be able to download HTML from URL stored in
domainOwnerJoinLauncherUrl
JavaScript variable in the original document and find focus URI there. Implementation of the corresponding changes is in progress.
- Analysis of hang and 100% CPU utilization on Pidgin shutdown
- Gnome keyring plugin, which fails to initialize, is the culprit.
- This buggy plugin subsequently exposes another bug in libpurple plugin system which sends Pidgin into infinite loop in
purple_plugin_unload()
when there's some plugin in failed state. - Design of the fix is in progress. PPA has a preliminary workaround applied, but it still doesn't handle the situation when Gnome keyring is installed and not enabled.
- Moving to an office on a different floor (2 hours).
- Fixed occasional assert failure when opening remote desktop share.
- Patches are eligible and prepared for Sipe upstream inclusion after a bit of testing in the PPA.
- Attempted to reproduce Rick's Pidgin UI hang during audio+appshare conference call, but still to no avail. More logs requested.
- Synchronized freerdp2 PPA packages with updates from Bernhard.
- Finished FreeRDP2 transition in sipe-collab PPA, fixed dependency issues between packages on update.
- Sipe & Remmina now use a single set of FreeRDP libraries and we build our own Remmina (from the source code of remmina-next).
- Proposal for the separate FreeRDP shadow subsystem library PR #3150 was merged upstream. pkg-config and header file changes are still being discussed.
- Fixed Pidgin UI freeze during desktop shares introduced in one of the recent commits
- Rick still reports some problems, might show only during multiuser conferences. I'll have to test myself.
- Sync with Niklas.
- Checked preliminary FreeRDP 2.0 Debian package by Miklautz
- Pull requests fixing some discovered problems:
- Turns out upstream has decoupled shadow server core from subsystem implementations, unwittingly preventing us from linking libsipe.so to libfreerdp-shadow.so, because required symbol X11_ShadowSubsystemEntry has moved directly into freerdp-shadow-cli binary. Thus, I have created a pull request asking to create a subsystem library we could link to.
- Update of FreeRDP packages in PPA is still in progress.
- Copied remmina-next packages into sipe-collab PPA
- except version for Ubuntu Vivid which I'll have to rebuild because it's not available in remmina-next.
- Analysis and development of fixes for failed assertion in Issue #19
- to be tested and deployed tomorrow.
- Ove is testing 14.04 installation of Sipe + Remmina from sipe-collab.
-
Tested desktop sharing using Remmina with Ove into 14.04.
There's a bug in Remmina which crops the contents of large desktops to the size of your screen (the rest of the image is visible only as black border on the right and the bottom). Fix exists upstream and there is PPA with prebuilt packages, so if you have this issue,
sudo add-apt-repository ppa:remmina-ppa-team/remmina-next
and install remmina and remmina-plugin-rdp from there (for us it worked everywhere, even in a VM). I'm going to copy the packages to sipe-collab and make pidgin-sipe depend on them so that patched remmina is installed by default.Found and fixed Sipe crash when huge amounts of data are being poured from Sipe to the RDP client.
- Worked on replacing xfreerdp with remmina in order to get a nice scaling and scrolling desktop view
- deployed in PPA
- works in 15.04, but in 14.04 I've seen only black screen. Pinged Ove to re-test in his 14.04. We might need a fallback mechanism to xfreerdp for ancient distros.
- Discussed with Niklas about application sharing, XMPP and Jingle.
- I should have a look at https://github.com/bmiklautz/debian-freerdp2 which is going to be the next official freerdp in Debian anc check if it ain't broken.
-
Two new patches for libnice that should address the relay issue (already in PPA):
Four lines of code worth of day and a half debugging.
Pinged Ove to also re-test his screen sharing issue as it might be because of this bug.
-
Tested call, filetransfer, and appshare with aforementioned changes. Tried scenario with Pidgin accessing Lync behind an Edge Server from the internet.
- Establishing connection through relay server seems reliable
- Sharing my desktop is somewhat laggy, Pidgin uses over 100% CPU at times
- Couldn't establish a call to the Lync Test Call Bot from then internet. Data flow is unobstructed because I can hear the bot and my record being played back, but libnice doesn't signal established connection and Sipe times out the call after 30 s. Works inside corporate network, same as pc2pc calls from the internet. Strange.
- Experienced libnice segfault in nice_socket_is_reliable(). Similar issue is reported and has a comment from Philip Withnall (libnice upstream) how to fix, but the ticket has been stale since November. Seems I shall step in and finish the work.
-
Rebased our Sipe patches on top of current Sipe upstream
-
Trying to figure out the missing relay candidate issue knees deep in libnice. It seems libnice doesn't take into account that there can be multiple allocate requests to the same TURN server (for instance when you have multiple local host IPs - and if you use VPN or have some virtual machines you most probably have). As soon as first relay candidate pair is discovered, further allocate responses start being treated as having RFC4571 framing, their headers get removed and thus they are not recognized and thrown off.
Wrote a fix, need to better test it tomorrow.
-
Turns out nice_socket_is_base_of() was wrong all along. The fact that it worked until I tried to use it in a different context makes me a tad uneasy. Features that need TCP (filetransfer, appshare) will need a through testing after both libnice fixes (missing relay and is_base_of) are in place.
-
Contemplating about replacing xfreerdp with Remmina, which would give scaling and scrollbars to the remote display window with likely little effort.
-
Sipe upstream
- fix dnsquery memory leak
- fix build on hppa architecture (as reported from Debian)
-
Updated PPA pidgin 3.x package to latest upstream hg default branch
-
Started investigating missing TCP TURN relay candidate issue.
Often there are only host TCP candidates present in Sipe SDP media negotiation. This makes desktop shares and file transfers impossible when clients can't establish a direct connection (e.g. intranet/internet scenario with edge server; also appears in Ove's debug logs).
Why no relay candidates are gathered is still uncertain, same as why it doesn't happen every time (suspect a bug/incomplete implementation in libnice). Relay server IP and port detection is correct, pseudo-SSL TCP connection succeeds and initial exchange of port allocation requests happens as well. It must go wrong somewhere further down the line. This article is useful to the topic.