Re: [Telepathy] Unearthy sound using telepathy-call
Hi, That element no longer exists in recent versions of gst-libav, but it shouldn't matter for this, as it is for the video pipeline. The second warning potentially denotes something more problematic. Sadly, Empathy is currently looking for a maintainer, so don't expect a quick fix.. Olivier On Thu, 2018-08-23 at 12:40 +0200, Johannes Winter wrote: > Hello everybody, > > I'm running empathy with telepathy-rakia on latest debian sid and > like > to use my fritzbox router for making SIP calls. > > Calling works, but sound quality is far beyond acceptable, only > grunting > sounds arrive at the other side. > > Looking at the system messages they show these maybe related errors: > > > Aug 23 12:30:21 radell empathy-call[3336]: Element factory > "postproc_tmpnoise" not found. > > Aug 23 12:30:21 radellempathy-call[3336]: Failed to add > "postproc_tmpnoise" (gst-ffmpeg missing?) > > Aug 23 12:30:22 radell empathy-call[3336]: > gst_structure_remove_field: > assertion 'IS_MUTABLE (structure)' failed > > > Maybe it's related to debians move from gst-ffmpeg to gst-libav? > > Best regards, > > Johannes Winter > ___ > telepathy mailing list > telepathy@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/telepathy -- Olivier Crête olivier.cr...@collabora.com signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Telepathy Release process?
Hi, I believe the most active maintenance of Telepathy is now at https://github.com/TelepathyIM Olivier On Fri, 2017-11-03 at 10:35 -0700, Diane Trout wrote: > Hi, > > Anyone still around who can handle doing releases? > > There's a request for a new release of telepathy-idle > > https://bugs.freedesktop.org/show_bug.cgi?id=94189 > > And Polari is actually maintained and reasonably well liked. > > (Also Hi team members, I'm starting to have time again. In case you > didn't know young children are ridiculous amounts of work). > > Diane > ___ > telepathy mailing list > telepathy@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/telepathy -- Olivier Crête olivier.cr...@collabora.com signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] status of empathy and XMPP in telepathy
Hi, On Sat, 2016-06-04 at 11:21 -0700, Diane Trout wrote: > As far as I can tell farstream only uses stun_usage_bind_create from > libnice, I didn't see anything about TURN. > > Though it does look like libnice has TURN support. If you use the libnice transmitter of Farstream, you get full TURN support. You just need to set the relevant properties when selecting the transmitter. The TURN settings are in the RelayInfo property on Stream.Interface.Media: https://telepathy.freedesktop.org/spec/Call_Stream_Interface_Media.html #Property:RelayInfo The relevant code in telepathy-farstream: https://cgit.freedesktop.org/telepathy/telepathy-farstream/tree/telepat hy-farstream/stream.c#n940 -- Olivier Crête olivier.cr...@collabora.com ___ telepathy mailing list telepathy@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] merging patches into telepathy-gabble
Hi, Telepathy, in particular gabble and tp-glib, are definitely in need a new maintainership, if you want to become the maintainer, I don't think there would be much opposition. Olivier On Wed, 2015-12-23 at 11:00 -0800, Diane Trout wrote: > Hello, > > I was looking through some of the bugs on the freedesktop bug tracker > and saw > that there's patches for telepathy-gabble to add Stream Management > (XEP-0198) > and message carbons (XEP-0280) > > What can we do to get these patches finished and merged? It seems > like the > current maintainers have disappeared. > > Stream Management > https://bugs.freedesktop.org/show_bug.cgi?id=46700 > > Message Carbons > https://bugs.freedesktop.org/show_bug.cgi?id=78093 > > Both patches need unit tests, I feel like the stream management patch > is a bit > closer in style to the rest of wocky, but I need to read more of the > wocky > source to be sure. > > However I went ahead and built a version of telepathy-gabble with > the github > repository linked to from 46700 and am currently testing it. > > Diane > ___ > telepathy mailing list > telepathy@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/telepathy -- Olivier Crête olivier.cr...@collabora.com ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Empathy port to ARM architecture (Ubuntu Touch)?
Hi, Empathy is the client for GNOME, so it's really focused on the GNOME desktop. The fact that the Ubuntu people use it is mostly historical. If you want to write a new IM client, you should just start from scratch based on either Telepathy or even better, just on libpurple directly. That said, old fashioned IM has mostly disappeared for regular people and the replacement protocols, Facebook, Skype, Hangouts, etc, are not suitable for the kind of APIs that were developed a decade ago like libpurple or Telepathy. Old protocols were based on carrying messages, while newer ones are mostly a view on a "mailbox" which is stored on the server so you can keep your conversation across devices and the web. Also, the large majority of real users are now using closed garden systems, making open clients much more painful to develop as everything needs to be reverse-engineered. Olivier On Tue, 2015-09-22 at 19:39 +0200, Peter Bittner wrote: > Is it possible to use most of Empathy's logic, and plugin-in a > QML-powered user interface on it? > > A bit like the Fahrplan developers did it at > https://github.com/smurfy/fahrplan/tree/master/src/gui? (I understand > that the difference technology-wise may be larger than in that > project.) > > If convergence is going to happen on the Ubuntu platform a > "responsive" Empathy implementation will be needed anyway. Could be > good to kick this off now. A clean separation would also allow to > implement a 100% web-based HTML5 Empathy client. Wouldn't that be > nice, too? > > Peter > > > 2015-09-22 19:30 GMT+02:00 Olivier Crête <olivier.cr...@collabora.com > >: > > Hello, > > > > Empathy works fine on ARM, but it is a desktop application, so you > > need > > to be running a regular desktop environment. The Ubuntu Touch > > platform > > is a completely different platform requiring custom applications > > for > > everything. > > > > > > On Tue, 2015-09-22 at 00:39 +0200, Peter Bittner wrote: > > > Are there any plans to port Empathy the ARM architecture, so that > > > it > > > would be installable on Ubuntu Touch mobile phones? > > > > > > Peter -- Olivier Crête olivier.cr...@collabora.com ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Empathy port to ARM architecture (Ubuntu Touch)?
Hello, Empathy works fine on ARM, but it is a desktop application, so you need to be running a regular desktop environment. The Ubuntu Touch platform is a completely different platform requiring custom applications for everything. On Tue, 2015-09-22 at 00:39 +0200, Peter Bittner wrote: > Are there any plans to port Empathy the ARM architecture, so that it > would be installable on Ubuntu Touch mobile phones? > > Peter > ___ > telepathy mailing list > telepathy@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/telepathy -- Olivier Crête olivier.cr...@collabora.com ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Make Google Hangouts voice and video chat work (Ubuntu 14.04)
Hello, Google Hangouts is not using standard XMPP Jingle signalling, but a variant that does the call over a chat room, so they can do multi-party calls. This variant is not publicly documented and so was never implemented in any telepathy CM. The best clients for Hangouts are Firefox and Chrome ;) Olivier On Mon, 2015-09-21 at 23:40 +0200, Peter Bittner wrote: > I've got an Ubuntu 14.04.3 LTS box running Empathy 3.8.6, and I've > got > a Google (apps) account configured. > > According to the documentation [1] voice and video chat should work > with Google, provided GTalk corresponds Hangouts today. I've checked > the installed codecs, and the ones listed in the docs [1] are > installed. > > Now, I do have Voice Call and Video Call in the user's context menu, > but for most users these options are grayed out. Not sure why: One > contact I called today was using their Google (Hangouts) account on a > Windows box and Psi messenger, another one is using their Google apps > account (i.e. custom domain, as I do) and is online now with Empathy. > (Interestingly, the former has the two options grayed out again now > that the account is set to "Away". Strange!) > > Is there any specific rule to when voice and video chat is available? > Peter > > [1] https://wiki.gnome.org/Apps/Empathy/FAQ#Audio_and_Video_calls > ___ > telepathy mailing list > telepathy@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/telepathy -- Olivier Crête olivier.cr...@collabora.com ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Empathy port to ARM architecture (Ubuntu Touch)?
Hi, Collabora also wrote a QML based Telepathy UI for the long defunct Meego Tablet project, there may be some code that can be re-usd from there. https://github.com/meego-tablet-ux/meego-app-im Olivier On Tue, 2015-09-22 at 13:52 -0400, Jonathan Frederickson wrote: > Ubuntu Touch's built-in messaging client is based on Telepathy, but > it can currently only send and receive SMS and MMS > messages. I'm not sure, but Canonical's plan may be to extend this > client so that it's a more general Telepathy client > and making its UI responsive - essentially, replacing Empathy for > their desktop. > > - Jon F. > > On 9/22/15 1:39 PM, Peter Bittner wrote: > > Is it possible to use most of Empathy's logic, and plugin-in a > > QML-powered user interface on it? > > > > A bit like the Fahrplan developers did it at > > https://github.com/smurfy/fahrplan/tree/master/src/gui? (I > > understand > > that the difference technology-wise may be larger than in that > > project.) > > > > If convergence is going to happen on the Ubuntu platform a > > "responsive" Empathy implementation will be needed anyway. Could be > > good to kick this off now. A clean separation would also allow to > > implement a 100% web-based HTML5 Empathy client. Wouldn't that be > > nice, too? > > > > Peter > > > > > > 2015-09-22 19:30 GMT+02:00 Olivier Crête < > > olivier.cr...@collabora.com>: > > > Hello, > > > > > > Empathy works fine on ARM, but it is a desktop application, so > > > you need > > > to be running a regular desktop environment. The Ubuntu Touch > > > platform > > > is a completely different platform requiring custom applications > > > for > > > everything. > > > > > > > > > On Tue, 2015-09-22 at 00:39 +0200, Peter Bittner wrote: > > > > Are there any plans to port Empathy the ARM architecture, so > > > > that it > > > > would be installable on Ubuntu Touch mobile phones? > > > > > > > > Peter > > _______ > > telepathy mailing list > > telepathy@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/telepathy > > ___ > telepathy mailing list > telepathy@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/telepathy -- Olivier Crête olivier.cr...@collabora.com ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] TURN servers in Empathy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/01/15 08:51 AM, Dominik George wrote: Hi, The best first step would probably be to make the TURN relay hostname, port, username and password configurable as parameters in src/protocol.c, the same way the STUN server hostname/port and HTTPS proxy hostname/port are currently configurable, […] I'd even say the existing stun-server parameters could simply be reused and the UI element be relabled as STUN/TURN-Server. At least, I cannot see any reason why the STUN server should be different from the TURN relay, and other clients (including Jitsi) do that as well. Except that for a TURN server, you need to pass the username and password too. Otherwise it's mostly the same. Technically, the servers could be split, but as all relevant TURN server implementations also do STUN and there is no reason to disable that, I think it is a very safe bet. All TURN servers are also STUN servers, so it's definitely very valid to only supply a TURN server. The annoying part is that you have to pass the TURN server config through telepathy-gabble. TURN servers should really be proposed by the XMPP server, but it seems that no one else than Google went through the effort of designing something that actually works. The Telepathy-Farstream Farstream part should already support it, so all the work is in Gabble and in Empathy. - -- Olivier Crête olivier.cr...@collabora.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEAREIAAYFAlTGbNcACgkQHTiOWk7Zorv1cgCeKBfERBl+3Z0+C5h7x4YFnB+h t9sAnjIdGg4Vgf3O8e8LnLlBHF4G3uoI =ocvb -END PGP SIGNATURE- ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] TURN servers in Empathy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/01/15 09:00 AM, Dominik George wrote: If the peer (the other person in the call) proposes a relay server candidate, again, that candidate will be used if higher-priority direct connections fail; so if you are not using a Google account, but your friend is, then your data might end up going through a Google server. This also implies that any relay candidate proposed by the other party will be used, even if this is a private TURN relay; so the task at hand to make Telepathy propose available TURN relays as well. Normally, only one party has to have a TURN server for the connection to work. So if the other party proposes TURN candidates, you can connect to it as if it was the other side's client and you've won. You could even be using two separate TURN servers, for example, if you're in a corporate network and your only way out is a HTTP or a SOCKS proxy, then you need to be using a TURN server to get out. So in that case, you need your own. It's pretty much the only case. - -- Olivier Crête olivier.cr...@collabora.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEAREIAAYFAlTGbZ0ACgkQHTiOWk7ZorvAugCfek1ppnF/lsXqqjq2SOE8uUNS ku8An2IWAQOCpm28L21Py9TKilkoBhFw =LJTL -END PGP SIGNATURE- ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] TURN servers in Empathy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/01/15 11:46 AM, Dominik George wrote: 1. STUN and TURN servers can be published throush XEP-0215; this also allows the use of temporary credentials. Jitsi and Prosody already support that, and I personally think it is a valid solution; I also agree, but I don't think any XMPP server deploys that seriously? XEP-215 had been on the todo list for a while, but the lack of deployed servres always kept it a low priority. 2. the XMPP Wiki suggests that it is a valid solution to look for _turn SRV records via DNS. That ignore the fact that you need to give it a username/password. - -- Olivier Crête olivier.cr...@collabora.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEAREIAAYFAlTGcwAACgkQHTiOWk7ZorsxNgCdHhkA2iOmuTH5IxLYOMPp/TzN flcAnAgnVjMnfJzdA+d2xiiREn6ae0QM =S8Yh -END PGP SIGNATURE- ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] choosing Telepathy versions for GNOME 3.12
On Wed, 2014-03-19 at 13:37 +, Simon McVittie wrote: * merge my port to GDBus, or decide not to Merge it already! Go Simon go! ;) -- Olivier Crête olivier.cr...@collabora.com ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-farstream 0.6.1
This is a bug fix release, all distributions should import it. - Fix build with newer telepathy-glib branches - Fix build with automake 1.13 - Improve configure.ac with AS_IF - Fix calls with standard ICE-UDP (against Gajim) tarball: http://telepathy.freedesktop.org/releases/telepathy-farstream/telepathy-farstream-0.6.1.tar.gz signature: http://telepathy.freedesktop.org/releases/telepathy-farstream/telepathy-farstream-0.6.1.tar.gz.asc git: http://cgit.freedesktop.org/telepathy/telepathy-farstream -- Olivier Crête olivier.cr...@collabora.com signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Folks status, the addressbook problem
On Tue, 2012-10-30 at 15:40 +0100, Xavier Claessens wrote: Folks DB Folks is about merging Personas, so I suggest having a separate DB that does just that. I think being able to sync the merging between multiple machines/devices is important. If I understand correctly, storing it in the vcard in EDS achieves that (I can put it in Google Contacts). Having a separate database breaks that property. -- Olivier Crête olivier.cr...@collabora.com signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Stable-branches for use with GNOME 3.6
On Tue, 2012-09-18 at 08:32 +0200, Guillaume Desmottes wrote: Le lundi 17 septembre 2012 à 15:28 +0100, Simon McVittie a écrit : telepathy-farstream 0.4.0 is still current for everyone who uses Farstream 0.1 and GStreamer 0.x. Do we want a 0.6.0 for use in conjunction with Farstream 0.2 and GStreamer 1.0, or are we just going to recommend 0.5.0 for those who live on the edge? GStreamer 1.0 support is going to be experimental in Empathy 3.6 (not enabled by default) so I don't think it's worth having a stable tp-fs for this. I'll be making a 0.6.0 release of tp-fs for those using GStreamer 1.0, as it's the new stable release of GStreamer. I don't see why you want to make the GStreamer 1.0 support be experimental, I understand GNOME 3.6 will depend on GStreamer 1.0 anyway? -- Olivier Crête olivier.cr...@collabora.com signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-farstream 0.5.0
This is the first release of an hopefully very short unstable branch. The main change is that it now uses Farstream 0.2 which mean GStreamer 1.0. Changes: - Port to GStreamer 1.0 and Farstream 0.2 - Set RemoteContact when accepting updating media descriptions tarball: http://telepathy.freedesktop.org/releases/telepathy-farstream/telepathy-farstream-0.5.0.tar.gz signature: http://telepathy.freedesktop.org/releases/telepathy-farstream/telepathy-farstream-0.5.0.tar.gz.asc git: http://cgit.freedesktop.org/telepathy/telepathy-farstream -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Migrating to telepathy-farstream
Hi, On Wed, 2012-06-20 at 10:27 +0200, Victor Paléologue wrote: I am migrating from telepathy-farsight to telepathy-farstream, but I have some problems after the stream (the TfContent) was added. In my callback, I still connect to src-pad-added event and I do not connect to any of the events of the old TfStream, but I didn't change anything else yet. You may want to connect to the start/stop-sending/receiving signals to start your source and sinks at the right time. In this configuration, I get this error message: tp-fs-Message: tf_stream_error: stream error errorno=7 error=add_remote_candidate not defined in stream transmitter class; and telepathy-gabble crashes. This is strange, do you have a log of your application, dbus-monitor and telepathy-gabble ? And Gabble should definitely not crash. Is there something obvious I did wrong? Is it important to connect the other signals of the TfContent? Are there any guidelines somewhere for migrating from farsight to farstream? You need to connect fs-conference-added of TfChannel and add the FsConference objects to your pipeline at that point. I can't find any updated documentation on how to do things with telepathy-farstream... http://telepathy.freedesktop.org/doc/telepathy-farstream/ -- Olivier Crête olivier.cr...@collabora.com signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] ANNOUNCE: telepathy-rakia 0.7.4
Hi On Mon, 2012-05-14 at 11:43 -0400, Mystilleef wrote: 1) For outgoing calls, calling TpCallChannel.accept transitions the channel's state from Pending_Initiator to Initialised. How do I get the channel's state to Accepted and Active? The docs say rakia is supposed to do this automatically after the accept method is called. So far, I'm having no luck. I'm using telepathy-rakia-0.7.4 on Fedora rawhide. For outgoing calls, it goes to ACCEPTED/ACTIVE when the other side accepts the call. This is probably related to the next problem as it won't send the request to the other side before getting the local codecs and candidates. 2) The Farstream TfChannel created from TpCallChannel does not emit signals for media streaming. In particular, fs- conference-added and content-added do not get emitted. I'm not sure if this is related to issue 1 or if this is a bug. This is strange... Look at the output of dbus-monitor maybe... -- Olivier Crête olivier.cr...@collabora.com signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] ANNOUNCE: telepathy-rakia 0.7.4
Hi, For the media part, the telepathy-farstream code is the same, but for the client part, you have to request a Call1 channel instead of a StreamedMedia channel. And so you have to use different APIs there. The new Call1 API should be much easier to use, no need to mess around with the Group interface for example. Olivier Mystilleef mystill...@gmail.com wrote: With regards to using the new Call API, do I need to adjust my code with telepathy-farstream, or will my old code just work fine? On Tue, May 8, 2012 at 8:03 PM, Brian Pepple bpep...@fedoraproject.org wrote: On Tue, 2012-05-08 at 13:07 -0400, Olivier Crête wrote: Telepathy-Rakia development release 0.7.4, the Call Me Maybe release, is now available. If you are using GNOME 3.4, please ship this release, as calls will not work with older releases. But be aware that there is one remaining problem, sometimes SIP servers stop forwarding call to us. I am unable to reproduce it with any SIP server that is under my control, so I don't know what happens, any help is appreciated. Does tp-rakia have a component to file bugs against at freedesktop.org? Looks like the latest release has a DSO Linking bug that causes the build to fail. Here's a snippet from the build log. snip /usr/bin/ld: ./.libs/librakia-convenience.a(call-stream.o): undefined reference to symbol 'g_inet_address_new_from_string' /usr/bin/ld: note: 'g_inet_address_new_from_string' is defined in DSO /lib64/libgio-2.0.so.0 so try adding it to the linker command line /lib64/libgio-2.0.so.0: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[3]: *** [telepathy-rakia] Error 1 make[3]: *** Waiting for unfinished jobs /usr/bin/ld: ./.libs/librakia-convenience.a(call-stream.o): undefined reference to symbol 'g_inet_address_new_from_string' /usr/bin/ld: note: 'g_inet_address_new_from_string' is defined in DSO /lib64/libgio-2.0.so.0 so try adding it to the linker command line /lib64/libgio-2.0.so.0: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status /snip If I have a little free time tomorrow, I'll see if I can whip up a quick patch to fix this. Later, /B -- Brian Pepple bpep...@fedoraproject.org https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-rakia 0.7.4
Telepathy-Rakia development release 0.7.4, the Call Me Maybe release, is now available. If you are using GNOME 3.4, please ship this release, as calls will not work with older releases. But be aware that there is one remaining problem, sometimes SIP servers stop forwarding call to us. I am unable to reproduce it with any SIP server that is under my control, so I don't know what happens, any help is appreciated. New in this release: - The StreamedMedia Channel type has been replaced by Call1 Tarball: http://telepathy.freedesktop.org/releases/telepathy-rakia/telepathy-rakia-0.7.3.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-rakia/telepathy-rakia-0.7.3.tar.gz.asc Git: http://cgit.freedesktop.org/telepathy/telepathy-rakia/log/?id=telepathy-rakia-0.7.4 -- Olivier Crête olivier.cr...@collabora.com Collabora signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Does SIP work with the new Farstream
Hi, The Rakia call branch has not been merged and released yet. In the short term, you can use the old streamed media with telepathy-farstream, just give it the streamed media channel and it should just work. You can also try the Call branch of Rakia that is available at http://cgit.collabora.com/git/user/tester/telepathy-rakia.git/log/?h=call and please report any problems that you find. We plan on merging and releasing it soon. Olivier On Sun, 2012-04-29 at 22:59 -0400, Mystilleef wrote: Nevermind, after a reboot, everything works again. Weird. On Sun, Apr 29, 2012 at 6:30 PM, Mystilleef mystill...@gmail.com wrote: Hello, I decided, very reluctantly, to port my sip client to telepathy-farstream yesterday because fedora was whining about telepathy-farsight being obsolete. After hours of trial and error, it finally worked! Today, after a reboot, the client fails to connect to the server. Then I release the new telepathy modules may be using the new Call APIs. I tested Empathy to see if it could connect to the SIP server. It couldn't. So has anyone successfully made calls using SIP with the new Farstream/Call APIs? I've also noticed that telepathy-rakia just randomly exits (crashes?). Here's rakia's debug log: http://pastebin.com/CZbYgKjs Here are the relevant packages I have installed Installed Packages Name: telepathy-farstream Arch: i686 Version : 0.4.0 Release : 2.fc18 Size: 190 k Repo: installed From repo : rawhide Summary : Telepathy client library to handle Call channels URL : http://telepathy.freedesktop.org/wiki/Telepathy-Farsight License : LGPLv2+ Description : telepathy-farstream is a Telepathy client library that uses Farstream to handle : Call channels. Name: telepathy-glib Arch: i686 Version : 0.18.1 Release : 1.fc18 Size: 2.4 M Repo: installed From repo : rawhide Summary : GLib bindings for Telepathy URL : http://telepathy.freedesktop.org/wiki/FrontPage License : LGPLv2+ Description : Telepathy-glib is the glib bindings for the telepathy unified framework : for all forms of real time conversations, including instant messaging, IRC, : voice calls and video calls. Name: telepathy-rakia Arch: i686 Version : 0.7.3 Release : 2.fc17 Size: 224 k Repo: installed From repo : rawhide Summary : SIP connection manager for Telepathy URL : http://telepathy.freedesktop.org/wiki/Components License : LGPLv2+ Description : telepathy-rakia is a SIP connection manager for the Telepathy : framework based on the SofiaSIP-stack. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy -- Olivier Crête olivier.cr...@collabora.com signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-farstream 0.2.3
A stabilisation release - Fix various bugs - Improve debug messages - Improve GI annotations - Use the generic marshallers tarball: http://telepathy.freedesktop.org/releases/telepathy-farstream/telepathy-farstream-0.2.3.tar.gz signature: http://telepathy.freedesktop.org/releases/telepathy-farstream/telepathy-farstream-0.2.3.tar.gz.asc git: http://cgit.freedesktop.org/telepathy/telepathy-farstream -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-farstream 0.2.2
The 2012 International Women's Day release - Allow an Endpoint to be removed so as it work with Rakia call transfers - Ignore port 2.26 deprecations - Added a tf_channel_new_finish() function - Misc bug fixes tarball: http://telepathy.freedesktop.org/releases/telepathy-farstream/telepathy-farstream-0.2.2.tar.gz signature: http://telepathy.freedesktop.org/releases/telepathy-farstream/telepathy-farstream-0.2.2.tar.gz.asc git: http://cgit.freedesktop.org/telepathy/telepathy-farstream -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-farstream 0.2.1
- Now use Call1 as well as Streamed Media - Now requires Farstream and telepathy-glib 0.17.5 tarball: http://telepathy.freedesktop.org/releases/telepathy-farstream/telepathy-farstream-0.2.1.tar.gz signature: http://telepathy.freedesktop.org/releases/telepathy-farstream/telepathy-farstream-0.2.1.tar.gz.asc git: http://cgit.freedesktop.org/telepathy/telepathy-farstream -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] tpfarsight (Python) and GObject Introspection Incompatibilities
Hi, On Wed, 2011-08-24 at 08:55 +0200, Tomeu Vizoso wrote: On Wed, Aug 24, 2011 at 08:35, Mystilleef mystill...@gmail.com wrote: Hello, My application suddenly stopped working after an upgrade. So I spent the better part of today trying to figure out why. It turns out the latest version of gobject-introspection is very strict and doesn't allow mixing non-introspectable python bindings with introspectable ones. Fortunately, my app runs its tpfarsight streamer in its own process. So it was easy to revert to using old school python bindings for gobject. To cut the long story short. I think the python bindings for telepathy-farsight and or farsight wouldn't work with the latest PyGI and gobject-introspection. Is this a known issue? Should I file a bug report? I'm not maintainer of those modules, but I think that if you think the bug is in those, you should put it in bugzilla. If you think the problem lies in pygobject or gobject-introspection, use bugzilla.gnome.org instead. I maintain the python bindings for farsight and tp-fs, the reason they're not using gi yet is that GStreamer isn't and probably won't be before 1.0. -- Olivier Crête olivier.cr...@collabora.com signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] tpfarsight (Python) and GObject Introspection Incompatibilities
On Wed, 2011-08-24 at 10:52 -0400, Mystilleef wrote: 2011/8/24 Olivier Crête olivier.cr...@collabora.com: Hi, On Wed, 2011-08-24 at 08:55 +0200, Tomeu Vizoso wrote: On Wed, Aug 24, 2011 at 08:35, Mystilleef mystill...@gmail.com wrote: Hello, My application suddenly stopped working after an upgrade. So I spent the better part of today trying to figure out why. It turns out the latest version of gobject-introspection is very strict and doesn't allow mixing non-introspectable python bindings with introspectable ones. Fortunately, my app runs its tpfarsight streamer in its own process. So it was easy to revert to using old school python bindings for gobject. To cut the long story short. I think the python bindings for telepathy-farsight and or farsight wouldn't work with the latest PyGI and gobject-introspection. Is this a known issue? Should I file a bug report? I'm not maintainer of those modules, but I think that if you think the bug is in those, you should put it in bugzilla. If you think the problem lies in pygobject or gobject-introspection, use bugzilla.gnome.org instead. I maintain the python bindings for farsight and tp-fs, the reason they're not using gi yet is that GStreamer isn't and probably won't be before 1.0. Cool! I think they might have started to use gi. A look at dir(gi.repository.Gst) shows many of the most important elements are available. How well they work is a completely different story. I'll test it out later when I have time. Except that I think important bits like the buffers, events and queries are not covered (because they're GstMiniObjects which are not GObjects). -- Olivier Crête olivier.cr...@collabora.com signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] tpfarsight (Python) and GObject Introspection Incompatibilities
On Wed, 2011-08-24 at 17:39 +0200, Tomeu Vizoso wrote: 2011/8/24 Mystilleef mystill...@gmail.com: 2011/8/24 Olivier Crête olivier.cr...@collabora.com: On Wed, 2011-08-24 at 10:52 -0400, Mystilleef wrote: 2011/8/24 Olivier Crête olivier.cr...@collabora.com: Hi, On Wed, 2011-08-24 at 08:55 +0200, Tomeu Vizoso wrote: On Wed, Aug 24, 2011 at 08:35, Mystilleef mystill...@gmail.com wrote: Hello, My application suddenly stopped working after an upgrade. So I spent the better part of today trying to figure out why. It turns out the latest version of gobject-introspection is very strict and doesn't allow mixing non-introspectable python bindings with introspectable ones. Fortunately, my app runs its tpfarsight streamer in its own process. So it was easy to revert to using old school python bindings for gobject. To cut the long story short. I think the python bindings for telepathy-farsight and or farsight wouldn't work with the latest PyGI and gobject-introspection. Is this a known issue? Should I file a bug report? I'm not maintainer of those modules, but I think that if you think the bug is in those, you should put it in bugzilla. If you think the problem lies in pygobject or gobject-introspection, use bugzilla.gnome.org instead. I maintain the python bindings for farsight and tp-fs, the reason they're not using gi yet is that GStreamer isn't and probably won't be before 1.0. Cool! I think they might have started to use gi. A look at dir(gi.repository.Gst) shows many of the most important elements are available. How well they work is a completely different story. I'll test it out later when I have time. Except that I think important bits like the buffers, events and queries are not covered (because they're GstMiniObjects which are not GObjects). Aha, I didn't catch that. But it may be a good moment to start developing against 0.11 (will be 1.0) and reporting issues. Many of the plugins are still not ported -- Olivier Crête olivier.cr...@collabora.com signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] gst.LinkError in Telepathy Farsight
Hi, On Fri, 2011-06-17 at 18:04 -0400, Mystilleef wrote: On Fri, Jun 17, 2011 at 5:51 PM, Tiago Katcipis katci...@inf.ufsc.br wrote: def __stream_created_cb(self, channel, stream): print Start of stream created! stream.connect(src-pad-added, self.__src_pad_added_cb) srcpad = stream.get_property (sink-pad) from gst import element_factory_make, STATE_PLAYING src = element_factory_make(audiotestsrc) src.get_pad(src).link(srcpad) src.set_property(is-live, True) src.set_state(STATE_PLAYING) self.__pipeline.add(src) here it seems to be the problem, self.__pipeline.add(src) and src.set_state(STATE_PLAYING) should be called before you call src.get_pad(src).link(srcpad). You can link pads of elements that belong to the same pipeline (bin) and are on the same state. I think you're right. I also had to set STATE_PLAYING in an idle handler. You don't have to change the state in a idle handler, it should matter. -- Olivier Crête olivier.cr...@collabora.com signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] gst.LinkError in Telepathy Farsight
You want to do it in this order: def __stream_created_cb(self, channel, stream): print Start of stream created! stream.connect(src-pad-added, self.__src_pad_added_cb) srcpad = stream.get_property (sink-pad) from gst import element_factory_make, STATE_PLAYING src = element_factory_make(audiotestsrc) src.set_property(is-live, True) self.__pipeline.add(src) src.get_pad(src).link(srcpad) src.set_state(STATE_PLAYING) On Fri, 2011-06-17 at 18:35 -0400, Mystilleef wrote: 2011/6/17 Olivier Crête olivier.cr...@collabora.com: Hi, On Fri, 2011-06-17 at 18:04 -0400, Mystilleef wrote: On Fri, Jun 17, 2011 at 5:51 PM, Tiago Katcipis katci...@inf.ufsc.br wrote: def __stream_created_cb(self, channel, stream): print Start of stream created! stream.connect(src-pad-added, self.__src_pad_added_cb) srcpad = stream.get_property (sink-pad) from gst import element_factory_make, STATE_PLAYING src = element_factory_make(audiotestsrc) src.get_pad(src).link(srcpad) src.set_property(is-live, True) src.set_state(STATE_PLAYING) self.__pipeline.add(src) here it seems to be the problem, self.__pipeline.add(src) and src.set_state(STATE_PLAYING) should be called before you call src.get_pad(src).link(srcpad). You can link pads of elements that belong to the same pipeline (bin) and are on the same state. I think you're right. I also had to set STATE_PLAYING in an idle handler. You don't have to change the state in a idle handler, it should matter. It crashes with the following error if I don't put it in an idle handler === (run:14061): GStreamer-CRITICAL **: Trying to dispose element autoaudiosrc0, but it is in PLAYING instead of the NULL state. You need to explicitly set elements to the NULL state before dropping the final reference, to allow them to clean up. This problem may also be caused by a refcounting bug in the application or some element. (run:14061): tp-fs-DEBUG: stream 0 0xa25b020 (audio) _tf_stream_bus_message: Codecs changed (run:14061): tp-fs-DEBUG: stream 0 0xa25b020 (audio) _tf_stream_try_sending_codecs: called (send_local:0 send_supported:0) (run:14061): tp-fs-DEBUG: stream 0 0xa25b020 (audio) _tf_stream_try_sending_codecs: 0: audio PCMU clock:8000 channels:0 (run:14061): tp-fs-DEBUG: stream 0 0xa25b020 (audio) _tf_stream_try_sending_codecs: 101: audio telephone-event clock:8000 channels:0 events=0-15 (run:14061): tp-fs-DEBUG: stream 0 0xa25b020 (audio) _tf_stream_bus_message: Send codec changed: 0: audio PCMU clock:8000 channels:0 params:(nil) fish: Job 1, “./run ” terminated by signal SIGSEGV (Address boundary error) == -- Olivier Crête olivier.cr...@collabora.com signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] gst.LinkError in Telepathy Farsight
If you get a segfault from python code, it means there is a bug in the C code somewhere.. Can you post the smallest possible example that crashes somewhere ? Btw, this belongs on the gstreamer mailing list Olivier On Fri, 2011-06-17 at 18:48 -0400, Mystilleef wrote: 2011/6/17 Olivier Crête olivier.cr...@collabora.com: You want to do it in this order: def __stream_created_cb(self, channel, stream): print Start of stream created! stream.connect(src-pad-added, self.__src_pad_added_cb) srcpad = stream.get_property (sink-pad) from gst import element_factory_make, STATE_PLAYING src = element_factory_make(audiotestsrc) src.set_property(is-live, True) self.__pipeline.add(src) src.get_pad(src).link(srcpad) src.set_state(STATE_PLAYING) Still crashes. I spent all morning trying different orders. It crashes or gives me a gst.LinkError, if the state is not put in an idle handler. The only thing that solved it for me is putting the state in the idle handler. -- Olivier Crête olivier.cr...@collabora.com signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-farsight 0.0.19
Please wait, please wait sir, I'll update you when needed Tarball: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.19.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.19.tar.gz.asc - Set the default RTP extension preferences in the right order - Added a block-ready property to be able to delay accepting the call until some condition has been met - Only call CodecsUpdated() if codecs that actually need to be transmitted has been changed Also requires Farsight2 0.0.29 -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] empathy video call resolution
On Sat, 2011-05-21 at 20:20 +0400, Timur Davletshin wrote: 1. I just wondering if there any way to configure video call resolution or it's just hardwired somewhere? No, currently it's hard coded. Although I'm working on a way to set it dynamically according to the network bandwidth, etc. 2. I see in codec-preferences file line with promised VP8 codec support but gst-inspect-0.10 | grep rtp gives me no rtp de/payloader component. Does it exist or it's just my distribution fault? The codec-preferences are just preferences.. The VP8 RTP pay/depayloaders are only in the newest version of gst-plugins-bad as the standard is not yet completed. -- Olivier Crête olivier.cr...@collabora.com signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-farsight 0.0.18
With extra feedback Tarball: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.18.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.18.tar.gz.asc - Add support for FeedbackMessages and RtpHeaderExtensions - Set the default codec preferences from farsight2, can still be overriden with the stream-get-config signal or during the stream-added signal handler - Set the default RTP Header extensions from farsight2, can be overridden during the stream-added signal Also requires Farsight2 0.0.28 and telepathy-glib 0.14.3 -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Abusing FileTransfer.URI
On Fri, 2011-05-06 at 10:38 +1000, Danielle Madeley wrote: Thoughts? Update the Telepathy API in a clean way.. -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-farsight 0.0.17
Tarball: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.17.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.17.tar.gz.asc - Implement StartSoundTelephonyEvent and StartNamedTelephonyEvent - Fix leak with Supported + Update - Use g_error_matches - Ignore NotImplemented errors for optional methods - Don't link against libpython -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] change speexenc settings for empathy
Hi, On Fri, 2011-04-08 at 17:19 +0200, Alexey Fisher wrote: vbr=1 # enable variable bitrate This may not work so well if you are near the limit of what the network can do.. Sine you'll get drops when the bitrate gets higher... dtx=1 # do not send any packets on silence # see Bug https://bugzilla.gnome.org/show_bug.cgi?id=646474 This gives you the impression that the bitrate is lower because you don't send why not speaking. But it doesn't change the maximum bitrate (when speaking) which is all that really matters for quality.. It will also break if WMM is enabled, in that case, the wireless router only sends out frames when it receives one, so you have to send continuously to keep on receiving. nframes=4 # allow better compression and bigger packet size. It reduce network # traffic to 13 packets/sec. (with default options ~50 packets/sec). # the value bigger than 4 will introduce stuttering. This will increase latency, but should definitely improve compression. But it gives less leeway to the jitterbuffer to do its thing. Maybe we can increase to 2 which is already 40ms.. 4 is 80ms which is way too much (the default jb is 100ms in Empathy). -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] change speexenc settings for empathy
On Fri, 2011-04-08 at 17:57 +0200, Alexey Fisher wrote: Hi Am Freitag, den 08.04.2011, 11:42 -0400 schrieb Olivier Crête: dtx=1 # do not send any packets on silence # see Bug https://bugzilla.gnome.org/show_bug.cgi?id=646474 This gives you the impression that the bitrate is lower because you don't send why not speaking. But it doesn't change the maximum bitrate (when speaking) which is all that really matters for quality.. It will also break if WMM is enabled, in that case, the wireless router only sends out frames when it receives one, so you have to send continuously to keep on receiving. My fault in description. It send about 2 packets/sec to keep connection. That's not enough.. You won't get incoming packets unless you send outgoing packets.. so if you send 2 packets per second, it means you only get incoming packets twice per second, which will destroy your audio. Unless someone tells me there is a reliable way to temporarily disable WMM from an application, DTX is not usable with WiFi networks. nframes=4 # allow better compression and bigger packet size. It reduce network # traffic to 13 packets/sec. (with default options ~50 packets/sec). # the value bigger than 4 will introduce stuttering. This will increase latency, but should definitely improve compression. But it gives less leeway to the jitterbuffer to do its thing. Maybe we can increase to 2 which is already 40ms.. 4 is 80ms which is way too much (the default jb is 100ms in Empathy). I'll try it. Are there any way to change the settings for empathy? I tryed to add speexenc in element-properties file, but it looks like without any effect. That should be all. -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] StreamedMedia/Call spec ambiguities
On Mon, 2011-04-04 at 21:59 -0400, Youness Alaoui wrote: On 04/04/2011 10:57 AM, mikhail.zabal...@nokia.com wrote: -Original Message- Following IRC discussion, let me condense the current issues with StreamedMedia and its Gabble implementation into a few bullet points: - Is the direction of a stream in a StreamedMedia channel a valid concept unless the Stream is in state Connected? Specifying that a CM should emit StreamDirectionChanged with actual direction (if different from the assumed Receive/PendingLocalSend) before signaling the stream as Connected could be a useful cop-out for clients who are not requesting the streams and only receive the signals. - What should the direction be reported as for a freshly requested stream for which we don't yet know if the remote user accepts to send on, or even can send? Telepathy-Rakia should return the stream with direction Receive and the Pending_Remote_Send flag. What Gabble does is probably bong, ignored by all clients because they really listen for StreamHandler signals. I might be wrong here, but from what Olivier told me, although it is not specified in any way in the spec, StreamedMedia direction when the call starts is used to represent the maximum direction. So Gabble setting it to BOTH, means that the protocol supports that the call may be sending, receiving or sending+receiving... eventually. In the case of MSN for example, where there are different audio/video call protocols that can be used, there is a unidirectional protocol for webcam, and that initial direction would be used to specify to the UI/user whether to show that the contact wants to send his webcam or contact wants to receive your webcam or contact wants to start a video chat. At least, that's what Olivier told me, he also said that it's not specified anywhere in the spec, but that's what he was told the CM implementations should do. Someone else probably needs to confirm though. Hope it sheds some light on the matter (although it might generate the opposite effect :) ). If I'm not mistaken, that's the direction in the SessionHandler.NewStreamHandler() signal, not the one in StreamedMedia.. In my experience, clients should call RequestStreamDirection with whatever they want and the listen for StreamDirectionChanged and then re-call RequestStreamDirection until they get what they want. That's the only way I'm sure works with every CM. -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Video call with GTalk
On Tue, 2011-03-29 at 08:53 +0800, flower bean wrote: Do I need to rely on telepathy-stream-engine? No, but them you must re-implement the Gst bits that it has into your own app. -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Video call with GTalk
On Mon, 2011-03-28 at 10:41 +0800, flower bean wrote: Hello, I use telepathy-qt4 to implement video call with GTalk protocal. I'm not sure if I need to launch camera by myself, if yes, does it use the API org.maemo.Telepathy.StreamEngine.StartCamera()? I have called org.maemo.Telepathy.StreamEngine.AttachToChannel, do I also need to call StartCamera/VideoPreviewSize etc. separatly ? I assume you're on Maemo5 (stream-engine is only for Maemo). You don't have to call StartCamera(), its only there if you want to start the camera before the call actually starts (like the Maemo5 default UI does). VideoOutputSize and VideoPreviewSize are signals that tell the UI what resolution the output/preview is so the UI can put its output window at the right ratio. That said, be careful, I'm not sure how will it will interact with the official UI if you use stream-engine. -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] The telepathy-reviewers mailing list.
On Fri, 2011-03-25 at 16:34 +, Will Thompson wrote: Hi folks, I'd like to propose a few people for commit access as per the WIP procedure at http://telepathy.freedesktop.org/wiki/Committers (which is based on WebKit's). That page says that Telepathy reviewers are defined to be the set of people on the telepathy-reviewers mailing list, which is currently rather anaemic: http://lists.freedesktop.org/mailman/roster/telepathy-reviewers. Are we okay with having a Grand Unified List of Reviewers for all Telepathy components hosted on freedesktop.org, just as commit access is all-or-nothing? Obviously people on the list should exercise their own judgement as to whether they're able to give patches in particular areas of different projects the thumbs-up. Thoughts? I don't think it's a good idea to have random people review stuff for random modules. Since our modules are relatively small, I think there should be a owner/maintainer for each module so we have a minimum of accountability. Also, the maintainer should always have an overview of the changes to his module, so that he can maintain a good level of consistency Also, some modules (like tp-farsight/farstream) require specialized knowledge so in practice only one or two people could review them anyway. -- Olivier Crête olivier.cr...@collabora.co.uk signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] empathy h264?
On Fri, 2011-03-18 at 14:52 +0100, Nicola De Filippo wrote: Hi, i attach meego empathy debug. It doesn't find the H.264 codec. Can you run gst-inspect-0.10 rtph264pay gst-inspect-0.10 rtph264depay gst-inspect-0.10 x264enc gst-inspect-0.10 ffdec_h264 And if any of these fails, you're missing some required bits. That said, maybe we should implement something custom that call gst-missing-plugins to install the H.264 stuff for Google. -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Telepathy farstream started
Added to the todo list at http://farsight.freedesktop.org/wiki/ApiBreak On Tue, 2011-02-01 at 18:32 +, mikhail.zabal...@nokia.com wrote: Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Sjoerd Simons Sent: Tuesday, February 01, 2011 7:11 PM To: telepathy Subject: [Telepathy] Telepathy farstream started Furthermore we've been planning to rename Farsight2 itself to Farstream for a while now, which Olivier promised me to do within the next two weeks. While you are at it, rename transmitters to transceivers, put them into $(libdir)/farstream-1.0/transceivers to reduce plugin file name fidgetry, and maybe match up on the Tp.Ch.Type.Call vs Farsight terminology? :) Cheers, Misha -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-farsight 0.0.16
Tarball: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.16.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.16.tar.gz.asc - Emit the NewActiveTransportPair signal - Emit CodecsUpdated more often - Various bug fixes Also, now depends on telepathy-glib 0.13.4 or later -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Encryption and OTR
On Wed, 2010-12-15 at 22:41 -0600, Reşat SABIQ wrote: Thanks Xavier. OTR=P2P encryption for messaging. A few follow-up questions: 1. Could somebody please confirm that selecting Encryption required (TLS/SSL) leads to video and audio streams being encrypted as well? No 3. Will future OTR support also include OTR (p2p) encryption for video and audio? No, encryption for calls is SRTP and is a completely separate topic. Thanks a bunch. 07.05.2010 01:29, Xavier Claessens yazğan: TLS/SSL will encrypt your messages from you to gtalk server. But gtalk server will decrypt it to send to your destination contact (and eventually re-encrypt). That means that Google can read your conversations. OTR is a p2p encryption, so only the end destination can decrypt the message, any people between you and your contact will only see encrypted data. In that case Google won't be able to read what you say. So IMO the question is: do you trust your server, if not you should use OTR, otherwise TLS/SSL is enough. tbh if you don't trust your sever, you already lost... Xavier Claessens. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy -- Olivier Crête olivier.cr...@collabora.co.uk signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] SIP Port Number
On Thu, 2010-10-14 at 18:04 +0200, Esben Stien wrote: It seems the SIP configuration dialog does not support valid URL's. I register on port 5080, not 5060. If I type in f...@bar.baz:5080, it does not contact the server. Any pointers as to what I can try? There is a separate field if you need to specify the port number, in empathy, look in advanced-proxy options -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-farsight 0.0.15
Tarball: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.15.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.15.tar.gz.asc There is a single bug fix in this release: - Release the send resource when the connection manager calls SetStreamSending(False) -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] how to specify codec and encoding/decoding pipeline for empathy?
On Mon, 2010-09-06 at 15:44 +0800, Zhao, Halley wrote: Thanks Vikram. Besides preference, I may need change the pipeline as well since my camera and encoder is a little special. Any more hint? thanks You can change the src by setting the gconf key with gstreamer-properties, the default src is gconfvideosrc I believe.. I'm not sure what else you want to do. Olivier -- Olivier Crête olivier.cr...@collabora.co.uk signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Audio codec for VoIP
Hi, I guess you're on Maemo 5 ? On this platform, you can configure the codec preferences by changing the order of the groups in in /etc/stream-engine/gstcodecs.conf Olivier On Mon, 2010-08-23 at 16:34 +0100, Cayetanot, Sebastien wrote: All, I would like to know if it's possible to set a specific codec to be used for Voice over IP ? Currently the audio channel is opened based on G729 codec. I would like to use G711 one. Regards Sebastien - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy -- Olivier Crête olivier.cr...@collabora.co.uk signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] best frame rate for video chat
On Sun, 2010-08-22 at 16:57 +0200, Alexey Fisher wrote: Most codecs and conteiners do not support dynamic frame rate, i do not know haw about h263. So probably empathy trying to stabilize frame rate to announced. If anounced 30fps and got 5fps it will upscale it to 30. This make no sense, espasially on slow CPU or to stream it in the network. Most codecs used in video calls (like H263, H264) when used with RTP don't have notion of framerate. They just send frames that have a specific timestamp. So if the camera doesn't produce buffers as fast as it claims, it just sends the buffers it has. -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Support for UPnP/DLNA
Hi, On Thu, 2010-08-05 at 15:50 +0530, Rajesh Sai T wrote: Do we have any support for UPnP in Telepathy ? If so, appreciate your help if you guys pointing me to the module that has the support. If no, is there any plans of doing so? Telepathy is a framework for real-time communication. UPnP/DNLA have nothing to do with that field. If you are looking for a free implementation of UPnP/DLNA, I suggest you look at the GuPnP project and the Rygel media server. -- Olivier Crête olivier.cr...@collabora.co.uk signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Support for UPnP/DLNA
On Thu, 2010-08-05 at 10:27 -0500, Matt Rogers wrote: 2010/8/5 Olivier Crête olivier.cr...@collabora.co.uk: Hi, On Thu, 2010-08-05 at 15:50 +0530, Rajesh Sai T wrote: Do we have any support for UPnP in Telepathy ? If so, appreciate your help if you guys pointing me to the module that has the support. If no, is there any plans of doing so? Telepathy is a framework for real-time communication. UPnP/DNLA have nothing to do with that field. If you are looking for a free implementation of UPnP/DLNA, I suggest you look at the GuPnP project and the Rygel media server. That's not necessarily true. UPnP is a framework that can be used for dynamic port forwarding with firewalls, so there is some relevance from that angle, but probably only in the connection managers. The original poster didn't even ask about DNLA so I have no idea where that came from. Yes, but that's not relevant to Telepathy. However, I should note that Farsight2 and libnice (used to make voip calls when using TP) fully supports UPnP IGB (Internet Gateway Device) to open ports etc. -- Olivier Crête olivier.cr...@collabora.co.uk signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] empathy with Microsoft Livechat LX-3000
Hi, pulsesink is actually created by empathy, not by tp-fs. That said, the streams are tagged with the application name and with the phone media role. So PA should be able to route it. Olivier On Tue, 2010-05-11 at 15:29 +0200, mikhail.zabal...@nokia.com wrote: Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext ?esa? ?ad??e ?? Sent: Tuesday, May 11, 2010 2:40 PM To: telepathy@lists.freedesktop.org Subject: [Telepathy] empathy with Microsoft Livechat LX-3000 I have two audio devides, internal and a Livechat LX-3000. how can I choose the audio device used for a SIP call? This is a very interesting question. If PulseAudio is in use, telepathy-farsight could tag PA streams with something that Empathy (or possibly the central mixer application) could route to the correct device. Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Webcam resolution limits
On Fri, 2010-05-07 at 10:01 +0200, Guillaume Desmottes wrote: Le vendredi 07 mai 2010 à 00:12 -0500, Reşat SABIQ a écrit : Hi again, I haven't seen anything regarding this in FAQ. But i've come across reports that A. high resolution webcams would lead to high-resolution video streams, and that webcam's (max) resolution can't be customized/reduced. Is statement A. true? If so, i guess it means that it's best to buy a webcam that would be expected to perform well at expected bandwidth. P.S. Is resolution tweaking support being planned in short, medium or long term, and are there any operational dates in this regard? Yes, there is a bug opened about that https://bugzilla.gnome.org/show_bug.cgi?id=607478 I also think that there are some plans to automatically adjust the framerate depending on the available bandwidth. The Farsight guys should be able to tell you more about that. Currently empathy forces the resolution to be 320x240, but I do plan to do dynamic bitrate/framerate/resolution scaling in the not so distant future. -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Feature request: make it clearer when there are new, hidden messages
Hi, Imho, if the view was at the botton, it should auto-scroll, but not otherwise.. I wrote some code in GnomeICU to do exactly that 7 years ago.. On Mon, 2010-02-15 at 17:45 -0500, Cory Kaufman wrote: Hi, Currently if I am chatting with someone and I switch to another window, any chats they sent me are hidden and the view stays where I left it before switching. I understand the reasoning behind this (even though it differs from how most other chat apps work) because you don't get lost of the other person sends a whole bunch of messages. However: it is hard to see at a glance that there are messages I am not seeing, unless the other person has written enough to push the scrollbar up significantly. It would be really helpful if there were a clear indication that there are new messages and I can scroll down to see them. Even if it's as simple as a small overlaid message at the bottom that says There are newer messages below, scroll to see them. Thanks! Cory -- Cory Kaufman Web Developer Bright Bridge Studios (616) 516-3906 c...@brightbridge.net www.brightbridge.net ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Feature request: make it clearer when there are new, hidden messages
On Tue, 2010-02-16 at 15:34 +, Will Thompson wrote: On 16/02/10 14:54, Olivier Crête wrote: Imho, if the view was at the botton, it should auto-scroll, but not otherwise.. I wrote some code in GnomeICU to do exactly that 7 years ago.. I'm pretty sure Empathy already does that... Yes, seems like it already does it.. And it also sets the urgency hint if the window is not in the foreground, not sure how much more it could do. -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Gabble/video(-XMPP/Gmail) one way only
On Tue, 2010-01-19 at 19:34 -0500, Olivier Crête wrote: Hi, On Wed, 2010-01-20 at 00:36 +0100, Toby Mangold wrote: Hi, I'm faced with a strange behaviour in video chat. I'm getting one-way video only when trying to contact a friend on XMPP/Gmail. Audio is fine, I can see him (Gmail on Windows), but he doesn't get my video. This is a known problem. The solution is to use the git version of gst-plugins-good and the attached patch (to empathy.. well to the file which is in /usr/share/empathy). Guillaume: Btw, can we put this patch in both empathy master and in the next 2.28 release. Seems, like the spspps-interval property is now called config-interval instead. -- Olivier Crête olivier.cr...@collabora.co.uk signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Requestable and Immutable properteries (was: API sketches for encrypted channels, and OTR)
On Mon, 2010-01-04 at 13:08 +, Simon McVittie wrote: On Wed, 30 Dec 2009 at 08:35:58 +1100, Danielle Madeley wrote: This is somewhat unrelated, but do you think it's a good idea to add property flags to the spec for things like this, so that we can display this information in the top-right of the box in the spec. Something like property ... tp:flags=requestable,immutable If anything, I'd prefer ... tp:requestable=yes tp:immutable=yes/. So far we've just been using fairly consistent text (this property is immutable or change notification is via the ThingChanged signal). One advantage of always having text like that is that it will hopefully remind people that they should explicitly say what the change notification is, which might in turn remind them to implement change notification at all :-) Maybe there should be a tp:notification= attribute on the property tag and if its not there, then its immutable. That would force people to have it. -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-farsight 0.0.12
The Guillaume, I love you release. Tarball: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.12.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.12.tar.gz.asc - Fix mixup between GSlice and malloc - Fix potential race between src-pad-added and dispose - The connected state in farsight is a lie, ignore it -- Olivier Crête olivier.cr...@collabora.co.uk signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] [TELEPATHY] receiving a split second of audio on any protocol
Hi, First, you don'T need stream-engine or gst-plugins-farsight, they're not used anymore. Second, your probably is probably with pulseaudio, which version do you have? Olivier On Sat, 2009-09-26 at 16:03 -0700, Reimundo Heluani wrote: Calling from empathy to a windows or mac os X box on Gabble/SIP/butterfly. The other box can hear me without trouble but I can only hear the first word and then silence (I can hear about 0.2 seconds of each audio chat). This might be a problem with gst-plugins-farsight but I don't know how to debug it. I am attaching the debug logs of gabble and empathy, perhaps someone here can help me a little, I've spent several hours throughout this month without any luck. The setup I am running is quite the latest stable: empathy-2.28.0 farsight2-0.0.15 gst-plugins-farsight-0.12.11 gst-plugins-bad-0.10.14 gst-plugins-good-0.10.16 gst-plugins-base-0.10.24 gst-plugins-ugly-0.10.11 telepathy-butterfly-0.5.1 telepathy-farsight-0.0.11 telepathy-gabble-0.8.3 telepathy-glib-0.7.37 telepathy-haze-0.3.2 telepathy-mission-control-5.3.1 telepathy-python-0.15.11 telepathy-sofiasip-0.5.18 telepathy-stream-engine-0.5.11 ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-farsight 0.0.11
The I'm so sorry release. Tarball: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.11.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.11.tar.gz.asc - Fixes a nasty double-free introduced in the last release - Also fixes more leaks -- Olivier Crête olivier.cr...@collabora.co.uk signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] ANNOUNCE: telepathy-farsight 0.0.10
Sorry, this release has a nasty double free bug. Please ignore it, 0.0.11 will come soon. On Tue, 2009-09-08 at 21:15 -0400, Olivier Crête wrote: The No Witty Name release. Tarball: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.10.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.10.tar.gz.asc - Fix some leaks - Fix possible deadlocks - Emit different error codes depending on the error - Emit stream state changes when the stream state changes according to ICE -- Olivier Crête olivier.cr...@collabora.co.uk signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-farsight 0.0.10
The No Witty Name release. Tarball: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.10.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-farsight/telepathy-farsight-0.0.10.tar.gz.asc - Fix some leaks - Fix possible deadlocks - Emit different error codes depending on the error - Emit stream state changes when the stream state changes according to ICE -- Olivier Crête olivier.cr...@collabora.co.uk signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Thoughs on the next gen MediaSignalling interface
On Fri, 2009-05-15 at 08:46 +0200, mikhail.zabal...@nokia.com wrote: Hi, -Original Message- From: telepathy-boun...@lists.freedesktop.org [mailto:telepathy-boun...@lists.freedesktop.org] On Behalf Of ext Olivier Crête Sent: Tuesday, April 14, 2009 11:44 PM To: telepathy Subject: [Telepathy] Thoughs on the next gen MediaSignalling interface o.fd.Tp.Client.StreamedMediaHandler: Methods: AddParticipants(a(ua(sv)) an array of particpants, the asv would contain nat-traversal, relay-info, stunservers, proxies, etc RemoveParticipants(au) SetCodecs(id, Codecs) (can fail if there is no intersection) AddCandidates(id, Candidates) ForceCandidates(id, Candidates) StartTelephonyEvent(event, volume) / StopTelephonyEvent(event) SetSendCodec(Codec) SetDirection(id, direction) Properties: CurrentCodecs Properties: Transmitters Properties: RecvCodecs Signals: CurrentCodecsChanged(Codecs) Signals: NewRecvCodecs(Codecs) Signals: Error(misc) I hope this helps starting the discussion on a saner MediaSignalling API. How do I restart an ICE session with this? Excellent question, maybe with a RestartICE() call.. It seems I also forgot the local candidates... so lets add a NewLocalCandidates(candidates) and a LocalCandidatesPrepared(candidates) signal as well as a LocalCandidates property... If that makes sense? -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] Mute?
Hello, In the current draft of the XMPP jingle spec, there is a mute informational message. Currently, gabble does not send it. I think there are two possiblities, either add an explicit Mute method/interface to TP, or implicitely mute if the stream direction is changed to recv-only. Probably, we also want to add a mute signal to the interface to allow the UI to display the fact that the other side has muted. Thoughts ? -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] Hold can fail
Hello, After the recent discussion on jingle hold, I realised some things. - For the compatibility case, if the other side is an older version that does not support informational messages or the senders= hack, then the Hold interface should not be present. - If the other end is the new jingle, then the informational messages are optional and the other end could return feature-not-implemented/unsupported-info, so Hold can fail. That information should be transmitted to the UI so further actions can be taken. - In the case of SIP, the same thing could happen, if I send a direction change to none, the other side could very well reply with an inverse direction change (ie, refuse the hold), in which case we should also fail the hold (I don't know if anyone implements it this way, but I can see no reason why someone wouldn't have done it). For the last two cases, we should allow the folowing: Hold refused by other party: (Unheld, any reason) → (Pending_Hold, Requested) → (Unheld, Rejected) -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] ANNOUNCE: telepathy-farsight 0.0.6
On Tue, 2009-03-17 at 23:03 +, Frederik Himpe wrote: On Tue, 17 Mar 2009 18:29:43 -0400, Olivier Crête wrote: Small bug fix release.. Make reading of the RelayInfo property actually work. Available from: http://telepathy.freedesktop.org/releases/telepathy-farsight/ Mandriva is now using -Werror=format-security CFLAG as default. To build this with this CFLAG, I had to apply this patch: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/telepathy-farsight/current/SOURCES/telepathy-farsight-0.0.6-strfmt.patch?view=co Could you check it and apply it if it's correct? In this case, it's not really a security problem, since its already the output of printf, but oh well, I applied it anyway. -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-farsight 0.0.5
Yet another glorious release! New in this release: - Recognize ice-udp - Improve error handling - Support the new CodecsUpdated method - Support for the RelayInfo and STUNServers properties This should work great with TURN servers, h.264 and Theora! -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Just what is stream directionality?
On Fri, 2009-03-13 at 22:11 +, Sjoerd Simons wrote: You never have any guarantee that the remote side will actually send though. You can argue whether it makes sense to request the remote side to start sending immediately (apart from when the call is initiating), as it should always be something the user on the other side decides not their peer. You want to be able to tell the other end to stop sending (its called hold) and start again (unhold), but we have a specific API for that. -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Getting relay info from Telepathy to Farsight
On Thu, 2009-02-05 at 18:23 +, Simon McVittie wrote: +property name=STUNServer tp:name-for-bindings=STUN_Server + type=s access=read + tp:added version=0.17.UNRELEASED/ + tp:docstring +The IP address or hostname of the STUN server to use for NAT traversal. +!-- Unresolved issue: should we mandate that this is an IP address? -- + /tp:docstring +/property Yes, we should. +property name=NATTraversal tp:name-for-bindings=NAT_Traversal + type=s access=read + tp:added version=0.17.UNRELEASED/ + tp:docstring xmlns=http://www.w3.org/1999/xhtml; +pThe transport (NAT traversal technique) to be used for this + stream. Well-known values include:/p + +dl + dtnone/dt + ddRaw UDP with no attempt made at doing NAT traversal. The +stun-server property MUST be absent or empty./dd + + dtstun/dt + ddRaw UDP, but a STUN request should be made to the given server +to open a UDP port mapping and determine the external IP. +The tp:member-refSTUNServer/tp:member-ref property MUST be +given and non-empty./dd + + dtgtalk-p2p/dt + ddGoogle Talk peer-to-peer connectivity establishment should be +used, as implemented in libjingle 0.3./dd + + dtice-udp/dt + ddInteractive Connectivity Establishment should be used, +as defined by the IETF MMUSIC working group./dd +/dl + /tp:docstring +/property Maybe also want to add msn-ice6 (as used in WLM 8 I believe?) The rest looks fine to me.. Youness, what do you think? -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] telepathy-farsight 0.0.4, now with added Python
Hello, Let the Python wrap you! Sjoerd has written cool new python bindings, so you can now use all of the tpfarsightedness from you favorite python application! Also, hold now works and the request-resource signal is now optional, if you don't listen to it, it will assume that the resource is always present. As usual, available from: http://telepathy.freedesktop.org/releases/telepathy-farsight/ -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] H.323 protocol support on Nokia N800/N810 devices?
On Thu, 2008-12-04 at 10:47 -0700, Merrick Fonnesbeck wrote: I am working on an application that may connect with another device already being used that currently communicates and sends video using the H.323 protocol. But I can't find anything that definitively states whether the Nokia internet tablets support H.323. Can anyone help me with this by letting me know if it does? Or if there is a plugin or code library that would give me that supported protocol for streaming video from the camera on the device out to another device that could receive it using H.323? Thanks. There is currently no Telepathy connection manager for H.323. So the Nokia N8x0 tablets have no H.323 support at all. -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Our error reporting sucks
First, thank you for answering, although with a 3 months delay! On Wed, 2008-12-03 at 17:33 +, Dafydd Harries wrote: Ar 28/08/2008 am 16:45, ysgrifennodd Olivier Cr??te: Hello, After spending too much time already trying to debug errors coming out of a connection manager, I've come to a simple conclusion: Telepathy error reporting SUCKS! As a first step, I propose adding translated error strings to the dbus errors.. So that instead of getting only NetworkError, we'd also get a strings that says Could not resolve a.b.c. Obviously, the UIs could ignore the string and the CMs don't have to emit a message with every error. How exactly do you propose we add an extra string? In the case of D-Bus method return errors, there isn't a place for us to put extra structured data. In the case of asynchronous errors, I don't see how to do without breaking API in a pretty nasty way. Well, for dbus error, there is already a string parameter, isn't there ? And this isn't structured data, its a string... Async errors have been done wrong, accept it, break the API/ABI and fix it. Or for every case add a new signal SignalNameWithUsableError and then new clients can use these and old ones use the old one (that can all be abstracted by tp-glib). I don't really like the idea of adding translations to connection managers. Either error conditions are common, in which case we should standardise them, or they're uncommon, in which case they should stay in the form of debug information. The problem is that we've been using integer enumerations of error conditions, which are difficult to extend in ABI-preserving ways. If we want to avoid translated strings in the CM (I don't really see why, they run in the same desktop session as the rest of the crap). We can add LOTS more stuff to the error enum. But to make it useful, we still need a string with extra information (like if we had an error can't resolve, then we'd also add a string with the hostname). Anyways, the current API is broken and needs fixing Also replace the org.freedesktop.Telepathy.Connection.StatusChanged signal with StatusChangedMessage(uus) where the string is the reason for the status change (I'm especially thinking of the NetworkError reason here). Also, I propose adding new log retrieval interface and make it mandatory on the ConnectionManager object and optional on the sub-objects (the Connection and Channels). Something like org.fd.tp.LogRetrieval with this method: GetLog(u: Number of Lines to return u: Min log level) - a(us) Where u would be the log level for that line (and s the string) so the UI can display/colorise it properly. This is a good idea, but I think probably a per-service debug object is easier to interface with. I think it should probably be something like: EnableDebugging() - a(us) I'm not sure the minumum log level parameter is very useful: you can filter that out on the client side. Also, calling this function would make a D-Bus signal be emitted for each debug message. This means that a debugger can watch a session without having to poll for logs. It might even be possible for dying services to send assertion failure messages over the bus. I think each service should probably have a global debug object. That means its hard to filter errors per telepathy connection .. so they may get mixed up pretty hard if you have multiple accounts... The minimum level is because stuff like GST can produce immense amounts of output at the highest log levels.. -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Using a server as some kind of audio/video relay?
On Sun, 2008-11-23 at 22:34 +1100, John Pye wrote: I have Linux server available to me which has a static IP address and which I can control. What you want are called ICE and TURN. ICE is a protocol used with SIP or XMPP that allows one to get through most NATs. TURN is Traversal Using Relays around NAT, its a soon-to-be-standardised protocol that implements a relay. That said, our implementation of these protocols is not yet fully integrated into any desktop client. However, if you use gabble + telepathy-stream-engine + empathy, you can make XMPP Jingle calls using an implementation of ICE and TURN from an older draft that is compatible with Google Talk. In summary, with SIP its painful for now. With XMPP, you can use gabble+farsight1+stream-engine+empathy and have calls work with other telepathy users as well as google-talk compatible clients. -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] stream-engine 0.5.5
Hello, I'm proud to announce the 0.5.5 release of Stream-engine. If you are a desktop-oriented Linux distribution, STOP HERE, this is not for you. This release: * uses libtelepathy-farsight to do the telepathy magic and uses farsight2. * is NOT meant to be used with Empathy or any other desktop-based client. * does NOT implement the same d-bus API as the older releases * assumes that the audio system is pulseaudio (but can also be made to work with a similar system). * does NOT provide volume control. Desktop applications MUST use libtelepathy-farsight directly. Hopefully, in the not so distant future. Someone (maybe me) will write helper libraries to make it easier to use it from a desktop application. And someone (maybe me), will port Empathy to use libtp-fs. -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] review: stream engine 'fs2-lib' branch
On Mon, 2008-10-20 at 12:20 +0100, Dafydd Harries wrote: If the config file thing is changed, I'm happy with the branch. I've created a telepathy-farsight repository for you to merge to. Ok, the proper branch is now the master of this new repository. I also have proposed branches of libtp-fs that removes the stream-engine program and a proposed branch of stream-engine that removes libtp-fs (and depends on the external lib).. See: http://monkey.collabora.co.uk/stream-engine.git_external-lib And http://git.collabora.co.uk/?p=user/tester/telepathy-farsight.git;a=shortlog;h=refs/heads/lib-only which for some reason fails to show up on the monkey -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] review: stream engine 'fs2-lib' branch
On Fri, 2008-10-17 at 17:54 +0100, Dafydd Harries wrote:
Ar 14/10/2008 am 16:25, ysgrifennodd Olivier Crête:
On Fri, 2008-10-10 at 16:06 +0100, Dafydd Harries wrote:
-service_in_files = org.freedesktop.Telepathy.StreamEngine.service.in
+service_in_files = org.maemo.Telepathy.StreamEngine.service.in
Hmm, this seems like a slightly odd choice of name.
Any other suggestions? The goal is to make it clear that the
out-of-process handling is really a maemo-specific thing.
While SE's past is exclusively in maemo land, and its future might well be
exclusively there also, there are non-Maemo people using it too, however
limited it is. The fact that your new code has #ifdef MAEMO_SUPPORT in it
attests to this.
Hopefully, the ifdef MAEMO_SUPPORT support will be going away. The idea
is to scare potential users into using the library.
But ok, I don't really care.
A more interesting question is where your branch should go. I think it might
be best to copy the SE repository to a telepathy-farsight repository and merge
it there.
Yes, I think we should split the telepathy-farsight library from the
stream-engine package.
+confdir = $(sysconfdir)/xdg/stream-engine
I don't think gstcodecs.conf should be in /etc/xdg. Put it in
/etc/telepathy/stream-engine.
Is there also a global config file for farsight2? If so, the SE one should
inherit from it somehow, to avoid duplication.
No, Farsight 2 has no config file, the config is passed programatically.
I'm putting it into /etc/xdg because that's what
g_get_system_config_dirs() returns and that follows the
XDG Base Directory Specification
I don't really understand why g_get_system_config_dirs() returns /etc/xdg. But
it seems to me that the XDG base directory specification is relevant only for
reference by other XDG specifications.
The FHS says that config files go in /etc.
I know I'm a bit lost in the whole XDG thing too
+#include telepathy-farsight/channel.h
+#include telepathy-farsight/stream.h
I think these includes should use instead of , since the headers
should
be read from the build tree, not from the system.
I changed that, but we have to not forget to revert it when we split the
library from maemo-s-e.
Wouldn't we get compilation errors if we forgot?
I guess
It looks like there's a lot of similar path building code spread across
various files. I think it would be good to factor it out.
What path building?
g_build_path() calls.
Where ?
[EMAIL PROTECTED] ~/collabora/telepathy-stream-engine $ grep -nrI g_build_path
*
[EMAIL PROTECTED] ~/collabora/telepathy-stream-engine $
+gst_element_set_state (engine-priv-pipeline, GST_STATE_NULL);
+gst_element_set_state (engine-priv-videosrc, GST_STATE_NULL);
+gst_element_set_state (engine-priv-pipeline,
GST_STATE_PLAYING);
Interesting. How does this work? Doesn't it run the risk of an infinite {
error - stop - start } loop?
It does, but in that case, you're fully screwed anyway. Its useful for
when you have a recoverable error.. I have no idea how to differentiate
fatal and non-fatal errors.
Ah, I see. Doesn't GStreamer separate errors into critical/non-critical ones?
Well, they are errors that are critical to gstreamer, but may possibly
be recovered from by restarting the pipeline. Stuff like the video
driver being crappy, crashing.. Closing and re-opening the device often
helps.
You sometimes indent lables to 0, 1, or 2 spaces. Pick one.
I believe it should be at -1 from the current code, I haven't found
any that wasn't consistent.
Consider using the code in other Telepathy components for automatically
generating signal marshaller list files.
I tried.. and failed..
What happened?
I obviously did something wrong, I copied the makefile stanza from
gabble and it just worked...
--
Olivier Crête
[EMAIL PROTECTED]
Collabora Ltd
signature.asc
Description: This is a digitally signed message part
___
Telepathy mailing list
Telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] review: stream engine 'fs2-lib' branch
On Wed, 2008-10-15 at 13:25 +0300, [EMAIL PROTECTED] wrote: Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Olivier Crête Sent: Tuesday, October 14, 2008 11:25 PM To: Dafydd Harries Cc: Telepathy Subject: Re: [Telepathy] review: stream engine 'fs2-lib' branch On Fri, 2008-10-10 at 16:06 +0100, Dafydd Harries wrote: -service_in_files = org.freedesktop.Telepathy.StreamEngine.service.in +service_in_files = org.maemo.Telepathy.StreamEngine.service.in Hmm, this seems like a slightly odd choice of name. Any other suggestions? The goal is to make it clear that the out-of-process handling is really a maemo-specific thing. Don't single us out :) Unless the standalone StreamEngine is now officially the dumping ground for whatever Maemo required, in contrast to a legitimate cross-platform option for a stand-alone IP streaming handler. PC platforms need more flexibility (various types of webcam, hotplugging them, etc) and that requires closer integration with the UI. So the out of process implementation should really be only for maemo. -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] review: stream engine 'fs2-lib' branch
obj; Shouldn't you propagate any error returned here? Its already propagated, the fs_session_new_stream() function will write it into our construction_error field. You sometimes indent lables to 0, 1, or 2 spaces. Pick one. I believe it should be at -1 from the current code, I haven't found any that wasn't consistent. Consider using the code in other Telepathy components for automatically generating signal marshaller list files. I tried.. and failed.. -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] TURN parameters
Hello, As Youness has mostly completed functional turn support in libnice, we need to pass the required parameters from the CM to the UI... For each component, and most RTP stream have two components (RTP and RTCP), we need to pass four values (ip/port/username/password). And we also need (per stream) to know if its using short term or long term credentials. After some discussion with Rob, he says we should add D-Bus properties to the StreamHandler interface. The question is which properties exactly? Do we have 9 properties (turn-creds-long-term, rtp-turn-ip, rtp-turn-port, rtp-turn-username, rtp-turn-password, rtcp-turn-ip, rtcp-turn-port...) Or just two properties (rtp-turn/rtcp-turn) with structures? Or just one property (turn-info) with an array of structures? Also, some protocols (like Google's stuff or MSN's SIP) provide the turn ip/port/username/password in their signalling, but simple SIP doesn't. It has to come from the profile (and is therefore long term credentials), so I propose these additions: http://monkey.collabora.co.uk/telepathy-spec.git_turn/ -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] Our error reporting sucks
Hello, After spending too much time already trying to debug errors coming out of a connection manager, I've come to a simple conclusion: Telepathy error reporting SUCKS! As a first step, I propose adding translated error strings to the dbus errors.. So that instead of getting only NetworkError, we'd also get a strings that says Could not resolve a.b.c. Obviously, the UIs could ignore the string and the CMs don't have to emit a message with every error. Also replace the org.freedesktop.Telepathy.Connection.StatusChanged signal with StatusChangedMessage(uus) where the string is the reason for the status change (I'm especially thinking of the NetworkError reason here). Also, I propose adding new log retrieval interface and make it mandatory on the ConnectionManager object and optional on the sub-objects (the Connection and Channels). Something like org.fd.tp.LogRetrieval with this method: GetLog(u: Number of Lines to return u: Min log level) - a(us) Where u would be the log level for that line (and s the string) so the UI can display/colorise it properly. -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] telepathy-stream-engine now in git
Hello, As part of the great quest to git-ify the world, telepathy-stream-engine joins the fray: http://git.collabora.co.uk/?p=telepathy-stream-engine.git;a=summary git://git.collabora.co.uk/git/telepathy-stream-engine.git git+ssh://git.collabora.co.uk/git/telepathy-stream-engine.git All unmerged branches (mine) have been ported and are available at: http://git.collabora.co.uk/?p=user/tester/stream-engine.git;a=summary -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Getting voip working in Empathy
Hello, On Fri, 2008-07-25 at 17:31 +0100, iain wrote: hi So I've been playing around with Telepathy and been trying today to get Empathy-Empathy voip working. The setup that I've got is two machines, Empathy on both, connecting to a private jabber server set up on one of them. The problem is that whenever the receiving machine accepts a call, the initiator instantly closes it. Attached are the logs from both stream engines. Can someone with more smarts than me see anything that could be happening and going wrong. Do I need logs from anything else? Your error is right there: (telepathy-stream-engine:8442): farsight-rtp-DEBUG: AUDIO - farsight_rtp_stream_bus_watch_cb: Error: gstalsasrc.c(640): gst_alsasrc_open (): /pipeline/bin1/gconfaudiosrc0/bin8/alsasrc0: Recording open error on device 'default': No such file or directory ** Message: tp_stream_engine_stream_error: stream errorno=0 error=Could not open audio device for recording. Configure your conferencing audio source properly in gnome-sound-properties.. Yes, we know that the error reporting is currently terrible. One of our SoCer (gcorvala) is working on fixing it. -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] IAX2
On Fri, 2007-11-30 at 18:31 +0100, salva wrote: Is it possible to use iax2 with Telepathy? Is there any connection manager? None has been written yet. -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] File transfer spec: need for advice
On Wed, 2007-22-08 at 15:47 +0200, Marco Barisione wrote: I propose to keep file transfers in the list until they are explicitly removed with AcknowledgeFileTransfer(), like we are already doing for text messages. I'm going to add a new CLOSED state to the existing ones (LOCAL_PENDING, REMOTE_PENDING and OPEN), but then FileTransferClosed signal would become a duplicate of FileTransferStateChanged so I'm going to remove it. What about FINISHED instead ? CLOSED kinda implies that you could open it. -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Media API redesign for SIP SOA and ICE
Hi, I'm sorry I didn't take the time to read earlier, but I was kind of busy with other things. I kind of like the whole idea of a transactional object (I've always wanted to implement some kind of transactional system), but I'm afraid that in the current timeframe, it would require too many changes to farsight's API to be implementable, although it is probably a good idea to think about it for Farsight 2. Anyways, I have a few questions. On Mon, 2007-04-06 at 00:06 +0300, [EMAIL PROTECTED] wrote: I've been thinking over the mapping of the StreamHandler and related APIs to semantics required for SDP Offer-Answer and ICE. There are a few problems with the current interfaces: - There is no good way to change the effective set of codecs and effective transport addresses all at once for a stream, which is required by SOA specification on session updates. - Similarly, there is no good way to roll back the stream state if an update offer gets rejected by local or remote party. Do you know if there is any requirement for the stream to keep its RTP properties when the candidates is changes? (ie, can't we just create a completely new stream?). - No clear way to implement forking with several provisional responses arriving from different endpoints, each potentially carrying an SDP answer. Until a 200 response arrives, the implementation cannot assume which session will finally be accepted, but it must at least respond to incoming ICE checks for every session. My reading of the SDP Offer-Answer stuff was that there could be a single negotiation going on at one time. As for the SIP provisional responses, can't you just create multiple streams with remote candidates but no remote codecs and set_sending to false (so the streams don't try to send anything). And maybe something to prevent them from actually receiving any data. -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd signature.asc Description: This is a digitally signed message part ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
