Re: [Ekiga-devel-list] Fedora 12 testing packages for NAT traversal support
On 04/24/2010 12:21 PM, yannick wrote: Hi, Chipper did binary packages for Fedora 12 including the NAT traversal patch (add STUN support for the audio and video streams). Please test them and report here: http://ekiga.net/yannick/f12/ [cut] Preliminary success. For the first time since FC9 I'm able to talk to the echo server. This works if and only if the patched opal library is installed. Fedora 12/i686/DLink DI614+. The router seems to support SIP, no static port forwarding required for the echo test. Nice work! --alec ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)
Trying to explain this once again, hopefully better. Questions in the end... The problem I try to solve is that users typically stores telephone numbers, often formatted and without countrycode, whereas Ekiga today requires a complete URL to place even an ordinary PSTN call. This makes the basic process to call a PSTN number hard, user has to manually convert e. g., '070-543 22 11' to sip:+46705432...@sip.diamondcard.com. I have written a piece of code which converts numbers to sip: urls. It's partly a question of handling missing country codes, partly to remove formatting characters as in '070- 543 11 22'. This code of course requires some configuration to define user's own countrycode etc. (all in total four values). It generates default config values usable for most users, and seems to work. It has the potential to let users just enter e. g., 070-543 22 11 in Ekiga to place a call instead of a complete URL. My problem is if/how to integrate this into Ekiga. More precise, I need help to integrate it. The Ekiga code is big, and although I think I'm able to produce a set of patches, I will at least need help with where in the code I should begin, and certainly other things as well. I really can't be on my own in this, it's to much for a newbie... So: first question: Would this overall be a Good Thing, something that makes Ekiga more usable, and thus worth some effort? Second question. I have done a simple plan: http://mumin.dnsalias.net/ekiga-callto-ui/patches.html. Is this reasonable? Third question. There is some UI impact, described in http://mumin.dnsalias.net/ekiga-callto-ui/index.html. Does this seems OK? Last question: Depending on the outcome of the other questions, how should I proceed with the first patch, to integrate a set of new source files related to PSTN management into Ekiga? Some background material: usecases defined in a few stories: http://mumin.dnsalias.net/ekiga-callto-ui/stories.html ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)
thomas schorpp wrote: Alec Leamas schrieb: Trying to explain this once again, hopefully better. Questions in the end... The problem I try to solve is that users typically stores telephone numbers, often formatted and without countrycode, whereas Ekiga today requires a complete URL to place even an ordinary PSTN call. No it doesn't. This is SIP-providers' switches business. A good VoIP/PSTN-provider with a fine designed switch does not require +countrycode... for local country #s. With sipgate.de e.g. You dial WYSIWYG on Ekiga's dialpad, care about @sipgate.de only, press green and off you go. But you still have to handle the @sip.xxx suffix to connect to the right provider, which is a Bad Thing. And besides the expansion, there is also what happens when you paste a formatted number into Ekiga. And you run into trouble when making DBus/CLI calls to connect to a specific number since Ekiga of today does not have the notion of a default PSTN provider. A more basic question is if Ekiga should support current users, and the providers they have. Or be used to put pressure on providers to implement certain features... I'm not sure that Ekiga currently is in the situation where it can put a pressure big enough to be useful. And users don't really want to wait for what the further spreading of electronic notepads and mobiles will lead to... Do you? Note that this is *not* about supporting providers that break the standards. It's about supporting a reasonably wide set of providers, and the way they implement standards. Skype is out there, people are actually comparing Ekiga w Skype. In Skype, you just enter the number, and it just works. Why should Ekiga be more complicated? Cheers! --a [cut] ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)
Simos wrote: On Sun, Mar 29, 2009 at 1:36 PM, Alec Leamas leamas.a...@gmail.com wrote: thomas schorpp wrote: Alec Leamas schrieb: Trying to explain this once again, hopefully better. Questions in the end... The problem I try to solve is that users typically stores telephone numbers, often formatted and without countrycode, whereas Ekiga today requires a complete URL to place even an ordinary PSTN call. No it doesn't. This is SIP-providers' switches business. A good VoIP/PSTN-provider with a fine designed switch does not require +countrycode... for local country #s. With sipgate.de e.g. You dial WYSIWYG on Ekiga's dialpad, care about @sipgate.de only, press green and off you go. But you still have to handle the @sip.xxx suffix to connect to the right provider, which is a Bad Thing. And besides the expansion, there is also what happens when you paste a formatted number into Ekiga. And you run into trouble when making DBus/CLI calls to connect to a specific number since Ekiga of today does not have the notion of a default PSTN provider. A more basic question is if Ekiga should support current users, and the providers they have. Or be used to put pressure on providers to implement certain features... I'm not sure that Ekiga currently is in the situation where it can put a pressure big enough to be useful. And users don't really want to wait for what the further spreading of electronic notepads and mobiles will lead to... Do you? Note that this is *not* about supporting providers that break the standards. It's about supporting a reasonably wide set of providers, and the way they implement standards. Skype is out there, people are actually comparing Ekiga w Skype. In Skype, you just enter the number, and it just works. Why should Ekiga be more complicated? I think the direction of your work is what Ekiga needs to make it easier for people to use. The workflow for dialing numbers that I envision new users of Ekiga would go through is A. Calling an existing entry in the Addressbook The addressbook is visible to the users so that when they need to call a contact for the second time, they would be more likely to go through the addressbook. The effort would be for Ekiga to try to get any new numbers in the Addressbook, similar to the way that the Betamax client does (allows to call a number directly, and if the call succeeds, it prompts to save it as an addressbook entry). B. Dialing a new number When a new number is typed and the Call button is pressed, I would prefer to have a dialog (single window wizard) pop up which would include 1. The number would be parsed according to your code and the country code, SIP provider, etc would be autocompleted to the extent possible. 2. There would be an option to save the entry to the addressbook 3. There would be a big Call button labeled 'Call Now' for users that want to actually call directly, temporarily postponing the addition to the addressbook. What I think is important is to try to make less visible (in sip:+46705434...@sip.diamondcard.com) the two parts about 'sip:' but most importantly the '@sip.diamondcard.com'). It would be ideal if in the UI, the 'sip:' part is considered a single entity (not four characters), and the same with the '@sip.diamondcard.com'. As a user, I have the telephone number X and I want to call with the S SIP provider. The 'sip:' is implied from S, and the '@sip.diamondcard.com' part is part of the information that Ekiga knows about this known SIP telephony provider. This all boils down to Ekiga learning about SIP providers and having an ability to register the details of those providers (i.e. be part of a configuration file that ekiga.net maintains). Of course, users would still be able to make custom entries. There is a relevant bug report for this at http://bugzilla.gnome.org/show_bug.cgi?id=547215 Simos ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list Hm... I actually share many of your opinions, perhaps all. The problem is just to find the limits of this work, its already nine patches. Of course, things would be different if I were not alone implementing this. My current understanding is that this is especially true for the UI, where I have tried to find a solution with as small changes as possible. Is it feasible to address an UI overhaul once a first attempt is out? My own experience is that you get really good ideas when you have a first attempt running. The need to hide the (a)sip.xxx part is already identified and discussed ( by at least Julien). And to be honest, it was a part of this work in my first sketches. But although it *is* important, I'd prefer not do this within this RFE. It's really a separate issue. Bottom line: I think what you say is interesting and is also in the right direction (I don't really understand all details
Re: [Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)
Eugen Dedu wrote: Hi, Hi :-) Thanks, Alec, for this. Let's try to check it in while it is fresh, otherwise it will be forgotten and the chances to be integrated are small. Also, let's wait with the check in a few days (until Tuesday?) for other people comments. (I welcome the make easy the user work subject; there is room here for other sub-domains too, we will speak later about that.) I'll be actually be offline for a week, so its no hurry. And for the same reason I will try to comment issues which I feel I have actual now, and not later. I'll try to attach a new version of the files to the bug before I leave. Alec Leamas wrote: Trying to explain this once again, hopefully better. Questions in the end... The problem I try to solve is that users typically stores telephone numbers, often formatted and without countrycode, whereas Ekiga today requires a complete URL to place even an ordinary PSTN call. This makes the basic process to call a PSTN number hard, user has to manually convert e. g., '070-543 22 11' to sip:+46705432...@sip.diamondcard.com. I have written a piece of code which converts numbers to sip: urls. It's partly a question of handling missing country codes, partly to remove formatting characters as in '070- 543 11 22'. This code of course requires some configuration to define user's own countrycode etc. (all in total four values). It generates default config values usable for most users, and seems to work. It has the potential to let users just enter e. g., 070-543 22 11 in Ekiga to place a call instead of a complete URL. My problem is if/how to integrate this into Ekiga. More precise, I need help to integrate it. The Ekiga code is big, and although I think I'm able to produce a set of patches, I will at least need help with where in the code I should begin, and certainly other things as well. I really can't be on my own in this, it's to much for a newbie... So: first question: Would this overall be a Good Thing, something that makes Ekiga more usable, and thus worth some effort? I agree. Second question. I have done a simple plan: http://mumin.dnsalias.net/ekiga-callto-ui/patches.html. Is this reasonable? I agree. Third question. There is some UI impact, described in http://mumin.dnsalias.net/ekiga-callto-ui/index.html. Does this seems OK? For the moment, let's just do nothing (the current error is shown). Later, we can add a menu entry, or a tab in preferences etc. Last question: Depending on the outcome of the other questions, how should I proceed with the first patch, to integrate a set of new source files related to PSTN management into Ekiga? There are three files involved (Pstn* and .csv); I would propose to use PTRACE from ptlib; as for assert, isn't possible to use classical assert? I can use PTRACE with some loss of information in error messages. Same for classical assert, to a much higher degree. Note my Trace/Assert uses the PTRACE backend when it's available, so there is really no conflict. But it's some extra code, yes. I have actually refactored the code, so wait a little with checking in. One of the thing I was thinking about is if there should be a separate directory for this, or which existing should be used. There is currently four source files besides the Trace/Assert stuff., + the csv file. The csv file is an issue. The app must be able to locate it, it's just a hardcoded path now. No idea how handle it. The first thing is to add a hook when the user clicks on green button. Later, we will add a hook for adding in dbus, roster etc., as you wrote. I see in the bug report there are several things involved, such as PresenceCode; so is it there to add this hook? The change to ekiga current code should be very small, only 2 lines (call your pstn file and replace the URL bar value). To be honest: I have absolutely no idea where to make the changes. But I think that in this case it's the code executed when user user pushes the Call context menu option for a contact. Yes, most of these patches should be really small. The problem is to find out where to do it... In fact, all your work can be resumed like this: when the user pushes the green button (or dbus, roster etc.), the number in the URL bar is transformed, that's all, isn't it? No, not really. The problem is when you expand a number supposed to be evaluated in another country e. g., when using a number on a US website. The user must then have a chance to review and edit the number before it's used. (it's the second example in my UI sketch and story 2.) So there *is* a need for a three-step approach: first convert, review/edit and call. The situation is the same whether called from the browser or when a number is pasted into Ekiga. The just push button is a shortćut possible on numbers that are unambiguous: starting with +, or from the address book. Some background material: usecases defined in a few stories: http
Re: [Ekiga-list] Implementing ekiga-callto (plain number management)
Julien Puydt wrote: Alec Leamas a écrit : This is a discussion started in http://bugzilla.gnome.org/show_bug.cgi?id=576486. Making a try to move discussion to the mailing list. Please read the bug to get context, specifically the stories attachment. The basic idea is that users should be able to use ordinary phone numbers when using Ekiga. Eh... I wrote ekiga-devel mailing-list, not that one :-) Sorry, my wrong, let's continue ther then... --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Alsa device enumeration
Damien Sandras wrote: Le mercredi 11 mars 2009 à 20:46 +0100, Alec Leamas a écrit : There are some problems w the current code which enumerates the alsa devices. I have a sketch for a patch, this is really not that complicated these days, there are new library routines which support it. The problem is just what devices to show, and how. Basically, there is two kind of devices: the classic devices which we partly see today, and several new devices such as pulse, hdmi, and several surround*. They exist for both capture and playback. The list for my box is below. The basic ideas are stolen from Skype. The important thing is the left column, the right is just internal stuff (hey, use a fixed font to see this...). Any thoughts out there about this list? I would clean it and remove entries with hw only. Because that's complex. What is Surround40 capture ? Surround capture is in my eyes complete nonsense. It's reported, though. I totally agree that it should not be visible to users. The hw discussion is complex. Actually, there are documents on the alsa site which boils down to that using hw:/plughw: is deprecated, they recommend front, surround* etc. But for capture, it just makes no sense. And, more important, if you have more than one card there is no way to e. g., direct sound to device front at the usb headset. Which device front actually refers to is a part of fthe alsa configuration (normally the default device). So, to direct sound to a specific card you must either mess with the alsa configuration, or use the hw:/plughw:. This is my current understanding. I know there are people who knows more which is reading this... My basic impression is that the alsa device addressing schema is a bit hard to handle, especially with more than one card. And although it's not that common that users have more than one card in their box, USB and bluetooth headsets are important use cases involving more than one card from the alsa perpective. It's also important to sort out the different roles in device management. The ultimate goal in my eyes is to create a new UI focused on making it much easier to setup the sound system. The major task is really up to the UI code here. My basic view is that the driver should provide a reasonably complete list of devices with as much information as possible. This does not preclude hiding nonsense like surround capture, But the finer tricks should be done by the UI, and we should be careful not to hide to much in the driver. The UI has other options than to just take the list from the driver and place in a select box IMHO. The plughw/hw is indeed complex. But to my understanding, it's really the only way to fix the basic task Send sound to and get capture from the USB headset/main box/bluetooth headset. Of course, we could handle this by reconfiguring alsa. But since devices comes and goes away, and then comes back with a new number (sigh...) this is not that easy. Maybe the complexity of hw/plughw could be handled by a new UI? --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Alsa device enumeration
Damien Sandras wrote: [ cut] I'm not sure. How can we know surround is non sense? How can we know other similar non sense entries... To my eyes, Alsa is really purely broken :-/ I didn't mean that surround is nonsense, no way. I just mean that surround capture/record/input makes no sense. 6 microphones, or what? One important aspect is that this new list contains new entries which are definitely meaningful including the pulse device. I have the same impression as you of the alsa naming scheme, But we have to live with t (?) I'll make Yet Another List. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Alsa device enumeration
There are some problems w the current code which enumerates the alsa devices. I have a sketch for a patch, this is really not that complicated these days, there are new library routines which support it. The problem is just what devices to show, and how. Basically, there is two kind of devices: the classic devices which we partly see today, and several new devices such as pulse, hdmi, and several surround*. They exist for both capture and playback. The list for my box is below. The basic ideas are stolen from Skype. The important thing is the left column, the right is just internal stuff (hey, use a fixed font to see this...). Any thoughts out there about this list? Cheers! --alec Capture devices: null null default default pulse pulse AD198x Analog - hw:0,0hw:0,0 AD198x Analog - plughw:0,0plughw:0,0 AD198x Digital - hw:0,1 hw:0,1 AD198x Digital - plughw:0,1 plughw:0,1 Playback devices: iec958 - NVidia,0 iec958 null null default default pulse pulse AD198x Analog - hw:0,0hw:0,0 AD198x Analog - plughw:0,0plughw:0,0 AD198x Digital - hw:0,1 hw:0,1 AD198x Digital - plughw:0,1 plughw:0,1 surround40 - NVidia,0 surround40 surround41 - NVidia,0 surround41 surround50 - NVidia,0 surround50 surround51 - NVidia,0 surround51 surround71 - NVidia,0 surround71 front - NVidia,0 front ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Damien Sandras wrote: [cut] Indeed. I have submitted a temporary patch to http://bugzilla.gnome.org/show_bug.cgi?id=572953. Not tested, but should be better than today. If it not makes other problems visible...Many thanks for your help with his, I wouldn't really have a chance without it. This patch will break with some hardware, even on Linux. Yes. OTOH, having a 5 periods hardcoded value for all hardware means, on 8 kHz, 100 ms latency where a value of 40-60 ms would be sufficient for many (most?) hw configurations. I still regard this as a bug, although this patch, which is more like a test case, is to simple. Stay tuned until there is some testing... Besides, things like this should definitely be declared instead of being hardcoded values in implementation code :-) --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Incoming call failure with 3.1.1
Damien Sandras wrote: Le lundi 02 mars 2009 à 14:39 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Eugen Dedu wrote: Damien Sandras wrote: Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit : Damien Sandras wrote: Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit : Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: A gdb backtrace would be more useful. waiting for some kind of customer service, taking a backtrace (yes, same problem, trunk as of yesterday). Despite trying 50 times, I can not reproduce it. Are you sure something is not corrupted? Eugen, can you reproduce it? Hi, Sorry for taking so much time to reply. Very interesting, when I call 520, I receive the call and it works (I have audio conversation). I use on debian ii ekiga-snapshot 0-20090226-1 H.323 and SIP compatible VoIP client - svn version configure: dummy export PTLIBDIR=$$PWD;\ ./configure \ --prefix=/usr \ --libdir=/usr/lib64\ --enable-debug \ --enable-tracing \ --disable-static \ --enable-plugins \ --disable-oss \ --enable-v4l2 \ --disable-avc \ --disable-v4l For info, I use much less configure options, only prefix and enable-v4l for ptlib I think, the other ones are by default. (But I do not think this is the problem.) By the way, does someone know how we can show the default options when running ./configure --help (for ex.)? Instead of putting them in the wiki, better to automatise the process by pushing them in the source code. Final configuration === Installing into prefix : /usr [...] libnotify support : disabled Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3sends desktop notifications to a notification daemon ii libnotify1 0.4.4-3sends desktop notifications to a notification daemon In fact, it cannot be because of libnotify, because Mark Carroll has the same problem and he uses snapshots, which use libnotify... My bad, thou shall not guess. I just compiled a version w libnotify, same problem crash. Relevant thread from gdb: Program received signal SIGSEGV, Segmentation fault. 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 [cut] Thread 1 (Thread 0x76b0f7b0 (LWP 23589)): #0 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 #1 0x004aa1da in closed_cb (main_window=0x2) at gui/main.cpp:2759 #2 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #3 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #4 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #5 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #6 0x003167603929 in ?? () from /usr/lib64/libnotify.so.1 #7 0x003b99811994 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #8 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #9 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #10 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #11 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #12 0x003b998129ca in ?? () from /usr/lib64/libdbus-glib-1.so.2 #13 0x003b98c0ef7b in dbus_connection_dispatch () from /lib64/libdbus-1.so.3 #14 0x003b99809765 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #15 0x0037b2c3779b
Re: [Ekiga-list] Incoming call failure with 3.1.1
Eugen Dedu wrote: Alec Leamas wrote: Damien Sandras wrote: Le lundi 02 mars 2009 à 14:39 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Eugen Dedu wrote: Damien Sandras wrote: Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit : Damien Sandras wrote: Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit : Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: A gdb backtrace would be more useful. waiting for some kind of customer service, taking a backtrace (yes, same problem, trunk as of yesterday). Despite trying 50 times, I can not reproduce it. Are you sure something is not corrupted? Eugen, can you reproduce it? Hi, Sorry for taking so much time to reply. Very interesting, when I call 520, I receive the call and it works (I have audio conversation). I use on debian ii ekiga-snapshot 0-20090226-1 H.323 and SIP compatible VoIP client - svn version configure: dummy export PTLIBDIR=$$PWD;\ ./configure \ --prefix=/usr \ --libdir=/usr/lib64\ --enable-debug \ --enable-tracing \ --disable-static \ --enable-plugins \ --disable-oss \ --enable-v4l2 \ --disable-avc \ --disable-v4l For info, I use much less configure options, only prefix and enable-v4l for ptlib I think, the other ones are by default. (But I do not think this is the problem.) By the way, does someone know how we can show the default options when running ./configure --help (for ex.)? Instead of putting them in the wiki, better to automatise the process by pushing them in the source code. Final configuration === Installing into prefix : /usr [...] libnotify support : disabled Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3sends desktop notifications to a notification daemon ii libnotify1 0.4.4-3sends desktop notifications to a notification daemon In fact, it cannot be because of libnotify, because Mark Carroll has the same problem and he uses snapshots, which use libnotify... My bad, thou shall not guess. I just compiled a version w libnotify, same problem crash. Relevant thread from gdb: Program received signal SIGSEGV, Segmentation fault. 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 [cut] Thread 1 (Thread 0x76b0f7b0 (LWP 23589)): #0 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 #1 0x004aa1da in closed_cb (main_window=0x2) at gui/main.cpp:2759 #2 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #3 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #4 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #5 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #6 0x003167603929 in ?? () from /usr/lib64/libnotify.so.1 #7 0x003b99811994 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #8 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #9 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #10 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #11 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #12 0x003b998129ca in ?? () from /usr/lib64/libdbus-glib-1.so.2 #13 0x003b98c0ef7b in dbus_connection_dispatch () from /lib64/libdbus-1.so.3 #14 0x003b99809765 in ?? () from /usr/lib64/libdbus-glib-1
Re: [Ekiga-list] Incoming call failure with 3.1.1
Eugen Dedu wrote: Alec Leamas wrote: Damien Sandras wrote: Le lundi 02 mars 2009 à 14:39 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Eugen Dedu wrote: Damien Sandras wrote: Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit : Damien Sandras wrote: Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit : Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: A gdb backtrace would be more useful. waiting for some kind of customer service, taking a backtrace (yes, same problem, trunk as of yesterday). Despite trying 50 times, I can not reproduce it. Are you sure something is not corrupted? Eugen, can you reproduce it? Hi, Sorry for taking so much time to reply. Very interesting, when I call 520, I receive the call and it works (I have audio conversation). I use on debian ii ekiga-snapshot 0-20090226-1 H.323 and SIP compatible VoIP client - svn version configure: dummy export PTLIBDIR=$$PWD;\ ./configure \ --prefix=/usr \ --libdir=/usr/lib64\ --enable-debug \ --enable-tracing \ --disable-static \ --enable-plugins \ --disable-oss \ --enable-v4l2 \ --disable-avc \ --disable-v4l For info, I use much less configure options, only prefix and enable-v4l for ptlib I think, the other ones are by default. (But I do not think this is the problem.) By the way, does someone know how we can show the default options when running ./configure --help (for ex.)? Instead of putting them in the wiki, better to automatise the process by pushing them in the source code. Final configuration === Installing into prefix : /usr [...] libnotify support : disabled Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3sends desktop notifications to a notification daemon ii libnotify1 0.4.4-3sends desktop notifications to a notification daemon In fact, it cannot be because of libnotify, because Mark Carroll has the same problem and he uses snapshots, which use libnotify... My bad, thou shall not guess. I just compiled a version w libnotify, same problem crash. Relevant thread from gdb: Program received signal SIGSEGV, Segmentation fault. 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 [cut] Thread 1 (Thread 0x76b0f7b0 (LWP 23589)): #0 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 #1 0x004aa1da in closed_cb (main_window=0x2) at gui/main.cpp:2759 #2 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #3 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #4 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #5 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #6 0x003167603929 in ?? () from /usr/lib64/libnotify.so.1 #7 0x003b99811994 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #8 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #9 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #10 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #11 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #12 0x003b998129ca in ?? () from /usr/lib64/libdbus-glib-1.so.2 #13 0x003b98c0ef7b in dbus_connection_dispatch () from /lib64/libdbus-1.so.3 #14 0x003b99809765 in ?? () from /usr/lib64/libdbus-glib-1
Re: [Ekiga-list] Incoming call failure with 3.1.1
Eugen Dedu wrote: Damien Sandras wrote: Le lundi 02 mars 2009 à 15:35 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Alec Leamas wrote: Damien Sandras wrote: Le lundi 02 mars 2009 à 14:39 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Eugen Dedu wrote: Damien Sandras wrote: Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit : Damien Sandras wrote: Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit : Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: A gdb backtrace would be more useful. waiting for some kind of customer service, taking a backtrace (yes, same problem, trunk as of yesterday). Despite trying 50 times, I can not reproduce it. Are you sure something is not corrupted? Eugen, can you reproduce it? Hi, Sorry for taking so much time to reply. Very interesting, when I call 520, I receive the call and it works (I have audio conversation). I use on debian ii ekiga-snapshot 0-20090226-1 H.323 and SIP compatible VoIP client - svn version configure: dummy export PTLIBDIR=$$PWD;\ ./configure \ --prefix=/usr \ --libdir=/usr/lib64\ --enable-debug \ --enable-tracing \ --disable-static \ --enable-plugins \ --disable-oss \ --enable-v4l2 \ --disable-avc \ --disable-v4l For info, I use much less configure options, only prefix and enable-v4l for ptlib I think, the other ones are by default. (But I do not think this is the problem.) By the way, does someone know how we can show the default options when running ./configure --help (for ex.)? Instead of putting them in the wiki, better to automatise the process by pushing them in the source code. Final configuration === Installing into prefix : /usr [...] libnotify support : disabled Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3sends desktop notifications to a notification daemon ii libnotify1 0.4.4-3sends desktop notifications to a notification daemon In fact, it cannot be because of libnotify, because Mark Carroll has the same problem and he uses snapshots, which use libnotify... My bad, thou shall not guess. I just compiled a version w libnotify, same problem crash. Relevant thread from gdb: Program received signal SIGSEGV, Segmentation fault. 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 [cut] Thread 1 (Thread 0x76b0f7b0 (LWP 23589)): #0 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 #1 0x004aa1da in closed_cb (main_window=0x2) at gui/main.cpp:2759 #2 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #3 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #4 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #5 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #6 0x003167603929 in ?? () from /usr/lib64/libnotify.so.1 #7 0x003b99811994 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #8 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #9 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #10 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #11 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #12 0x003b998129ca in ?? () from /usr/lib64/libdbus-glib-1.so.2 #13 0x003b98c0ef7b in dbus_connection_dispatch
Re: [Ekiga-list] PTLIB alsa plugin status
Damien Sandras wrote: Le dimanche 01 mars 2009 à 17:53 +0100, Alec Leamas a écrit : Derek Smithies wrote: On Sat, 28 Feb 2009, Alec Leamas wrote: Derek Smithies wrote: Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: I need a whisky. Coffee is much better. Don't add any impurities though (milk, sugar etc) I'm was actually using both whisky AND coffe w milk. Sorry, no offense... :-) After some serious fights w the build system, I've been able to add a simple PTRACE to the SetBuffers method in sound_alsa.cxx. Trimmed output: 13:45:49.348 ALSASetting buffers, size: 3840, count: 5 13:45:49.402 ALSADevice default Opened 13:45:49.438 ALSASetting buffers, size: 320, count: 5 It is set in opal in OpalAudioMediaStream::OpalAudioMediaStream( where soundChannelBuffers is set to the supplied parameter value. This comes out of the pcssendpoint class, which which ends up coming from: a method of the pcss endpoint which gets the user defined buffer depth... soundChannelBuffers = pcss endpoint.GetSoundChannelBufferDepth() so you know what ? I think this is a bug from outside of ptlibopal. The default values for codec sizes in ptlibopal are for a count of 2 buffers (unix) and 3 buffers(windows). Derek. Indeed. I have submitted a temporary patch to http://bugzilla.gnome.org/show_bug.cgi?id=572953. Not tested, but should be better than today. If it not makes other problems visible...Many thanks for your help with his, I wouldn't really have a chance without it. This patch will break with some hardware, even on Linux. With the standard 8 kHz codecs, there is not more than 2-3 errors on 1 Mbyte of data using a two periods hw buffer and a 150 ms jitter buffer from Sweden to the echo server. I've added logging code to the alsa driver to show this. I have not been able to get any usable results using the 16 kHz codecs against 5...@ekiga.net (no sound at all...). If the jitter buffer is decreased to 50 ms there are more errors, but then the sound is so bad anyway that it's not a valid usecase. Thinking about it, I can't really see why two or three periods should be a problem unless the jitter buffer is to small (or the system overloaded). And it's the user who sets the jitter buffer. I really think the defaut value should be smaller 2 (or 3) on Linux. Question is how to adjust this value if needed. Yet another hidden gconf variable? Is it needed, can this be handled by the jitter buffer? Anyway, this is a way to get rid of 40-60 ms of latency on Linux, more on windows. I think it deserves to be thought of, it is a substantial gain. BUt bot until the release is out :-) --a PS: I can now accept calls with the gtk message box. This used to crash. DS --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Derek Smithies wrote: On Sat, 28 Feb 2009, Alec Leamas wrote: Derek Smithies wrote: Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: I need a whisky. Coffee is much better. Don't add any impurities though (milk, sugar etc) I'm was actually using both whisky AND coffe w milk. Sorry, no offense... :-) After some serious fights w the build system, I've been able to add a simple PTRACE to the SetBuffers method in sound_alsa.cxx. Trimmed output: 13:45:49.348 ALSASetting buffers, size: 3840, count: 5 13:45:49.402 ALSADevice default Opened 13:45:49.438 ALSASetting buffers, size: 320, count: 5 It is set in opal in OpalAudioMediaStream::OpalAudioMediaStream( where soundChannelBuffers is set to the supplied parameter value. This comes out of the pcssendpoint class, which which ends up coming from: a method of the pcss endpoint which gets the user defined buffer depth... soundChannelBuffers = pcss endpoint.GetSoundChannelBufferDepth() so you know what ? I think this is a bug from outside of ptlibopal. The default values for codec sizes in ptlibopal are for a count of 2 buffers (unix) and 3 buffers(windows). Derek. Indeed. I have submitted a temporary patch to http://bugzilla.gnome.org/show_bug.cgi?id=572953. Not tested, but should be better than today. If it not makes other problems visible...Many thanks for your help with his, I wouldn't really have a chance without it. --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Incoming call failure with 3.1.1
Damien Sandras wrote:
Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit :
Damien Sandras wrote:
Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit :
Damien Sandras dsand...@seconix.com writes:
Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit :
I have run through the configuration assistant thing from start to
finish. I can call the 5...@ekiga.net echo test and that works
just fine.
However, calling the 5...@ekiga.net callback service has it hang
up on me
and then ... nothing, though the -d 5 output shows that it is indeed
getting a callback initiated from from sip:5...@ekiga.net which is
then
aborted. I am behind NAT and the router forwards incoming UDP
from port
5060 to 5100 to the machine I'm using and acts as a gateway to
let all
my outgoing packets out.
Should I gzip my -d 4 output and send it to somebody? I can also
sniff
packets and send pcap files. I use Debian; software versions are,
There is a known problem with incoming calls and the current
snapshot. I
will fix it this week-end.
Now with the 20090225 one, the incoming call does arrive (yay!), I hit
`accept', and it segfaults.
I can still send my -d 4 output to somebody. (-:
A gdb backtrace would be more useful.
waiting for some kind of customer service, taking a backtrace (yes,
same problem, trunk as of yesterday).
Despite trying 50 times, I can not reproduce it. Are you sure something
is not corrupted?
Eugen, can you reproduce it?
Hm... I'm not the only one with this issue, seems to pop up now and
then, last this morning. Is it the build options? I's all very simple
for me: call 5...@ekiga.net, wait until there is a incoming call, see a
coredump for either Accept or Reject, doesn't seem to matter which.
configure: dummy
export PTLIBDIR=$$PWD;\
./configure \
--prefix=/usr \
--libdir=/usr/lib64\
--enable-debug \
--enable-tracing \
--disable-static \
--enable-plugins \
--disable-oss \
--enable-v4l2 \
--disable-avc \
--disable-v4l
hemulen ptlib-2.7.0$ svnversion
22117M# Some trace/logging changes, I think they are under
control...
./configure --prefix=/usr --libdir=%{_libdir} --enable-debug# OPAL
hemulen opal-3.7.0$ svnversion
22117
Final configuration ===
Installing into prefix : /usr
GNOME support : disabled
GConf support : enabled
Evolution-Data-Server support : enabled
NOTIFY support : disabled
LDAP support : enabled
XVideo support : enabled
H.323 support : yes
SIP support : yes
DBUS support : enabled
DBUS service support : enabled
mDNS/DNS-SD support : enabled
GStreamer support : disabled
KAddressBook support : disabled
KDE support : disabled
XCAP support : disabled
libnotify support : disabled
OS Type : linux-gnu
Machine Type : x86_64
Byte Order : little endian
If all settings are OK, type make and make install
$ svnversion
7694
___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Incoming call failure with 3.1.1
Damien Sandras wrote:
Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit :
Damien Sandras wrote:
Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit :
Damien Sandras dsand...@seconix.com writes:
Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit :
I have run through the configuration assistant thing from start to
finish. I can call the 5...@ekiga.net echo test and that works
just fine.
However, calling the 5...@ekiga.net callback service has it hang
up on me
and then ... nothing, though the -d 5 output shows that it is indeed
getting a callback initiated from from sip:5...@ekiga.net which is
then
aborted. I am behind NAT and the router forwards incoming UDP
from port
5060 to 5100 to the machine I'm using and acts as a gateway to
let all
my outgoing packets out.
Should I gzip my -d 4 output and send it to somebody? I can also
sniff
packets and send pcap files. I use Debian; software versions are,
There is a known problem with incoming calls and the current
snapshot. I
will fix it this week-end.
Now with the 20090225 one, the incoming call does arrive (yay!), I hit
`accept', and it segfaults.
I can still send my -d 4 output to somebody. (-:
A gdb backtrace would be more useful.
waiting for some kind of customer service, taking a backtrace (yes,
same problem, trunk as of yesterday).
Despite trying 50 times, I can not reproduce it. Are you sure something
is not corrupted?
Eugen, can you reproduce it?
Hm... I'm not the only one with this issue, seems to pop up now and
then, last this morning. Is it the build options? It's all very simple
for me: call 5...@ekiga.net, wait until there is a incoming call, see a
coredump for either Accept or Reject, doesn't seem to matter which.
configure: dummy
export PTLIBDIR=$$PWD;\
./configure \
--prefix=/usr \
--libdir=/usr/lib64\
--enable-debug \
--enable-tracing \
--disable-static \
--enable-plugins \
--disable-oss \
--enable-v4l2 \
--disable-avc \
--disable-v4l
hemulen ptlib-2.7.0$ svnversion
22117M# Some trace/logging changes, I think they are under
control...
./configure --prefix=/usr --libdir=%{_libdir} --enable-debug# OPAL
hemulen opal-3.7.0$ svnversion
22117
Final configuration ===
Installing into prefix : /usr
GNOME support : disabled
GConf support : enabled
Evolution-Data-Server support : enabled
NOTIFY support : disabled
LDAP support : enabled
XVideo support : enabled
H.323 support : yes
SIP support : yes
DBUS support : enabled
DBUS service support : enabled
mDNS/DNS-SD support : enabled
GStreamer support : disabled
KAddressBook support : disabled
KDE support : disabled
XCAP support : disabled
libnotify support : disabled
OS Type : linux-gnu
Machine Type : x86_64
Byte Order : little endian
If all settings are OK, type make and make install
$ svnversion
7694
___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Sorry for the noise. I've had problems w my email, lost control over what's really sent. -a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Incoming call failure with 3.1.1
Eugen Dedu wrote: [cut] Final configuration === Installing into prefix : /usr [...] libnotify support : disabled Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3sends desktop notifications to a notification daemon ii libnotify1 0.4.4-3sends desktop notifications to a notification daemon Very likely, the crash seems o be in the callback invoked from the message box: Thread 1 (Thread 0x76b247b0 (LWP 4832)): #0 0x004a0ff9 in incoming_call_response_cb ( incoming_call_popup=0x7fffeca23520, response=0, data=0x7fffde80) at gui/main.cpp:1418 #1 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #2 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Derek Smithies wrote: Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: I need a whisky. Coffee is much better. Don't add any impurities though (milk, sugar etc) I'm was actually using both whisky AND coffe w milk. Sorry, no offense... :-) After some serious fights w the build system, I've been able to add a simple PTRACE to the SetBuffers method in sound_alsa.cxx. Trimmed output: 13:45:49.348 ALSASetting buffers, size: 3840, count: 5 13:45:49.402 ALSADevice default Opened 13:45:49.438 ALSASetting buffers, size: 320, count: 5 which verifies Andreas' logs i. e., this is what causes the oversized alsa hw buffer. I made a quick search, there are no references to SetBuffers in the plugin code. So these calls comes from the upper layers. For the moment I'll stick to the alsa plugin and will not investigate this any further. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] call failure
I've been able to reproduce what I think is the same error (core dumped when 520 calls back). Gdb backtrace in http://mail.gnome.org/archives/ekiga-list/2009-February/msg00282.html --a Michael Stockenhuber wrote: Hi, Fair enough. Its great to hear that there are a lot of users. It is not a gdb backtrace it the debug output from ekiga in linux ( ekiga -d 4). Anyway, I have cut out the stuff that was repeated a lot and got it down to below 40 kB. File is enclosed. Maybe someone can help. Cheers Michael On February 28, 2009 at 2:54 AM Damien Sandras dsand...@seconix.com wrote: Le vendredi 27 février 2009 à 20:52 +1100, Michael Stockenhuber a écrit : Hi, I have replied and sent the logs but they are too big and wait for moderator approval. It won't get approved, there are too many subscribers to this list. Please post it to pastebin. However, I doubt a gdb backtrace is that big. -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ Be IP : http://www.beip.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsand...@ekiga.net ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Derek Smithies wrote: Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: Hm... a write operation could be guaranteed to return in finite time (using non-blocking io + snd_pcm_wait). So couldn't the close method just mark the chanell as closing, leaving the dirty work to the writer thread and thus avoiding the locks? (Which, otoh, really isn't a big issue in this scenario). If required, opening could be handled in the same way, I guess. This would also create the advantage that the thread could process the jitter buffer data in parallel with the alsa output, without the need to wait for the IO to complete. Wouldn't this give a more accurate timing? Also, avoiding blocking io is a Good Thing IMHO. No. It must be a blocking write. The architecture of opal demands this. The play thread (using play as an example) repeatedly does the following read rtp packet from jitter buffer decode put raw audio to sound device (which delays for up to framesize of packet) I didn't really make my point clear, sorry. I understand that the write method should block, and my code does this, it's just a question how it's implemented. Refactored to a write method: write( pcm, chunk) if( closing) close(); return(); snd_pcm_wait( pcm, timeout) // Blocks until there is a free frame in alsa buffer, // the same time as a blocking write would, using the // the same timer, but with a timeout option. if( timeout) // Underrun? Check status handle error. else write( pcm, chunk) // non-blocking The basic difference is that this code will never block indefinitely - thus making it it possible to remove the locks. Depending on the blocking, alsa write implementation it might also give a slightly better timing. But I shouldn't count on it. There was a time when pwlib and openh323 (the old names of ptlib and opal) used non blocking writes to the sound card plus software timers. the software timers were found to not be reliable enough to delay the write thread. Sometimes the delay was hundreds of milliseconds. So openh323 and pwlib were changed to use blocking writes, which gave much better audio performance. to change the operation of the write to be non blocking would have major architectural implications to opal. Let me help you. This won't happen. Agreed Coming back to the other issues. Unfortunately, I'm the victim of https://bugzilla.redhat.com/show_bug.cgi?id=481722, having a hard time to to test Ekiga. I'll do what I can, though. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Derek Smithies wrote: [ cut, replied earlier today...] I don't think this aspect of the the Opal design is a problem. The problem we are are trying to address is the reason for the buffering - why is there a 100ms delay??? Yes. I *think* I've seen five periods hardcoded somewhere... First of all: an overview. You state that the the hw buffering should be two periods, each period 30 or possibly 20 ms. You havn't mentioned sample rate(?), I assume for the moment that we agree on 8 kHz. This would be the interface between the codcc and the sound_alsa stuff. The 20/30 ms is a requirement from the codecs, implemented by the alsa read/write methods. Andrea has debug printouts from the settings when doing a voice call, see the thread A comparisom ALSA-PULSE a few days ago. Basically, this boils down to 8Khz, period size 160 frames == 20ms, hw buffer size = 800 frames = 5 periods == 100 ms. This is the sound_alsa /pulse emulated alsa interface settings. The buffer is way to large. And when I take a new look today by making a cat of the /proc/asound files I find rate: 44100, period_size: 8192 == 18.5 ms buffer_size: 16384 == 37 ms. This is the real stuff, the way pulse handles the alsa device. Bottom up: I'm not worried about the 44.1 kHz. Pulse is designed to convert our 8kHz stream to a 44.1 kHz one without any problems. But we should be aware of that what we see in /proc/asound is what pulse sets up against the hw; our settings vs pulse is another issue. I missed that. sound_alsa.cxx/pulse: I really need to look into the code here Here are a lot of hardcoded values, no symbolic constants... seems that the buffer is initially 4 periods (storedPeriods is initiated to 4). The setBuffer calls changes storedPeriods and thus buffer size - at a glance the code looks OK. So: a simple PTRACE in SetBuffers should reveal how the buffers are set. For the moment, I presume that this is how the codec's requirement on a specific sample rate is implemented. I need a whisky. Later on, I'll try refine the documentation for PsoundChannel. Answer: There are two entities that I have seen which can store audio to give you a delay. The jitter buffer, which can store seconds of audio. There are status variables in the jitter buffer which indicate how long it is buffering audio for. As I suspected. Thanks also for this. So basically we have network latency, jitter/echo cancellation buffer and the device/alsa buffer, all in total preferably in the 150 - 200 ms range. If there is no echo cancellation, the alsa buffer (if larger) could also be jitter buffer. But not if fancy things like echo cancellation should be performed (?). You may have the answer here. How much delay does the speex echo cancellor introduce ? No idea. Anyone, out here? But we seem to have is a 100 ms alsa hw buffer, which will be added to any other buffers involved, including the echo cancellation buffer. it is defaulted to.. The thing is that when looking at the alsa device from the operating system level (in the /proc filesystem) it's clear that the buffer is 5 periods * 20 ms = 100 ms (details in the thread initiated by Andrea). So something is not as expected... Is the simple truth that the alsa period size doesn't match the codec chunk size? But even if so, should it matter? suspicious Alsa probably introduces a delay/buffering of its own when you do alsa--pulse conversions. Can you repeat the above test on an older distro where the machine does not have pulse? Havn't any, and I havn't had any luck using sound in my VirtualBox VM:s either :-( Derek. --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
About the sound_alsa::write: As of today, both PsoundChannel abstract definition and the method comment in psound_alsa mentions a writeTimeout, with the obvious functionality. However, this is not implemented by the actual code. So: something is wrong, but what? Code? comment? Or? Seems that sound_alsa::read has the same problem. --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
yannick wrote: I've no clue if this documentation might help, still the pulse audio main author refers it as a guide: http://0pointer.de/blog/projects/guide-to-sound-apis.html Especially the section You want to know more about the safe ALSA subset? These kinds of hints are always welcome! And I can make us all happy when saying that both the current implementation and the changes discussed are within this safe set. --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Yes, the ptlib alsa driver needs to be reentrant. One thread could attempt to close the audio device while a second thread is reading/writing data from/to the alsa system. Just to sort his out for my simple mind, trying to understand the overall requirements. And with the idea that using threads is perfectly reasonable in this context :-) - Let's focus on the playback case, leaving any read aside (which refer to a different alsa device). - This should mean that while one thread (A) is closing it's playback device, another thread (B) starts writing to it. - Which means that thread B has been able to open the device before thread A finished closing it(?) - Which means that I am a little confused... is this as designed? What am I missing? --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Incoming call failure with 3.1.1
Damien Sandras wrote: Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit : Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: A gdb backtrace would be more useful. waiting for some kind of customer service, taking a backtrace (yes, same problem, trunk as of yesterday). --a [Thread 0x7fffe5953950 (LWP 4883) exited] [Thread 0x7fffe4f52950 (LWP 4882) exited] Program received signal SIGSEGV, Segmentation fault. 0x004a0ff9 in incoming_call_response_cb ( incoming_call_popup=0x7fffeca23520, response=0, data=0x7fffde80) at gui/main.cpp:1418 1418 call-hangup (); Missing separate debuginfos [cut] (gdb) thread apply all bt Thread 19 (Thread 0x7fffe3b7c950 (LWP 4869)): #0 0x0037b200b309 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x76ea0222 in PSyncPoint::Wait (this=0x7fffe804abc8) at ptlib/unix/tlibthrd.cxx:1468 #2 0x77ade927 in SIPEndPoint::SIP_PDU_Thread::Main ( this=0x7fffe804aa70) at /home/mk/src/rpms/build/opal-3.7.0/src/sip/sipep.cxx:1507 #3 0x76e9f570 in PThread::PX_ThreadStart (arg=0x7fffe804aa70) at ptlib/unix/tlibthrd.cxx:853 #4 0x0037b20073da in start_thread () from /lib64/libpthread.so.0 #5 0x0037b14e62bd in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x7fffedaa5950 (LWP 4857)): #0 0x0037b14dc886 in poll () from /lib64/libc.so.6 #1 0x0037b2c3ae08 in ?? () from /lib64/libglib-2.0.so.0 #2 0x0037b2c3b49d in g_main_loop_run () from /lib64/libglib-2.0.so.0 #3 0x0037bc248170 in ?? () from /usr/lib64/libORBit-2.so.0 #4 0x0037b2c60d44 in ?? () from /lib64/libglib-2.0.so.0 #5 0x0037b20073da in start_thread () from /lib64/libpthread.so.0 #6 0x0037b14e62bd in clone () from /lib64/libc.so.6 Thread 11 (Thread 0x7fffee4a6950 (LWP 4850)): #0 0x0037b14dc886 in poll () from /lib64/libc.so.6 #1 0x0037b2c3ae08 in ?? () from /lib64/libglib-2.0.so.0 #2 0x0037b2c3b49d in g_main_loop_run () from /lib64/libglib-2.0.so.0 #3 0x003b97c18d8d in ?? () from /usr/lib64/libebook-1.2.so.9 #4 0x0037b2c60d44 in ?? () from /lib64/libglib-2.0.so.0 #5 0x0037b20073da in start_thread () from /lib64/libpthread.so.0 #6 0x0037b14e62bd in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x7fffee745950 (LWP 4848)): #0 0x0037b14deaa2 in select () from /lib64/libc.so.6 #1 0x76e9f2c6 in PThread::PXBlockOnIO (this=0x9a01e0, handle=40, type=2, timeo...@0x7fffee744c20) at ptlib/unix/tlibthrd.cxx:952 #2 0x76e94c82 in PChannel::PXSetIOBlock (this=0x99fd58, type=PChannel::PXAcceptBlock, timeo...@0x7fffee744c20) at ptlib/unix/channel.cxx:119 #3 0x76e91340 in PSocket::os_accept (this=0x9a3200, listen...@0x99fd58, addr=0x7fffee744c70, size=0x7fffee744cfc) at ptlib/unix/socket.cxx:206 #4 0x76ebd720 in PTCPSocket::Accept (this=0x9a3200, sock...@0x99fd58) at ptlib/common/sockets.cxx:2359 #5 0x7779dc6a in OpalListenerTCP::Accept (this=0x99fd00, timeo...@0x7fffee744e90) at /home/mk/src/rpms/build/opal-3.7.0/src/opal/transports.cxx:638 #6 0x7779df44 in OpalListener::ListenForConnections (this=0x99fd00, thre...@0x9a01e0) at /home/mk/src/rpms/build/opal-3.7.0/src/opal/transports.cxx:472 #7 0x7779e76b in OpalListener::ListenForConnections_PNotifier::Call ( this=0x9a00e0, no...@0x9a01e0, extra=0) at /home/mk/src/rpms/build/opal-3.7.0/include/opal/transports.h:355 #8 0x76ecfe84 in PSimpleThread::Main (this=0x9a01e0) at ptlib/common/osutils.cxx:2031 #9 0x76e9f570 in PThread::PX_ThreadStart (arg=0x9a01e0) at ptlib/unix/tlibthrd.cxx:853 #10 0x0037b20073da in start_thread () from /lib64/libpthread.so.0 #11 0x0037b14e62bd in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x7fffee786950 (LWP 4847)): #0 0x0037b14deaa2 in select () from /lib64/libc.so.6 #1 0x76e90f2b in PSocket::Select (re...@0x7fffee785c70,
Re: [Ekiga-list] PTLIB alsa plugin status
Derek Smithies wrote:
Hi,
On Thu, 26 Feb 2009, Alec Leamas wrote:
Just to sort his out, trying to understand the overall requirements.
Which is a very reasonable thing to do, and it is a good question.
And with the idea that using threads is perfectly reasonable in this
context :-)
Excellent. This idea is very reasonable.
-Let's focus on the playback case, leaving any read aside (which
refer to a different alsa device).
Good idea.
- This should mean that while one thread (A) is closing it's
playback device, another thread (B) starts writing to it.
Yes, thread B is writing audio to the playback device. Thread B is
collecting the data off the jitter buffer,
decoding the audio using the specified codec,
sending the data to the playback device.
thread B is stopped by a bad write to the playback device. Typically,
a bad write to the playback device is caused by the playback device
being closed.
Hm... a write operation could be guaranteed to return in finite time
(using non-blocking io + snd_pcm_wait). So couldn't the close method
just mark the chanell as closing, leaving the dirty work to the writer
thread and thus avoiding the locks? (Which, otoh, really isn't a big
issue in this scenario). If required, opening could be handled in the
same way, I guess. This would also create the advantage that the thread
could process the jitter buffer data in parallel with the alsa output,
without the need to wait for the IO to complete. Wouldn't this give a
more accurate timing? Also, avoiding blocking io is a Good Thing IMHO.
Something like
while(1) {
if( closing)
close(); return
chunk = process_jitter_buffer();
snd_pcm_wait( pcm, timeout)
if( timeout)
// close or prepare...
else
snd_pcm_write( pcm , chunk) // non blocking
}
In the gui thread, user clicked hangup, and a close down thread is
created. This close down thread runs independantly of the gui (so does
not hold up the gui so responses work ok) and makes a call to
OpalCall::Clear() (which is a structure inside Opal) which then goes
through all the RTP threads (including audio) and closes the devices.
Since the Open, Close and Read/Write operations are atomic, there is
no possibility of one happening while the other happens and breaking
things.
The Opal thread which does the call to device Open then goes on to
launch the read/write threads. So read/writes don't run before the
device is open.
Thanks. So there are never any io operations in parallell, but parallell
io/close operations. I think I understand. A good explanation, BTW. I
might submit a patch with documentation to the plugin base class
clarifying this, basically what we have here.
I don't think this aspect of the the Opal design is a problem. The
problem we are are trying to address is the reason for the buffering -
why is there a 100ms delay???
Yes. I *think* I've seen five periods hardcoded somewhere...
Answer:
There are two entities that I have seen which can store audio to
give you a delay.
The jitter buffer, which can store seconds of audio.
There are status variables in the jitter buffer which indicate how
long it is buffering audio for.
As I suspected. Thanks also for this. So basically we have network
latency, jitter/echo cancellation buffer and the device/alsa buffer, all
in total preferably in the 150 - 200 ms range. If there is no echo
cancellation, the alsa buffer (if larger) could also be jitter buffer.
But not if fancy things like echo cancellation should be performed (?).
The sound device. Opal sets the sound device (on linux) to store 2
buffers of audio, which is (at most) 2 x 30ms.
One of the 30ms buffers is the buffer currently being written to the
sound device.
The second 30ms buffer is the next buffer to be written.
The buffering depth is set by the call to
devices/audiodev.cpp:bool PSoundChannel_EKIGA::SetBuffers (PINDEX
size, PINDEX count)
size is =480 (480 is for a 30ms long buffer. GSM uses 20ms.)
count is typically 2 (windows uses 3 or more)
It is possible that this call is not happening at the right time. I
doubt this, but you could verify this with a review of the logs.
If this command was being missed, the sound device would get whatever
value it is defaulted to..
The thing is that when looking at the alsa device from the operating
system level (in the /proc filesystem) it's clear that the buffer is 5
periods * 20 ms = 100 ms (details in the thread initiated by Andrea). So
something is not as expected... Is the simple truth that the alsa
period size doesn't match the codec chunk size? But even if so, should
it matter? suspicious
Derek.
--a
___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Derek Smithies wrote: Hi, On Wed, 25 Feb 2009, Alec Leamas wrote: Hi :-) Thanks for this info! As you state, this should work as long as they are instantiated in a proper way. And it's simple just to add some assertions to make sure that this is indeed the case. I still don't get why the device pointers needs locking. Is the overall Ekiga design such as there are several threads writing concurrently? Or is this a general requirement for the driver, for other scenarios the Ekiga? In other words , is the PTlib alsa driver defined as reentrant? yes, the ptlib alsa driver needs to be reentrant. One thread could attempt to close the audio device while a second thread is reading/writing data from/to the alsa system. It is not the overall Ekiga design that sets the requirment for coping with multiple threads - it is a the PTLib/OPAL design that sets the requirement for coping with multiple threads. The discussion topic of threads and too many threads and so on has occuppied many hours at conferences, and many emails, and is slightly tedious. A useful article on threads is found at: http://www.gotw.ca/publications/concurrency-ddj.htm In my view, the reason many programmers argue vehemently against threads is a combination of several factors *all their early programs were single threaded (e.g. hello_world) and so they developed the mindset of only knowing how to cope with 1 thread. *some programming styles (which are spaghetti like in nature) are torture to debug when threaded *many of the open source tools (in particular debuggers) don't handle threads well and make the whole codefix process too hard However, ptlib and opal are coded to a high degree of quality. There are still issues (device plugins) but these are getting fewer and fewer. Given the nature of voip and how voip works, I don't think any other model would work. Remember that opal is a library, and is used by people making hundreds of simultaneous calls. If you do propose a different way of doing things, will Hey! Have I said it's something wrong with threads? I have actually my background in tecknical systems, I was using threads long time before the word was used :-) I was just raising a question, and you have answered it. The PTlib alsa driver is defined as reentrant. I have no problems with this, once I understand it (it might be useful to document this fact in the PSoundChannel interface, I doubt I'm the only one which will stumble into this). But there *are* problems. A well behaved alsa driver should work better aganist pulse, other does. The hw buffer is way to large, 100 ms latency instead of ~50. No statistics. No rebuffering. But you have convinced on one, important point: it should be possible to enhance the driver with a set of smaller patches instead of a major rewrite. Such things are always easier. And I have absolutely no intention to look under the hood in the opal framwork. I just found Andreas' posting, and realized that I had some odd experience in alsa which might be useful. And after looking into this, I still feel that a better alsa interface in Ekiga is really important to get better latency and quality, both of which are crucial in a voip context. Or? BTW, are you the one which have an overall understanding the complete buffering scheme in Ekiga? --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE (long, addendum)
Derek Smithies wrote: Hi, Perhaps it's PTLib underneath it? I really don't know, I'm just throwing the idea out there! It is PTLib which contains the code to read from alsa. Surely, the ideal is not to go via ALSA, but have ptlib directly talk to pulse. Thus, we need to write a ptlib plugin for pulse audio. We know how ptlib plugins work. There are example plugins for alsa, esd, oss, sunaudio. The big question is writing a plugin for pulse. What is involved in writing code that talks directly to pulse ? Anyone know example code, or of the pulse api docs? Please don't refer me to docs which say just use alsa code. We are using alsa code, and that is why we are having this issue. Derek. I think you are right. For the reasons you mention, but also because the current alsa plugin is seriously flawed I made a short review very late yesterday. Among other things it's synchronized in a way that forces playback and record to wait for each others' I/O operations(!) With this said, I don't (yet) see any problems in understanding and using the external interface. These problems are within the alsa plugin. So: with limited resources we have a choice to either fix (i. e., major rewrite of) current alsa plugin, or make a pulse plugin. The latter is most likely easier. But then we leave platforms without pulse in the dark ages. So question is: do we need a working alsa plugin if we have a pulse one? Anyone? (let's take silence as a no :-) ) What disturbs me a little is the way the plugin interface seems to be, at least from the alsa example. Question is if there is a way to arrange event-driven I/O - current code is strictly polled. OTOH, we can live with that, for sure. But there might* be other hooks in the plugin interface not used today... we might need to backwards-engineer some docs... possibly expanding the plugin interface in a backwards-compatible way There is good pulse doc's on their website e. g., http://0pointer.de/lennart/projects/pulseaudio/doxygen/ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] PTLIB alsa plugin status
I made a short review of the read/write code in the PTLIB alsa plugin yesterday. In short: - Playback and record thread are synchronized in a way that forces the two streams to wait for each others I/O operations. - There is no rebuffering support. This means data underruns sounds worse than necessary. - Various minor remarks. I've filed a bug against ekiga with some more details : http://bugzilla.gnome.org/show_bug.cgi?id=572953 (pls don't file a bug on the formatting of the attachment...). In my opinion, it's not really worth to put much work on using the current alsa plugin. As long as it works, don't touch it... until it get's fixed in a proper way, possibly by using a pulse plugin instead. As for the latency discussion about alsa vs pulse: This review shows that anything will be much better than current alsa code... --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Derek Smithies wrote: Hi, Hi :-) Have you checked the bugzilla bug? There's some more meat on the bones (or however you prefer to say it down there ;-) On Tue, 24 Feb 2009, Alec Leamas wrote: - Playback and record thread are synchronized in a way that forces the two streams to wait for each others I/O operations. Yes - can someone test that ptlib alsa plugin works ok with this mutex removed?? It's not just a question of testing. This kind of problem must be handled by careful reading of code, to test all conditions possible when there are concurrent threads is not that simple. I think what should be done is to separate the recording and playback threads into separate objects, thus letting the compiler check that there are no critical zones. I also think the whole idea of a single channel must be interpreted as a facade for two more or less independent streams . They should not really share any data. But of course they share a lot of behaviour. - There is no rebuffering support. This means data underruns sounds worse than necessary. What is required to do rebuffering? Any code suggestions? Well, the basic thing is a separate thread feeding alsa started when alsa is started. The write routine just drops it's buffer to the thread through some kind of thread-safe mechanism, being blocked if there is no space in (a small) buffer. The thread is just waiting for alsa (snd:_pcm_wait). When started it normally transfers data from upstream (write), rebuffering as necessary if there is nothing else to send. In my opinion, it's not really worth to put much work on using the current alsa plugin. As long as it works, don't touch it... until it get's fixed in a proper way, possibly by using a pulse plugin instead. It is worth it. Alsa will be around for a long time. This is an opportunity for Ekiga people to contribute back to ptlibopal (libraries that are crucial to this project) OK, unless you provoke you don't get an answer... I actually share your opinion :-) As for the latency discussion about alsa vs pulse: This review shows that anything will be much better than current alsa code... The current alsa code works mostly.. it is close.. If there was some usable docs at alsa to explain what is not good, that would help. Anyone able to work out what is actually wrong in the alsa plugin? But we have 100 ms of hw buffer, roughly twice the size of other VOIP applications. There are open issues about the overall design, threads, objects etc. There are no quality metrics, we have no idea about things like bytes transferred, hard errors, soft errors, buffer usage etc. And Andreas' logs shows that the driver does not deliver data as expected. I don't want to blame anyone or so, but I think we must face the fact that there *are* problems, some of them requiring more than a point fix. As I said, take a look at the bug, there are some more details, despite the horrible formatting. And bear in mind that I'm certainly wrong from time to time. And that English isn't my native language, the nuances are a bit bit, well, rough now and then :-) Derek. --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE
Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22050 period_size : 5512 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min: 5512 period_event : 0 start_threshold : 22050 stop_threshold : 22050 silence_threshold: 0 silence_size : 0 boundary : 1445068800 I interpret delay as the time the calling routine has to sit waiting until there is space enough in the hardware buffer to write. Available reflects the numbers of (bytes? frames? samples?) available in the hw buffer for the sound card? Available_max: isn't this just the size of the hw buffer, in something( bytes? frames? samples?) i. e., the max number of entities which could be buffered? I am not sure I follow, since there are 2 patterns here alsa-pulse-alsa: delay = 0, avail_max=1764 and avail in between alsa direct: delay + avail = 1764, avail_max varies 1764 seems to be the size of the hw buffer. OK, this is haunting me. To get some peace of mind I need to sort this out, at least for myself. From the alsa docs: snd_pcm_status_get_avail_max: Get maximum number of frames available from a PCM status container after last snd_pcm_status http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#g3517971b4faf263cf91d146b5a07169d call. snd_pcm_status_get_avail: Number of frames ready to be read/written snd_pcm_status_get_delay: Delay is distance between current application frame position and sound frame position. It's positive and less than buffer size in normal situation, negative on playback underrun and greater than buffer size on capture overrun. --- So: avail is the number of frames the app (opal) can write to alsa. I doubt the other figures are relevant, and they might certainly be hard to define in the emulated alsa interface provided by pulse. Something is strange in the direct logs. Looking at the avail figures, its something like (after an initial phase): 459, 21, 446, 9, 443, 6, 446, 9, 483, 46, 444, 6, ...the pattern is obvious. I interpret it as something is out of phase between the app (opal?) and the alsa layer. Ideal, these figures should be something around 446, 444, 489, 444, ... ( application writes as soon as there is space to write one period). Possibly nothing is written when avail is small, but it's still not as it should be. BTW, the direct logs shows that avail_max don't excceds 1000 frames - it's roughly 800-900. If this is typical, it should be possible to decrease the buffer to 3 periods (1323 frames) without any significant underrun rate. But this is not important now. As for the alsa logs, the xruns are the endpoint when the avail drops in four steps: 1322, 882, 441, 0/xrun. This is almost exactly 3 periods, 2 periods, 1 period, xrun. It looks like the xrun occurs when avail drops to 0 - which is more than strange. Something is broken also here, I presume this is the same problem as in the direct case. It might be an idea to put some timestamps around the debug printouts just to make sure the very presence of them don't disturb the timing. I don't think so, but I once, when working with something similar, remember storing figures in a buffer only written now and then. It was most likely overkill. But just to be sure... I really wish I had more time. But as I see it, these printouts implies something strange in the current alsa handling, and that this propably ought to be sorted out before trying pulse. As usual, that's if I'm right...Isn't there any other alsa people out there? ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Trunk compile errors
Eugen Dedu wrote: Alec Leamas wrote: I'm running into troubles (below) compiling trunk. Is it just that it's broken, or is it something in my environment? I've tried both 7675 and 7677, same status. So I guess it's something by me. Anyone else with gcc 4.3? --alec ndpoints/sip-endpoint.cpp:1044: error: ‘class SIPHandler’ has no member named ‘GetTargetAddress’ endpoints/sip-endpoint.cpp:1065: error: no matching function for call to ‘Opal::Sip::EndPoint::GetDefaultRegisteredPartyName()’ /usr/include/opal/sip/sipep.h:704: note: candidates are: virtual SIPURL SIPEndPoint::GetDefaultRegisteredPartyName(const OpalTransport) endpoints/sip-endpoint.cpp:1044: error: ‘class SIPHandler’ has no member named ‘GetTargetAddress’ endpoints/sip-endpoint.cpp:1065: error: no matching function for call to ‘Opal::Sip::EndPoint::GetDef gui/main.cpp: In function ‘int main(int, char**, char**)’: gui/main.cpp:4628: error: cannot call member function ‘void PProcess::PreInitialise(int, char**, char**)’ without object Latest trunk for ptlib/opal/ekiga compile fine here. gcc 4.3.3. Tried 7681. Do you have trunk for ptlib/opal/ekiga? Yes. But I've been able to build against the official Fedora RPM:s for opal and ptlib There is something lurking around here, but I'm happy for the moment. I'm busy anyway, as you may have noticed ;-) ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE ( long)
Andrea wrote: Alec Leamas wrote: Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22050 period_size : 5512 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min: 5512 period_event : 0 start_threshold : 22050 stop_threshold : 22050 silence_threshold: 0 silence_size : 0 boundary : 1445068800 I attach more output. What you have seen so far was the log when ekiga plays the ring tone (by far the most damaged sound). When running the echo test the setup is different stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 1 rate : 8000 exact rate : 8000 (8000/1) msbits : 16 buffer_size : 800 period_size : 160 period_time : 2 tstamp_mode : NONE period_step : 1 avail_min: 160 period_event : 0 start_threshold : 1 stop_threshold : 800 silence_threshold: 0 silence_size : 0 boundary : 1677721600 And I cannot see any underrun at all. My echo test uses PCMA. It is possible that with a better codec (i.e. higher rate that 8000), we see them again. Don't really know how to test. I would say that the quality of the echo test with or without pulse is the same (but being only 8000 Hz, it is already not perfect and more difficult to judge). All my tests so far have been run in debug, so the speed of ekiga/opal/ptlib is already lower the release. The quality of the ring tone is though more or less the same. I will try to rerun everything in release. I have 2 points 1) Is the following true: ekiga-pulse gives bad audio quality because there are underruns. So, if for some connection there are no underruns (e.g. my echo test) then, the quality is not expected to be lower than alsa-direct, and we should not complain about pulse. Yes. And, whatever the problems are, I don't really think it's pulse. I think it's a problem how we handle alsa which is just not that visible today. 2) If underruns are (the) evil (or at least the biggest problem), then it would be good to print some indication of how close to the underrun we are. Does alsa provide that? Is it already part of my log? Yes, in the max_avail, see below. But bear in mind that it's not only a question about if underruns happens, it's also a question how they are handled. Actually, a correct working upper layer (opal...) should never allow alsa underruns, it should rebuffer (send previous data) if nothing else is available. It's sounds much better than an actual underrun. I still have not fully understood your comments about the values printed in the log. I need to get familiar with the terminology. And I have not yet checked for overruns when reading from the microphone. Andrea OK, as long you don't feel I occupy your territory, I'll make a try. After some reading my memories are coming back. But don't take what I say for granted, this *is* complicated. And if anyone who really knows alsa could review this, I would be more than happy... First of all: Alsa is basically, in all interfaces, concerned with frames. A frame is what the hardware handles in parallel. So in a mono stream, a frame is the same as a sample. In a stereo stream, a frame is two samples. The sample is S16_LE (signed 16 bit litte endian) i e, two bytes. So a frame is four bytes when sending the sound (stereo) and two bytes when talking as above (one channel, mono). The next entity is a period. A period is (in this context) a chunk of data transferred from user space to the alsa drivers' hw ringbuffer. The ringbuffer is normally an even number of periods. In the case above the period size is 160 frames. Since a frame is a sample ( mono), it's actually 320 bytes. But it's better to stick to frames, that's what alsa is all about. Last we have the hw bufffer. It's actually a ring buffer, where the application stores data, and the driver/interrupt routines fetches it and transfers it to the sound card. The overrun/underrun condtions is really what happens when the two ringbuffer pointers becomes equal, The period size is 160 frames. 1 frame takes 1/8000 seconds = 1000/8000 ms = period time 160/8 ms = 20 ms. The buffer above is actually 800/8 ms = 100 ms. This is quite a large buffer, with added network latency it might be to large. A goal is to keep the overall latency below 150 ms. The avail reflects the number of frames free to write in the hw buffer. When the buffer is full it's 0. When it's empty, it's the buffer size. The normal behaviour is that the application writes a period as soon as avail is = 1 period. Sending routines should somehow (blocking I/O, event-driven) be sure that avail is indeed = 1 period before it writes
Re: [Ekiga-list] A comparison ALSA-PULSE (long, addendum)
When looking for quality info (underruns, other errors etc) it's really a question of what opal provides. It's there all errors are handled, and hopefully logged somehow. *If* opal is the lib handling alsa, which is just a guess from my side. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE (long, addendum)
Mark T.B. Carroll wrote: Alec Leamas leamas.a...@gmail.com writes: When looking for quality info (underruns, other errors etc) it's really a question of what opal provides. It's there all errors are handled, and hopefully logged somehow. *If* opal is the lib handling alsa, which is just a guess from my side. Perhaps it's PTLib underneath it? I really don't know, I'm just throwing the idea out there! Indeed., grep tells it all. I have no more understanding than that the alsa functions are present there, and nowhere else. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE
Just some thoughts. Maybe it can provoke someone who knows better... If we had a pointer to cress-referenced code of the *dump routines we would be on much safer ground. It would be interesting to know the basic characteristics: sample rate, frame size, samplesize, period size...I remember something like cat /proc/asound/card0/pcm0p/sub0/hw_params, cat /proc/asound/card0/pcm0c/sub0/sw_params to get this info. I interpret delay as the time the calling routine has to sit waiting until there is space enough in the hardware buffer to write. Available reflects the numbers of (bytes? frames? samples?) available in the hw buffer for the sound card? Available_max: isn't this just the size of the hw buffer, in something( bytes? frames? samples?) i. e., the max number of entities which could be buffered? Isn't trigger time the time between each interrupt, basically the thing you are waiting for in snd_pcm_wait()? Is pulseaudio running with high nice value? Is the RTP jitter buffer a separate buffer, or is it using the alsa buffer for this purpose? Separate playback buffers is a major drawback, they add latency without being available to avoid underruns. Maybe it's possible to increase the alsa buffer and decrease the RTP playback buffer? Same latency, but less chance of underrun... There are real-world examples of hw buffers ~3600 bytes, with very acceptable latency (i. e., twice the buffer size here). But then that's the only buffers and it depends on samplerate etc. Alsa underruns behaves very differently depending on the calling routines. I don't know whether pulse handles underruns internally (they should!), or if it's a requirement for client code. Is this sorted out? Skype runs fine with pulseaudio drivers, so it's definitely possible... Andrea wrote: Hi, I've tried to compare the behaviour of ALSA when Ekiga uses the direct access vs going through pulse-alsa module. I've added some alsa print status in ptlib and the 2 files are the output when playing the ring-tone. I've used the 2 alsa calls to populate the log 1) snd_pcm_dump at the beginning 2) snd_pcm_status_dump after each write The first part is the same, but the status after each write is different DIRECT About to write 1764 len bytes state : RUNNING trigger_time: 9762.542972003 tstamp : 9762.543004130 delay : 430 avail : 1334 avail_max : 1334 PULSE About to write 1764 len bytes state : RUNNING trigger_time: 1235218239.552437000 tstamp : 0.00 delay : 0 avail : 441 avail_max : 1764 And then every now and then when running via pulse we generate an underrun About to write 1764 len bytes state : RUNNING trigger_time: 1235218239.552437000 tstamp : 0.00 delay : 0 avail : 0 avail_max : 1764 ### EPIPE state : XRUN trigger_time: 1235218239.552437000 tstamp : 0.00 delay : 0 avail : 0 avail_max : 1764 Does anybody know a bit what all those values mean? It seems that the underrun comes earlier that without pulse-alsa... I've tried to increase the size of the buffers in PSoundChannelALSA::SetBuffers() and the playback is much better, but that gives a bigger latency and delay when calling the echo test. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Handling of old-fashioned phone numbers
Damien Sandras wrote: [cut] If you do the back-end (as you have the most experience), we can do the GUI (for Ekiga 3.4). Does that sound like a good idea for you? Yes, I'll make a try, time permitting. And after a night's sleep, I've solved the UI issue :-). It's really just a question of accepting something like 0920-23456 in the ekiga URL window. When user clicks the Call button, the call is placed, and the complete URL is showed in the window. Errors handled as today. This means that the only new UI would be the ekiga-callto-config window, propably just yet another heading in Preferences. I'll add a screenshot of the configuration to the ekiga-callto homepage for reference. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE
Andrea wrote: Alec Leamas wrote: Just some thoughts. Maybe it can provoke someone who knows better... If we had a pointer to cress-referenced code of the *dump routines we would be on much safer ground. Sorry, I don't understand what you mean. Sorry, tapping the keyboard to fast. I mean a HTMl view of the soure code, where the different functions, definitions etc are clickable links (as created by e. g., Doxygen) It would be interesting to know the basic characteristics: sample rate, frame size, samplesize, period size...I remember something like cat /proc/asound/card0/pcm0p/sub0/hw_params, cat /proc/asound/card0/pcm0c/sub0/sw_params to get this info. It is at the beginning of the 2 files (the same): Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 1764 period_size : 441 period_time : 1 tstamp_mode : NONE period_step : 1 avail_min: 441 period_event : 0 start_threshold : 1 stop_threshold : 1764 silence_threshold: silence_size : 0 boundary : 1849688064 Trying to sort this out: I presume the buffer size is 1764 bytes, and there is two channels (i. e., stereo sound). This might mean that the buffer is just one period (441 frames/period * 2 samples/frame * 2 bytes/sample = 1764 bytes). This gives the buffer time 441/44100 = 1 ns = 10 ms. That would be a really small buffer, Given an overall requirement of a latency in the 100-150ms area, it's not important. It should be possible to have 2 or three periods without any trouble. If there's latency, it's somewhere else... in the network, or possibly in other sw buffers (RTP?). If I'm right. This needs a review! I'm far from certain. As a comparison this is what alsa's aplay uses when playing the same file Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22050 period_size : 5512 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min: 5512 period_event : 0 start_threshold : 22050 stop_threshold : 22050 silence_threshold: 0 silence_size : 0 boundary : 1445068800 aplay is an entirely different issue. They don't have to think about latency, just quality. So they make the buffers really large. A VOIP application must make a tradeoff between latency and quality. (And that's why it makes sense to adjust buffer size to network quality). I interpret delay as the time the calling routine has to sit waiting until there is space enough in the hardware buffer to write. Available reflects the numbers of (bytes? frames? samples?) available in the hw buffer for the sound card? Available_max: isn't this just the size of the hw buffer, in something( bytes? frames? samples?) i. e., the max number of entities which could be buffered? I am not sure I follow, since there are 2 patterns here alsa-pulse-alsa: delay = 0, avail_max=1764 and avail in between alsa direct: delay + avail = 1764, avail_max varies 1764 seems to be the size of the hw buffer Nor do I. I was just plain wrong in this, it seems. I have some experience with alsa, but have only used pulseaudio as user... stay tuned, I have som reading to do... Isn't trigger time the time between each interrupt, basically the thing you are waiting for in snd_pcm_wait()? Is pulseaudio running with high nice value? I use the default, no idea what to check here If you kill the daemon (pulseaudio --kill) and restart ir from a terminal (pulseaudio -D) you might get something like this if there's a problem:I: caps.c: Limited capabilities successfully to CAP_SYS_NICE. I: caps.c: Dropping root privileges. I: caps.c: Limited capabilities successfully to CAP_SYS_NICE. N: main.c: Called SUID root and real-time and/or high-priority scheduling was requested in the configuration. However, we lack the necessary privileges: N: main.c: We are not in group 'pulse-rt', PolicyKit refuse to grant us the requested privileges and we have no increase RLIMIT_NICE/RLIMIT_RTPRIO resource limits. N: main.c: For enabling real-time/high-priority scheduling please acquire the appropriate PolicyKit privileges, or become a member of 'pulse-rt', or increase the RLIMIT_NICE/RLIMIT_RTPRIO resource limits for this user. Is the RTP jitter buffer a separate buffer, or is it using the alsa buffer for this purpose? Separate playback buffers is a major drawback, they add latency without being available to avoid underruns. Maybe it's possible to increase the alsa buffer and decrease the RTP playback buffer? Same latency, but less chance of underrun... There are real-world examples of hw buffers ~3600 bytes, with very
Re: [Ekiga-list] A comparison ALSA-PULSE
It is at the beginning of the 2 files (the same): Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 1764 period_size : 441 period_time : 1 tstamp_mode : NONE period_step : 1 avail_min: 441 period_event : 0 start_threshold : 1 stop_threshold : 1764 silence_threshold: 0 silence_size : 0 boundary : 1849688064 Actually, I thnk I'm wrong. If the buffer is 1764 frames:. Time for 1 frame = 1/44100 sec = 1000/44100 ms. Time for buffer 1764 * 1000/44100= 40 ms. So, it really not that small, and increasing it is a problem. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE
[cut] Skype runs fine with pulseaudio drivers, so it's definitely possible... Maybe you could dump the setup used by skype, via some /proc/file... [...@hemulen ~]$ cat /proc/asound/card0/pcm0c/sub0/sw_params tstamp_mode: NONE period_step: 1 avail_min: 512 start_threshold: 512 stop_threshold: 2147483647 silence_threshold: 0 silence_size: 1342177280 boundary: 1342177280 [...@hemulen ~]$ cat /proc/asound/card0/pcm0p/sub0/hw_params access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 512 buffer_size: 2560 [...@hemulen ~]$ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE
Andrea wrote: Alec Leamas wrote: It is at the beginning of the 2 files (the same): Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 1764 period_size : 441 period_time : 1 tstamp_mode : NONE period_step : 1 avail_min: 441 period_event : 0 start_threshold : 1 stop_threshold : 1764 silence_threshold: 0 silence_size : 0 boundary : 1849688064 Actually, I thnk I'm wrong. If the buffer is 1764 frames:. Time for 1 frame = 1/44100 sec = 1000/44100 ms. Time for buffer 1764 * 1000/44100= 40 ms. So, it really not that small, and increasing it is a problem. Looking at the code in PSoundChannelALSA::Write(), where len=1764 /* the number of frames to read is the buffer length divided by the size of one frame */ r = snd_pcm_writei (os_handle, (char *) buf2 [pos], len / frameBytes); I would say 1764 is a number of bytes. The header file confirms this virtual PBoolean Write( const void * buf, /// Pointer to a block of memory to write. PINDEX len/// Number of bytes to write. ); There are really two things here: the total size of the hw buffer, and the size of a period. Data is transferred in chunks of one period, that's what's called buffer size in this code as I see it. The buffer is actually four periods, period time is 1 ns = 10ms. So everything seems to adjust to this model. To summarize, a period is 1764 bytes == buffer above, the total buffer is 1764 frames i. e., 7056 bytes. If I'm right, that is... After some serious googling I found a document I've used before. Maybe it could be of interest: http://www.stderr.org/doc/libasound2-doc/html/pcm.html . Note the hostname, it looks bad, but I actually trust these docs. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Trunk compile errors
I'm running into troubles (below) compiling trunk. Is it just that it's broken, or is it something in my environment? I've tried both 7675 and 7677, same status. So I guess it's something by me. Anyone else with gcc 4.3? --alec ndpoints/sip-endpoint.cpp:1044: error: ‘class SIPHandler’ has no member named ‘GetTargetAddress’ endpoints/sip-endpoint.cpp:1065: error: no matching function for call to ‘Opal::Sip::EndPoint::GetDefaultRegisteredPartyName()’ /usr/include/opal/sip/sipep.h:704: note: candidates are: virtual SIPURL SIPEndPoint::GetDefaultRegisteredPartyName(const OpalTransport) endpoints/sip-endpoint.cpp:1044: error: ‘class SIPHandler’ has no member named ‘GetTargetAddress’ endpoints/sip-endpoint.cpp:1065: error: no matching function for call to ‘Opal::Sip::EndPoint::GetDef gui/main.cpp: In function ‘int main(int, char**, char**)’: gui/main.cpp:4628: error: cannot call member function ‘void PProcess::PreInitialise(int, char**, char**)’ without object ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Hacking: ekiga-callto update (last for a while...)
There is yet another version of ekiga-callto. From the changelog: * Sat Feb 21 2009 Alec Leamas lea...@bredband.net 0.2.19-1 - From my perspective: feature complete. - New homepage: http://mumin.dnsalias.net/ekiga-callto.html - New default configuration based on country as looked up from IP address. - New mini application for cut paste numbers in documents, email etc. - Further improved number recognition - Got rid of the 'find-dist' installation kludge rpm. The major things is the web page (screenshots, at last!) and the new dial clipboard. Would be nice with a link from ekiga.org... I don't plan any more work with this for the moment. Cheers, --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Handling of old-fashioned phone numbers
Basically, I think this should not reside in a frontend like ekiga-callto, which is more like a prototype. There are some good reasons to integrate into the core application: - To make this functionality available also on Windows it's propably much better to have it in Ekiga. A dependency on gtk-python is actually not that nice in this environment (as opposed to Linux, where it's readily available from repos). - Integrating it into Ekiga should make it possible to use the same logic for numbers stored in PIM databases (e. g., Evolution) which typically lacks countrycode. ( see http://wiki.ekiga.org/index.php/API::GmContact::PhoneNumbers) - Configuration becomes easier when the list of available accounts is could be accessed. - The many steps and windows used by frontend + Ekiga is, taken together, not a really nice UI. To integrate it into current UI should give a much better user experience. The ability to handle the everyday numbers we have around us is actually crucial for everyday use. This is an area where Skype shines. So should also Ekiga! The najor drawback as I see it is to introduce still more configuration, based on the idea that numbers should be expanded in a country-based context. On the other hand default values could be provided which should be fine for almost all users. And the idea that numbers are local to a country is intuitive and should not pose a problem for users. And, of course, there is work. But having a prototype is a start. I see most of the difficulties in modifying the UI. Actually, I havn't any real ideas about this... ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Resolved: Thompson ST585 v6 router stability problems
I have the the subject router, a decision from my ISP I have to live with. I've really never been able achieve long-term stability with Ekiga, the registration has dropped after some time (~1 hour?). Another strange symptom has been the Edit Acoount Dialog. When invoked and saved with the same data, my registrar became Unregistered. Repeating the Edit/Save procedure, still w same data, turned the registrar to Registered. To make it work at all I after a while found out that the router has an Application Layer Gateway (ALG) for sip (thanks, Damien!). Using this means to disable stun, and rely on the the routers' sip management. And indeed, I could both call place and recieve calls. But no long-term stability. The problem seems to be the ALG, it's just buggy according to a lot of threads out there. Furhermore, it cannot be disabled with the v6 version of the firmware. It was possible in some older versions(!) Solution: go around the ALG by using another port than 5060 (I use 5080). Enable stun. Setup port forwarding (a k a Game Sharing...) to port 5080/UDP in the router. Done. BTW: this means that it's not a trivial setup decision to use the ALG just because it's there. This à propos the discussion about automatic recognition of sip-aware routers in the initial configuration wizard. Cheers --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Hacking: ekiga-callto: Yet another update
Ive dropped new RPM:s and tarball at ftp://mumin.dnsalias.net/pub/ekiga-callto. From the changelog: * Sat Feb 14 2009 Alec Leamas lea...@bredband.net 0.2.13-1 - New dialog for editing ambiguous numbers before calling. - Installed new testpage: http://mumin.dnsalias.net/numberformats.html - Improved number identification. - New versioning scheme, svn-versioned tarballs. - Suse (11.2) and Mandriva (2009.9) RPM support. The big news is a dialog giving user a chance to review the guess the system does. The number recognition has also improved a lot. There s also a single javascript file. This should work on Windows, will convert phone numbers into links. However, this means that users are on their own to find an application which can handle the callto: URL:s. Unfortunately, Ekiga as of today is not such an application. Feedback welcome. As always, need help with localisations. I'm also interested in URL:s containing phone numbers which are not handled correct. Thr README (big update) has information about new build instructions, perfomance etc. Cheers! --alec Eugen Dedu wrote: About the phone number format, is http://wiki.ekiga.org/index.php/API::GmContact::PhoneNumbers useful to you? ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Hacking: ekiga-callto: update
Yes. Thanks! --alec Eugen Dedu wrote: About the phone number format, is http://wiki.ekiga.org/index.php/API::GmContact::PhoneNumbers useful to you? Eugen Alec Leamas wrote: I have updated the packages, fixed numerous installation bugs, added Ubuntu installation docs ( in README). Same url: ftp://mumin.dnsalias.net/pub/ekiga-callto contains RPM:s and tar.gz Bear in mind that mumin.dnsalias.net is a home server, with a limited amount of 9's describing the availability ;-) Retry, that is, when it doesn't work. Answers below yannick wrote: Le samedi 07 février 2009 à 10:29 +0100, Damien Sandras a écrit : Le vendredi 06 février 2009 à 00:08 +0100, Alec Leamas a écrit : I've been busy some evenings creating scripts to make ekiga calls from web pages. I am at a point where I can click on any phone number in a web page to make ekiga call this number. Unfortunately, most real phone numbers are not given in the standard, international form. So I have faced the need to add missing countrycodes for numbers missing it. This implies a need to configure countrycode etc for the users. There is a simple form for this. If anyone is interested, the scripts are available as rpm and tar.gz packages at ftp://mumin.dnsalias.net/pub/ekiga-callto/ . Also, if anyone think it's worth the effort, some new localisations would be really nice. The README covers how to use the stuff. Thanks for this work! Yannick, could we link to this from the wiki together with the Ekiga.net web buttons? Here it is: http://wiki.ekiga.org/index.php/Ekiga.net_VoIP_service_subscription#Ekiga_Web_integration Alec, I've a few questions for you: 1- Can you provide a screenshot ;) Well, I could, but it's sort of meaningless.. just a normal webpage. The trick is the clickability of the page, but this is not easy to show in a screenshot. But I see what you mean, thinking...have to think more. Maybe three pages, one without links, one with, and a third showing ekiga calling the link? 2- Is there an official (i mean public) way to contact you for contributors? It's possible to upload things to ftp://mumin.dnsalias.net/pub/upload. And there is leamas.alec(at)gmail.com 2- It this application portable to windows? (Mac OS 3- What is the coding langage used ? Most likely, yes., it's python and javascript. MacOS shoud definitely be OK. Not all window users have python in place, I guess. Among other things, it would be really nice with some more localisations. Just grab the po/en_GB.po file, fill in the 12 lines and submit them to me... ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] ekiga-list Digest, Vol 31, Issue 19
Rick Bergfeld wrote: [cut] On Mon, 2009-02-09 at 21:09 -0600, Rick Bergfeld wrote: I'm not sure what has changed. I was running FC8 with Ekiga 2.01 (I think) and I didn't have any issues. I upgraded to FC10 and Ekiga 3.0.2 and now I Could not register sip: error and Could not connect to remote host. I think maybe I'm missing somthing? I just did the default install of FC10, so maybe something is missing. Any help is appreciated. link to output.txt http://docs.google.com/Doc?id=dcz353zw_84pndt2fq As a first port of call I'd check the firewall settings. I forgot to mention that I disabled the firewall completely on FC10, but did not reboot. I also tried setting up port forwarding on my Linksys router. I had some similar issues as well, they were related to the combination of Ekiga and my router. Long story short: disabling stun made this to work for me. There is no UI for this, you have to patch directly into the gconf database: install the gconf-editor package, use it from Application | System Tools The path is /apps/ekiga/nat/disable_stun. If your router works like mine, disable all forwarding etc and let it handle sip in its own way. HTH --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Hacking: ekiga-callto: update
I have updated the packages, fixed numerous installation bugs, added Ubuntu installation docs ( in README). Same url: ftp://mumin.dnsalias.net/pub/ekiga-callto contains RPM:s and tar.gz Bear in mind that mumin.dnsalias.net is a home server, with a limited amount of 9's describing the availability ;-) Retry, that is, when it doesn't work. Answers below yannick wrote: Le samedi 07 février 2009 à 10:29 +0100, Damien Sandras a écrit : Le vendredi 06 février 2009 à 00:08 +0100, Alec Leamas a écrit : I've been busy some evenings creating scripts to make ekiga calls from web pages. I am at a point where I can click on any phone number in a web page to make ekiga call this number. Unfortunately, most real phone numbers are not given in the standard, international form. So I have faced the need to add missing countrycodes for numbers missing it. This implies a need to configure countrycode etc for the users. There is a simple form for this. If anyone is interested, the scripts are available as rpm and tar.gz packages at ftp://mumin.dnsalias.net/pub/ekiga-callto/ . Also, if anyone think it's worth the effort, some new localisations would be really nice. The README covers how to use the stuff. Thanks for this work! Yannick, could we link to this from the wiki together with the Ekiga.net web buttons? Here it is: http://wiki.ekiga.org/index.php/Ekiga.net_VoIP_service_subscription#Ekiga_Web_integration Alec, I've a few questions for you: 1- Can you provide a screenshot ;) Well, I could, but it's sort of meaningless.. just a normal webpage. The trick is the clickability of the page, but this is not easy to show in a screenshot. But I see what you mean, thinking...have to think more. Maybe three pages, one without links, one with, and a third showing ekiga calling the link? 2- Is there an official (i mean public) way to contact you for contributors? It's possible to upload things to ftp://mumin.dnsalias.net/pub/upload. And there is leamas.alec(at)gmail.com 2- It this application portable to windows? (Mac OS 3- What is the coding langage used ? Most likely, yes., it's python and javascript. MacOS shoud definitely be OK. Not all window users have python in place, I guess. Among other things, it would be really nice with some more localisations. Just grab the po/en_GB.po file, fill in the 12 lines and submit them to me... --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Hacking: ekiga-callto
There are some best effort screenshots at ftp://mumin.dnsalias.net/pub/ekiga-callto/shots/. Anyone having a better idea how to present it? --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Revisited: visual feedback when making dbus/cli calls
Sorry for threading issues; I cleaned my mailbox I've just compiled trunk. The status is somewhat different here: - When making a cli/dbus call the number is now displayed in the main window. Fixed, that is ;-) - I'm using metacity at the monent. In 3.0.2, when the main window was opened due to a call, it was always on top ; if it already was open and hidden it remained hidden, though. In trunk, even when a fresh window is opened, it is often opened *under* the window which has the focus (i. e., the window that initiated the call). In other words, it has become worse. I'll look at it, but this is really something for a WM wizard. Anyone out there? --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Revisited: visual feedback when making dbus/cli calls
I'm currently using the Dbus interface to establish Ekiga calls. The basic functionality seems fine, but to my understanding there are some glitches: - When making an ekiga.Call(uri)/ekiga.Show() sequence, the call is indeed placed to the uri. Also, if there is no open window, a main window is opened. In this the hook is off (red phone), but the uri called is not reflected in the dialpad entry up-left. Net result from a visual, user perspective is some kind of invisible call (besides the history, where it eventually is listed). - If the window is open already, it's likely to be hidden by other windows. In this situation the Show() method seems to do nothing. I think it would be more intuitive if the window popped up after a Show() call instead of staying hidden in this situation. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Revisited: visual feedback when making dbus/cli calls
Damien Sandras wrote: Le samedi 07 février 2009 à 16:36 +0100, Alec Leamas a écrit : I'm currently using the Dbus interface to establish Ekiga calls. The basic functionality seems fine, but to my understanding there are some glitches: - When making an ekiga.Call(uri)/ekiga.Show() sequence, the call is indeed placed to the uri. Also, if there is no open window, a main window is opened. In this the hook is off (red phone), but the uri called is not reflected in the dialpad entry up-left. Net result from a visual, user perspective is some kind of invisible call (besides the history, where it eventually is listed). - If the window is open already, it's likely to be hidden by other windows. In this situation the Show() method seems to do nothing. I think it would be more intuitive if the window popped up after a Show() call instead of staying hidden in this situation. Is that Ekiga 3.0 ? 3.0.2 You are free to propose patches. I will commit them... It's quite a step to dive into the code. But I *am* tempted. Stay tuned... ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Hacking: ekiga-callto
I've been busy some evenings creating scripts to make ekiga calls from web pages. I am at a point where I can click on any phone number in a web page to make ekiga call this number. Unfortunately, most real phone numbers are not given in the standard, international form. So I have faced the need to add missing countrycodes for numbers missing it. This implies a need to configure countrycode etc for the users. There is a simple form for this. If anyone is interested, the scripts are available as rpm and tar.gz packages at ftp://mumin.dnsalias.net/pub/ekiga-callto/ . Also, if anyone think it's worth the effort, some new localisations would be really nice. The README covers how to use the stuff. Cheers, --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Visual feedback when doing ekiga -c calls
As of now, if a running ekiga instance makes a call started through ekiga -c # there is no visual feedback at all. Somehow, when I use this, it creates a little uneasy feeling (despite the obvious audio feedback). Also, if I lose connection to my account (and thus can't receive or place calls), there is still the same green spot in the tray... Thinking about it, from a user perspective there is really four states: - No dialtone i.e., no registered account. - Idle, ready... - Connecting - Connected I think it would make sense to reflect all these states in the tray icon. Nothing like Skype, which throws up it's main window when a call is initiated - it just irritating when you work in another application. Maybe just change colour on the green spoot in the tray. Just to illustrate what I have in mind: - No dialtone: Red spot, tooltip No account registered - Idle: Green spot, tooltip Diamondcard account registered or Two accounts registered - Connecting: yellow spot, tooltip Connecting to ...@sip.provider.com - Connected: as today, tooltip Connected to 111...@sip.provider.com Or? --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Visual feedback when doing ekiga -c calls
Le mercredi 04 février 2009 à 13:27 +0100, Alec Leamas a écrit : As of now, if a running ekiga instance makes a call started through ekiga -c # there is no visual feedback at all. Somehow, when I use this, it creates a little uneasy feeling (despite the obvious audio feedback). Also, if I lose connection to my account (and thus can't receive or place calls), there is still the same green spot in the tray... Thinking about it, from a user perspective there is really four states: - No dialtone i.e., no registered account. - Idle, ready... - Connecting - Connected I think it would make sense to reflect all these states in the tray icon. Nothing like Skype, which throws up it's main window when a call is initiated - it just irritating when you work in another application. Maybe just change colour on the green spoot in the tray. Just to illustrate what I have in mind: - No dialtone: Red spot, tooltip No account registered - Idle: Green spot, tooltip Diamondcard account registered or Two accounts registered - Connecting: yellow spot, tooltip Connecting to 111 sip provider com - Connected: as today, tooltip Connected to 11 sip provider com Or? There is maybe a place for that in the main GUI rather than in the systray (the systray reflect your status already, mixing both status and connectivity will be overkill). I'm thinking about the quality meter at the bottom. It is always visible and except when you're in a call, it is pretty useless. No dialtone, idle and connecting can fill this useless, while connected would be where the quality info will be shown. Regards, Am I missing something? When initiating a call, does the systray icon reflect that we are trying to connect i. e., is there any visual feedback at all when doing a ekiga -c #? As I see it, a call attempt which is not connected is more os less invisible for the user(?). If I lose my account connection, is there any feedback then? Personally, I feel this is more important. I autostart ekiga, which makes sense, if you are logged in you want to be available. But as of now, I really have to check (by opening main window) now and then if the line is OK. Is a green light representing a broken phone reasonable? Bottom line: user perspective really is really four states, but the current systray icon only reflects two: Connected or not. To use the main window is better than nothing. But to have to open it just to check if there is a connection is not that good. And, as I said, the ekiga -c mechanism is most likely invoked when you work in some other application, and to show the main window then (like Skype) is just little irritating (?) Reading what I've written it feels a little sharp. Hope you don't mind, English is not my native language, the nuances are not lost... I want to be friendly, but writes like God knows what. Have mercy with me :-) --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Visual feedback when doing ekiga -c calls
yannick wrote: Le mercredi 04 février 2009 à 15:08 +0100, Alec Leamas a écrit : Yes, I'm missing something: the called state, waiting to pick up the phone. Embarrasing. But not a problem, in this case there is a powerful visual representation :-) What you missed is this: you can turn the green tray icon to red or orange using the main GUI. This is called presence. Green=on line orange=busy red=do not disturb Ah, I'm on Fedora. And after following the presence discussion for Fedora I've put it aside. I get your point. But my point(s) are still valid: there is a need to somehow give some visual feedback when ekiga is making a call initiated by other means than the main window. And there is also a need to communicate the possible fact that we are not available at all when all accounts are down. With this said, the green/red idea was obviously not that great...maybe opening the main window is what's left. Other sip-phones does it, it can't be that bad... ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Newbie, help: Account mgmt problems
I've isolated the problem. In a fresh install, right after the configuration wizard, clear the Authentication User field for the Ekiga account. After this an exit + restart corrupts the Ekiga account data. Trying to sort things out, I ran ekiga under valgrind. There is a lot of Conditional jump or move depends on uninitialised value(s); I presume these are irrelevant. Besides these, Ekiga runs clean when the Authentication User field is non-empty. However, the following two errors occurs iff the Authentication User field is empty i. e., when the data corruption occurs. Signing off, --alec ==27886== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) ==27886==at 0x3906C0E65C: (within /lib64/libpthread-2.9.so) ==27886==by 0x3A68F4230B: PSocket::os_sendto(void const*, int, int, sockaddr*, int) (in /usr/lib64/libpt.so.2.4.4) ==27886==by 0x3A68F66A08: PIPDatagramSocket::WriteTo(void const*, int, PIPSocket::Address const, unsigned short) (in /usr/lib64/libpt.so.2.4.4) ==27886==by 0x3A68F6CDC4: PMonitoredSockets::WriteToSocket(void const*, int, PIPSocket::Address const, unsigned short, PMonitoredSockets::SocketInfo const, int) (in /usr/lib64/libpt.so.2.4.4) ==27886==by 0x3A68F6CEF3: PMonitoredSocketBundle::WriteToBundle(void const*, int, PIPSocket::Address const, unsigned short, PString const, int) (in /usr/lib64/libpt.so.2.4.4) ==27886==by 0x3A68F6C91E: PMonitoredSocketChannel::Write(void const*, int) (in /usr/lib64/libpt.so.2.4.4) ==27886==by 0x3A68F46327: PIndirectChannel::Write(void const*, int) (in /usr/lib64/libpt.so.2.4.4) ==27886==by 0x3A68F46911: PChannel::WriteString(PString const) (in /usr/lib64/libpt.so.2.4.4) ==27886==by 0x3A69B9B2AF: SIP_PDU::Write(OpalTransport, OpalTransportAddress const, PString const) (in /usr/lib64/libopal.so.3.4-beta4) ==27886==by 0x3A69BA0C43: SIPTransaction::Start() (in /usr/lib64/libopal.so.3.4-beta4) ==27886==by 0x3A69BB6153: SIPHandler::WriteSIPHandler(OpalTransport) (in /usr/lib64/libopal.so.3.4-beta4) ==27886==by 0x3A69BB62C8: SIPHandler::WriteSIPHandler(OpalTransport, void*) (in /usr/lib64/libopal.so.3.4-beta4) ==27886== Use of uninitialised value of size 8 ==27886==at 0x390EC7F0B3: (within /usr/lib64/libstdc++.so.6.0.10) ==27886==by 0x390EC85BC6: std::ostreambuf_iteratorchar, std::char_traitschar std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::_M_insert_intunsigned long(std::ostreambuf_iteratorchar, std::char_traitschar , std::ios_base, char, unsigned long) const (in /usr/lib64/libstdc++.so.6.0.10) ==27886==by 0x390EC85DF6: std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::do_put(std::ostreambuf_iteratorchar, std::char_traitschar , std::ios_base, char, unsigned long) const (in /usr/lib64/libstdc++.so.6.0.10) ==27886==by 0x390EC98D5B: std::ostream std::ostream::_M_insertunsigned long(unsigned long) (in /usr/lib64/libstdc++.so.6.0.10) ==27886==by 0x4BD1FF: Opal::Account::edit() (in /usr/bin/ekiga) ==27886==by 0x390AC0B7DC: g_closure_invoke (in /lib64/libgobject-2.0.so.0.1800.3) ==27886==by 0x390AC214BC: (within /lib64/libgobject-2.0.so.0.1800.3) ==27886==by 0x390AC22B67: g_signal_emit_valist (in /lib64/libgobject-2.0.so.0.1800.3) ==27886==by 0x390AC23092: g_signal_emit (in /lib64/libgobject-2.0.so.0.1800.3) ==27886==by 0x3569831ACA: gtk_widget_activate (in /usr/lib64/libgtk-x11-2.0.so.0.1400.5) ==27886==by 0x356973658C: gtk_menu_shell_activate_item (in /usr/lib64/libgtk-x11-2.0.so.0.1400.5) ==27886==by 0x3569737FD4: (within /usr/lib64/libgtk-x11-2.0.so.0.1400.5) chaitanya mehandru wrote: If you can do this,it may help to resolve: - ekiga-config-tool --clean - ekiga-config-tool --fix-permissions - ekiga-config-tool --clean-schemas - ekiga-config-tool --install-schemas --Disable the STUN support while running the configuration wizard; --Make 2 new sip accounts and while running the configuration wizard,register with one of the new users. --Add a sip account to ekiga with authentication user being the same as user name. If this doesn't help, probably there might be some library to be installed to keep the values in the respective fields. I have been able to run Ekiga 3.0.2 with H264 enabled on Ubuntu 8.10,8.04 without any similar issues. On Fri, Jan 30, 2009 at 5:08 PM, Alec Leamas leamas.a...@gmail.com mailto:leamas.a...@gmail.com wrote: Thanks for your reply! First of all I should add that I'm on Fedora/X86_64. Did the ekiga-config-tool thing. After a reinstall, and disabling the stun server, there is only two accounts: my ekiga account and an account at sip.mysecretary.net http://sip.mysecretary.net. Situation after a Chat | Quit + restart: - The data for both accounts is corrupted (password moved to Authentication User, Password + Timeout set to random values). - The account is presented
Re: [Ekiga-list] Newbie, help: Account mgmt problems
Done: http://bugzilla.gnome.org/show_bug.cgi?id=570024 Cheers, --alec Damien Sandras wrote: Le vendredi 30 janvier 2009 à 18:50 +0100, Alec Leamas a écrit : Thanks for your reply! As for the data corruption issues, this seems to happen iff I leave the field Authentication User blank in the Edit Account dialog. If I fill this (with same vale as User) data is not corrupted and Ekiga runs fine. Ah, please report this to bugzilla.gnome.org. There might be a bug in that case! ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Newbie, help: Account mgmt problems
Thanks for your reply! First of all I should add that I'm on Fedora/X86_64. Did the ekiga-config-tool thing. After a reinstall, and disabling the stun server, there is only two accounts: my ekiga account and an account at sip.mysecretary.net. Situation after a Chat | Quit + restart: - The data for both accounts is corrupted (password moved to Authentication User, Password + Timeout set to random values). - The account is presented as Registered despite that it isn't logged in at the server (I can verify this on the server side for the mysecretary account). - Invoking the Account | Edit Account dialog with correct, unchanged data effectively toggles the account between Registered and Unregistered. - With data OK, successfully logged in to mysecretary.net and making a Chat | Quit the server does not understand that the client is disconnected (still presented as present/logged in by server). Possibly a server issue? - The server eventually understands that the client has disconnected after the timeout specified fot the account. I have a feeling that there are at least two things here: data corruption and presence mgmt. But, I'm a newbie and should thus not have any feelings ;-) Damien Sandras wrote: Le jeudi 29 janvier 2009 à 13:45 +0100, Alec Leamas a écrit : Oops, forgot... Ekiga 3.0.2 on Fedora 10, updated as of today. The install is a clean install from Fedora's repositories. Try purging the configuration totally (ekiga-config-tool --clean) and start from scratch. There is no known bug corrupting the accounts data. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Newbie, help: Account mgmt problems
Thanks for your reply! As for the data corruption issues, this seems to happen iff I leave the field Authentication User blank in the Edit Account dialog. If I fill this (with same vale as User) data is not corrupted and Ekiga runs fine. So, I don't have any blocking errors for the time being. But the presence stuff still seems a little odd e. g., Ekiga displays an account as Registered despite a login failure. I've started a thread on Fedora Forum to see if there are Fedora users having similar problems. No luck so far. I'll try your recipe, and look a little more into this. Not this evening, though ;-) Stay tuned.. --alec chaitanya mehandru wrote: If you can do this,it may help to resolve: - ekiga-config-tool --clean - ekiga-config-tool --fix-permissions - ekiga-config-tool --clean-schemas - ekiga-config-tool --install-schemas --Disable the STUN support while running the configuration wizard; --Make 2 new sip accounts and while running the configuration wizard,register with one of the new users. --Add a sip account to ekiga with authentication user being the same as user name. If this doesn't help, probably there might be some library to be installed to keep the values in the respective fields. I have been able to run Ekiga 3.0.2 with H264 enabled on Ubuntu 8.10,8.04 without any similar issues. On Fri, Jan 30, 2009 at 5:08 PM, Alec Leamas leamas.a...@gmail.com mailto:leamas.a...@gmail.com wrote: Thanks for your reply! First of all I should add that I'm on Fedora/X86_64. Did the ekiga-config-tool thing. After a reinstall, and disabling the stun server, there is only two accounts: my ekiga account and an account at sip.mysecretary.net http://sip.mysecretary.net. Situation after a Chat | Quit + restart: - The data for both accounts is corrupted (password moved to Authentication User, Password + Timeout set to random values). - The account is presented as Registered despite that it isn't logged in at the server (I can verify this on the server side for the mysecretary account). - Invoking the Account | Edit Account dialog with correct, unchanged data effectively toggles the account between Registered and Unregistered. - With data OK, successfully logged in to mysecretary.net http://mysecretary.net and making a Chat | Quit the server does not understand that the client is disconnected (still presented as present/logged in by server). Possibly a server issue? - The server eventually understands that the client has disconnected after the timeout specified fot the account. I have a feeling that there are at least two things here: data corruption and presence mgmt. But, I'm a newbie and should thus not have any feelings ;-) Damien Sandras wrote: Le jeudi 29 janvier 2009 à 13:45 +0100, Alec Leamas a écrit : Oops, forgot... Ekiga 3.0.2 on Fedora 10, updated as of today. The install is a clean install from Fedora's repositories. Try purging the configuration totally (ekiga-config-tool --clean) and start from scratch. There is no known bug corrupting the accounts data. ___ ekiga-list mailing list ekiga-list@gnome.org mailto:ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Newbie, help: Account mgmt problems
I have a setup with four SIP providers, the last most used. Once configured, everything works OK. But if I exit Ekiga, and later restart it, the account data for my last account is corrupted: The password has became Authentication user, the timeout is some random value. In this situation my client obviously can connect to the sip provider, I can verify this on the server side. However, the Accounts window still presents the account as Registered. If I rectify the data it works again. However, if I invoke the Edit dialog for this account and closes it without changing anything (data OK) the account becomes Unregistered. Invoking Edit Account again, closing with same data restores the account to Registered In short, a mess. Has anyone out there a clue to what's going on? --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Revisited: Newbie, help: Account mgmt problems
Please igonre my previous post - there was a single, really bad typo. I have a setup with four SIP providers, the last most used. Once configured, everything works OK. But if I exit Ekiga, and later restart it, the account data for my last account is corrupted: The password has became Authentication user, the timeout is some random value. In this situation my client obviously can't connect to the sip provider, I can verify this on the server side. However, the Accounts window still presents the account as Registered. Needless to say, I can't call using the provider. If I rectify the data it works again. However, if I invoke the Edit dialog for this account and closes it without changing anything (data OK) the account becomes Unregistered. Invoking Edit Account again, closing with same data restores the account to Registered In short, a mess. Has anyone out there a clue to what's going on? --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Newbie, help: Account mgmt problems
Oops, forgot... Ekiga 3.0.2 on Fedora 10, updated as of today. The install is a clean install from Fedora's repositories. yannick wrote: 3. Le jeudi 29 janvier 2009 à 13:21 +0100, Alec Leamas a écrit : I have a setup with four SIP providers, the last most used. Once configured, everything works OK. But if I exit Ekiga, and later restart it, the account data for my last account is corrupted: The password has became Authentication user, the timeout is some random value. In this situation my client obviously can connect to the sip provider, I can verify this on the server side. However, the Accounts window still presents the account as Registered. If I rectify the data it works again. However, if I invoke the Edit dialog for this account and closes it without changing anything (data OK) the account becomes Unregistered. Invoking Edit Account again, closing with same data restores the account to Registered In short, a mess. Has anyone out there a clue to what's going on? --alec What's your platform? How did you installed? What is the ekiga version ? ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] No Echo Test response: STUN Problem with Thomson ST585 V6 ADSL router
Checking my logs... is it so that I hijacked Terry's thread and thus, after submitting a bug seemingly closing the thread, caused his question to remain unsolved? If so, I really have to apologize. --alec Terry Barnaby wrote: [snip] You could report a bug concerning the impossibility to try sound events. I am about to try and get a Windows Version (3.0.2) of Ekiga working for my mother in laws computer. I suspect that her router will also support SIP as it is relatively new. How can I disable the STUN support in Ekiga in Microsoft Windows so that Ekiga will work with a router that implements automatic SIP port forwarding ? Cheers Terry ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Newbie configuration experiences...
First of all: I actually got Ekiga 3.0.1 running to the point of a working call to the echo service on my Fedora 10 box which is a Good Thing. You are doing a great job! However, being a newbie I found it a little harder than it ought to be. If it's an objective that Ekiga should be easy to setup, here are some remarks: Sound device selection. - There is no support for testing the output devices (Play test sound) for output nor ringing device in the device selection menu. I think it should. - On my Fedora box, some selections makes Ekiga really weird e. g., it's possible to connect but not to disconnect. The bad thing is that there is no user feedback indicating that this is a problem with the sound devices, which makes it hard to figure out what's going on. NAT traversal and router setup: - My router is a NAT router with the dreaded Symmetric NAT. There *is* an error message when Ekiga is started which basically says that I have to configure the router manually. The crucial term Symmetric NAT is *not* mentioned in this message. I finally learned to start ekiga with debug output, and grep for 'stun' to reveal this fact. This should really easier, the information about Symmetric NAT should be displayed to the user. - Once I understood that my router was doing Symmetric NAT I configured port forwarding according to the docs (dynamic, triggered ports is not properly handled by my Thomson router). I came to a point with working connect/disconnect but no sound. - After some more reading, I understood that the stunnel stuff was in the way. So I needed to disable stunnel. There are no switches in the UI for this, and even in gconf there is no Use stunnel option. What I did was to set the stunnel host to a non-existing value. This created a lot of error messages, and a working Ekiga... This should be easier and more straightforward IMHO. The issue to setup Ekiga with a router doing symmetric NAT couldn't really be out of the box, I understand that. But I still think this process could be easier with better error messages and configuration options. Or, maybe, a Symmetric NAT wizard? Last but not least, I shouldn't have taken the time to write this unless I really appreciate what you are doing... --Alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Newbie configuration experiences...
Terry Barnaby wrote: [snip] Indeed... there is no need to enable port forwarding for the RTP ports for the ST585 router. Thanks! This is nice, but also creates a strange feeling about this router.. is there anything else it forwards without letting me know? I second that. One thing you may find, if you are using a Thomson ST 585 V6 router as I am, is that once you have disabled STUN then the ST 585 appears to automatically open the RTP ports for you. ie you don't need to manually set the router to port forward them, at least on my setup ... It seems to also forward them to the correct host (I have a number of systems behind the ST586). See my message No Echo Test response: STUN Problem with Thomson ST585 Cheers Terry ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] No Echo Test response: STUN Problem with Thomson ST585 V6 ADSL router
Damien Sandras wrote: Le vendredi 19 décembre 2008 à 22:54 +, Terry Barnaby a écrit : Hi, [snip] It appears that the ST585 is doing something special when it sees SIP protocol requests and forwarding the ports automatically, but the use of the STUN system messes this up. If this is the case, It would be useful to be able to disable STUN support in the standard user preferences dialogs of the Ekiga app and to note this in the error dialog window. Also I guess it may be possible to fix the STUN support if there is an issue here ... It is one of the things I want to work on for 3.20 : detect if STUN is required or if the router supports SIP. OK, this would resolve most issues mentioned in my first post labeled Newbie configuration experience. In the short run, updating the docs with how to disable stunnel support would make sense. Also, please note my remarks about the sound device selection (I know, the post is long, sorry...) --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] No Echo Test response: STUN Problem with Thomson ST585 V6 ADSL router
Damien Sandras wrote: [snip] You could report a bug concerning the impossibility to try sound events. Done, http://bugzilla.gnome.org/show_bug.cgi?id=565196 --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
