Re: [Ekiga-devel-list] News on debian snapshots
Not at the moment. The current configure line looks like --disable-static --enable-plugins --disable-oss --enable-v4l2 --disable-avc --disable-v4l but as I'm pretty sure DC cameras are also supported by v4l I may well disable it at some point in the future as with libv4l support most linux cameras are supported through v4l2 in ekiga. So if I understand correctly, avc and dc PTLIB plugins are in most cases superseded by v4l2 PTLIB plugin with libv4l? In this case I should remove these 2 plugins! Uh... I don't think either AVC or DC are V4L2 comptatible. Ah, my bad. Are they supported through the gstreamer plugins? Peter ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] News on debian snapshots
Hi there! On Thu, 26 Feb 2009 16:29:00 +0100, Eugen Dedu wrote: Peter Robinson wrote: * The AVC plugin is not compiled anymore (the package is still there, but will be removed soon). Please tell if you really need it. It seems to me that ptlib needs libraw1394-dev v1, but v1 is not available anymore on debian unstable and very soon in testing either. Here is the error I receive with v2 installed: Just as an FYI Fedora has had AVC disabled for quite a while (since well before ekiga 3) and had no bug reports or complaints. Have they had disabled DC too? I need it disable it too... Could ptlib be adjusted to libraw1394-dev v2? Not that I use the AVC and DC plugins [1], but IMHO disabling both is a regression. Thx, bye, Gismo / Luca Footnotes: [1] I primarily use Ekiga (and any VoIP software) for phone call, but indeed I have a DC camcorder which I could use with Ekiga :-) pgpm8v65Anez9.pgp Description: PGP signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] News on debian snapshots
Luca Capello wrote: Hi there! On Thu, 26 Feb 2009 16:29:00 +0100, Eugen Dedu wrote: Peter Robinson wrote: * The AVC plugin is not compiled anymore (the package is still there, but will be removed soon). Please tell if you really need it. It seems to me that ptlib needs libraw1394-dev v1, but v1 is not available anymore on debian unstable and very soon in testing either. Here is the error I receive with v2 installed: Just as an FYI Fedora has had AVC disabled for quite a while (since well before ekiga 3) and had no bug reports or complaints. Have they had disabled DC too? I need it disable it too... Could ptlib be adjusted to libraw1394-dev v2? Not that I use the AVC and DC plugins [1], but IMHO disabling both is a regression. For avc, there is a compile problem, as shown previously. If someone could propose patches... (use debian unstable, download last ptlib and compile) For dc, as shown in http://bugzilla.gnome.org/show_bug.cgi?id=545017, v2 does not compile, and v1 is not available anymore in debian (http://packages.qa.debian.org/libr/libraw1394.html). (I hope I am not wrong.) -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Ekiga release preparation
Hi, From http://live.gnome.org/TwoPointTwentyfive: 02/03: rc due 09/03: Hard Code Freeze: no source code changes can be made without approval from the release-team. 16/03: final tarball due Will we release ekiga? If yes, will we make a release for 02/03, and the final one for 09-16/03? (solution I personally prefer, because the 02/03 version could be checked by people) Bugs tagged 3.20: http://bugzilla.gnome.org/buglist.cgi?product=ekigabug_status=NEWbug_status=REOPENEDbug_status=ASSIGNEDbug_status=UNCONFIRMEDtarget_milestone=3.20 -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Ekiga release preparation
On Fri, Feb 27, 2009 at 4:05 PM, Eugen Dedu eugen.d...@pu-pm.univ-fcomte.fr wrote: Hi, From http://live.gnome.org/TwoPointTwentyfive: 02/03: rc due 09/03: Hard Code Freeze: no source code changes can be made without approval from the release-team. 16/03: final tarball due Will we release ekiga? If yes, will we make a release for 02/03, and the final one for 09-16/03? (solution I personally prefer, because the 02/03 version could be checked by people) It would be good if we could have a release before 02/03 seeing as we never had the last scheduled 3.1.1 release that was planned for a couple of weeks ago. Peter ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-list] direct IP to IP SIP call without SIP registrar, not working in 3.x
Did you both tried sip:anyth...@ip ? On Fri, Feb 27, 2009 at 8:37 AM, Dave Higton dave.hig...@nice.com wrote: Patrick Lee wrote: Not sure any one has asked this question before. I was able to make call without registering any SIP registrar in Ekiga ver 2.x. No need to create SIP account. Just type sip:192.168.1.34 (the remote IP address) and the call was setup. And the remote client could be x-lite. But NOT with ver 3.x, the same syntax gave me no response. It seems like I have to create a SIP account first. My environment is a complete isolated network so I simply can't register in ekiga.net for SIP account. And there is some other SIP clients so I have to stick with SIP protocol. I know SIP registration is a proper SIP operation. But I love ekiga as it allows pt-to-pt call without setting up a SIP server. But not true for ver 3.x. Any solution ? It may be worth mentioning that I have the same situation (no SIP access to the outside world, therefore Ekiga cannot possibly register to anything), the same requirement to do VoIP across our own LAN (only), and the same problem. Dave NICE CTI Systems UK Limited (NICE) is registered in England under company number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 2ZP. Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately. Monitoring: NICE may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- %---% Michel memeteau Blog 0.2 : http://memeteau.free.fr Fixe : 0974763294 Mobile : 0624808051 VOIP | Visio: sip:freeche...@ippi.fr sip%3afreeche...@ippi.fr jabber/GTalk : xmpp:freeche...@jabber.fr xmpp%3afreeche...@jabber.fr ___ 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] direct IP to IP SIP call without SIP registrar, not working in 3.x
are you suggesting sip:hostn...@dest_ip where hostname can be anything and dest_IP is the remote endpoint IP address ? I tried sip:a...@192.168.1.34, it returned nothing, no connecting tone nor busying tone ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] call failure
Hi, I have replied and sent the logs but they are too big and wait for moderator approval. Cheers Michael On February 27, 2009 at 2:30 AM Eugen Dedu eugen.d...@pu-pm.univ-fcomte.fr wrote: Michael Stockenhuber wrote: Hi all, I am using ekiga from current debian experimental (3.0.1) to connect to ekiga on a windows vista machine (cough,cough). It connects often from boith sides, but afetr 30 s or so connection goes to zero transfer rate. When I phone 500 it works reasonably well, but with 520 the callback dies more or less immediately. I had the same problem with linux-windows. Could you give us a -d 4 output? (See wiki, debugging). For crash: could you provide a gdb stack bt? -- Eugen ___ 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] direct IP to IP SIP call without SIP registrar, not working in 3.x
I am on Windows platform, and I found similar problem in h.323 as well. Look like something wrong with the windows executable. But ver 2.x works fine on my windows box. On Fri, Feb 27, 2009 at 5:12 PM, chaitanya mehandru chinku.li...@gmail.com wrote: Just for your info, I have been using ekiga 3.0.2 on Ubuntu hardy and I can connect using - sip:a...@w.x.y.z. I hear busy tone,connecting tone ringing tone. On Fri, Feb 27, 2009 at 2:29 PM, Patrick Lee leepatrick...@gmail.com wrote: are you suggesting sip:hostn...@dest_ip where hostname can be anything and dest_IP is the remote endpoint IP address ? I tried sip:a...@192.168.1.34, it returned nothing, no connecting tone nor busying tone ___ 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] direct IP to IP SIP call without SIP registrar, not working in 3.x
On Fri, Feb 27, 2009 at 07:37 (-), Dave Higton wrote: Patrick Lee wrote: Not sure any one has asked this question before. I was able to make call without registering any SIP registrar in Ekiga ver 2.x. No need to create SIP account. Just type sip:192.168.1.34 (the remote IP address) and the call was setup. And the remote client could be x-lite. But NOT with ver 3.x, the same syntax gave me no response. It seems like I have to create a SIP account first. My environment is a complete isolated network so I simply can't register in ekiga.net for SIP account. And there is some other SIP clients so I have to stick with SIP protocol. I know SIP registration is a proper SIP operation. But I love ekiga as it allows pt-to-pt call without setting up a SIP server. But not true for ver 3.x. Any solution ? It may be worth mentioning that I have the same situation (no SIP access to the outside world, therefore Ekiga cannot possibly register to anything), the same requirement to do VoIP across our own LAN (only), and the same problem. Dave, Have you tried connecting to h323:192.168.1.34 (or IP as appropriate)? It works for me both on a LAN and over a wan with 3.0.[12] and 3.1.0. Regrettably, I have other show-stopper problems, but that's another thread. Patrick, you say you have other SIP clients, but will the h323: thing work for you in your ekiga-to-ekiga work? Jim ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] direct IP to IP SIP call without SIP registrar, not working in 3.x
Le vendredi 27 février 2009 à 08:56 -0400, Jim Diamond a écrit : I know SIP registration is a proper SIP operation. But I love ekiga as it allows pt-to-pt call without setting up a SIP server. But not true for ver 3.x. Any solution ? I reshaped our wiki page about NATs, did you read this troubleshooting? http://wiki.ekiga.org/index.php/Ekiga_behind_a_NAT_router#I_have_2_Ekiga_behind_a_NAT_using_STUN:_they_can.27t_communicate And this configuration setup if you're sure to only use Ekiga exclusively inside the LAN: http://wiki.ekiga.org/index.php/Ekiga_behind_a_NAT_router#How_to_disable_STUN_with_Ekiga_3.3F @Damien, What is the command line to enable STUN back using Ekiga 3.x? ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Le vendredi 27 février 2009 à 09:37 +0100, Alec Leamas a écrit : 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. 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? 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 -- Me joindre en téléphonie IP / vidéoconférence ? sip:yann...@ekiga.net Logiciel de VoIP Ekiga : http://www.ekiga.org http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] direct IP to IP SIP call without SIP registrar, not working in 3.x
Le vendredi 27 février 2009 à 15:57 +0100, yannick a écrit : Le vendredi 27 février 2009 à 08:56 -0400, Jim Diamond a écrit : I know SIP registration is a proper SIP operation. But I love ekiga as it allows pt-to-pt call without setting up a SIP server. But not true for ver 3.x. Any solution ? I reshaped our wiki page about NATs, did you read this troubleshooting? http://wiki.ekiga.org/index.php/Ekiga_behind_a_NAT_router#I_have_2_Ekiga_behind_a_NAT_using_STUN:_they_can.27t_communicate And this configuration setup if you're sure to only use Ekiga exclusively inside the LAN: http://wiki.ekiga.org/index.php/Ekiga_behind_a_NAT_router#How_to_disable_STUN_with_Ekiga_3.3F @Damien, What is the command line to enable STUN back using Ekiga 3.x? gconftool-2 -s /apps/ekiga/general/nat/stun_server stun.ekiga.net --type=string This is only needed in 3.0 because in 3.20, there is a new option in the preferences window. -- _ 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
Re: [Ekiga-list] [ekiga engine] api availability and documentation
Le vendredi 27 février 2009 à 08:53 +0100, Giampaolo Armellin a écrit : I’ve read on Ekiga web site that the engine is available to be used in other projects. Nevertheless, I couldn’t find any reference to a SDK, API or documents. May anyone tell me where that information can be found? I'm not sure it is completely doxygenified, but you could try generating the help from the headers. -- _ 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
Re: [Ekiga-list] call failure
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
Re: [Ekiga-list] WG: Connect to a LifeSize HD System
Le jeudi 26 février 2009 à 09:11 +0100, Stefan Stoedtgen a écrit : Hi Ekiga List! I'm using Ekiga 3.0.2 stable under Windows XP, SP2 with a logitech QuickCam. I tried to connect to a LifeSize Room HD Conferencing Unit (www.lifesize.com) which uses SIP and H323 for communication. The connection seems to be established, but then, it breaks down. I attached you the error.log. Can you help me with this problem? Thanks for your Support! Breakdown = crash ? Because I see nothing wrong. Perhaps you should try H.323. -- _ 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
Re: [Ekiga-list] Incoming call failure with 3.1.1
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? -- _ 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] Documentation on NAT UDP timeouts
http://wiki.ekiga.org/index.php/Ekiga_behind_a_NAT_router#I_can_make_calls.2C_but_if_I_let_Ekiga_running_after_some_time_I_can.27t_receive_any_calls mentions, ip_conntrack_udp_timeout ip_conntrack_udp_timeout_stream but sysctl from a 2.6.26 kernel instead has, net.netfilter.nf_conntrack_udp_timeout = 30 net.netfilter.nf_conntrack_udp_timeout_stream = 180 net.ipv4.netfilter.ip_conntrack_udp_timeout = 30 net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180 which I'm guessing are what I have to adjust on my system. (Changing the first pair seems to automatically change the second.) I'm having difficulty finding any setting in trunk's Ekiga GUI or gconf stuff corresponding to `you can configure each account to refresh the registration every 180 seconds'. Mark ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] ekiga-snapshot-config-tool Debian packaging looks for wrong schema file
Le jeudi 26 février 2009 à 15:49 +0100, Eugen Dedu a écrit : Mark T.B. Carroll wrote: ekiga-snapshot-config-tool --install-schemas gives, I/O warning : failed to load external entity /etc/gconf/schemas/ekiga.schemas Failed to open `/etc/gconf/schemas/ekiga.schemas': No such file or directory My version of the ekiga-snapshot Debian package is 0-20090214-1 which instead has a /usr/share/gconf/schemas/ekiga-snapshot.schemas file. upstream, please apply the patch attached. Do you think it is still useful to distribute this small script? Is it better to just inform people about the gconftool command line to remove their ekiga configuration? I applied all your patches. I can't really answer your question because I don't have a precise opinion about this. -- _ 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
Re: [Ekiga-list] ekiga-snapshot-config-tool Debian packaging looks for wrong schema file
On Fri, Feb 27, 2009 at 17:01 (+0100), Damien Sandras wrote: Le jeudi 26 février 2009 à 15:49 +0100, Eugen Dedu a écrit : Mark T.B. Carroll wrote: ekiga-snapshot-config-tool --install-schemas gives, I/O warning : failed to load external entity /etc/gconf/schemas/ekiga.schemas Failed to open `/etc/gconf/schemas/ekiga.schemas': No such file or directory My version of the ekiga-snapshot Debian package is 0-20090214-1 which instead has a /usr/share/gconf/schemas/ekiga-snapshot.schemas file. upstream, please apply the patch attached. Do you think it is still useful to distribute this small script? Is it better to just inform people about the gconftool command line to remove their ekiga configuration? I applied all your patches. I can't really answer your question because I don't have a precise opinion about this. For those of us who don't use gnome and gconf, it is better to have some way other than the non-existent gconftool. Cheers. Jim ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Contacting admins at accou...@ekiga.net (?)
Dear list, my apologies for the kind of off-topic post. I am trying to retrieve a forgotten password and either the Forgot Password Service does not send any replies to my address, or for some other reason they don't reach their destination. I've never successfully used Ekiga to be honest since some of the camera models I tried to attach in my old laptop where not cooperating with Ubuntu. Therefore I was stuck in Skype. Now I have a new machine with a built-in webcam which works out-of-the-box under Ubuntu II / 64-bit. If some admin follows this list, please could you help me to retrieve my _very_ old and forgotten password? I've already mailed at accounts_at_ekiga_dot_net but I suspect that there might be a (generic) problem with mails comming from @ekiga.net reaching my mailbox!? My apologies again. Thanks, Nikos signature.asc Description: This is a digitally signed message part ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] ekiga-snapshot-config-tool Debian packaging looks for wrong schema file
Jim Diamond wrote: On Fri, Feb 27, 2009 at 17:01 (+0100), Damien Sandras wrote: Le jeudi 26 février 2009 à 15:49 +0100, Eugen Dedu a écrit : Mark T.B. Carroll wrote: ekiga-snapshot-config-tool --install-schemas gives, I/O warning : failed to load external entity /etc/gconf/schemas/ekiga.schemas Failed to open `/etc/gconf/schemas/ekiga.schemas': No such file or directory My version of the ekiga-snapshot Debian package is 0-20090214-1 which instead has a /usr/share/gconf/schemas/ekiga-snapshot.schemas file. upstream, please apply the patch attached. Do you think it is still useful to distribute this small script? Is it better to just inform people about the gconftool command line to remove their ekiga configuration? I applied all your patches. I can't really answer your question because I don't have a precise opinion about this. For those of us who don't use gnome and gconf, it is better to have some way other than the non-existent gconftool. The problem is that this script has 131 lines and replaces only about 5 lines of code (rm -rf $HOME/.gconf/...; gconf --shutdown etc.) But we will wait until everybody is ok with this removal. -- Eugen ___ 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)
Same problem here using Ubuntu Hardy and Wednesday's trunk on three separate computers. Incoming calls segfault every time on each 3.1.1 build. Outgoing calls are ok. 5...@ekiga.net echo test works but all incoming calls segfault. Craig Albrecht Taylor University Broadcasting Inc Indiana, USA -Original Message- From: ekiga-list-boun...@gnome.org [mailto:ekiga-list-boun...@gnome.org] On Behalf Of ekiga-list-requ...@gnome.org Sent: Friday, February 27, 2009 10:58 AM To: ekiga-list@gnome.org Subject: ekiga-list Digest, Vol 31, Issue 59 Send ekiga-list mailing list submissions to ekiga-list@gnome.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.gnome.org/mailman/listinfo/ekiga-list or, via email, send a message with subject or body 'help' to ekiga-list-requ...@gnome.org You can reach the person managing the list at ekiga-list-ow...@gnome.org When replying, please edit your Subject line so it is more specific than Re: Contents of ekiga-list digest... Today's Topics: 1. Re: direct IP to IP SIP call without SIP registrar, not working in 3.x (Jim Diamond) 2. Re: direct IP to IP SIP call without SIP registrar, not working in 3.x (yannick) 3. Re: PTLIB alsa plugin status (yannick) 4. Re: direct IP to IP SIP call without SIP registrar, not working in 3.x (Damien Sandras) 5. Re: [ekiga engine] api availability and documentation (Damien Sandras) 6. Re: call failure (Damien Sandras) 7. Re: WG: Connect to a LifeSize HD System (Damien Sandras) 8. Re: Incoming call failure with 3.1.1 (Damien Sandras) -- Message: 1 Date: Fri, 27 Feb 2009 08:56:27 -0400 From: Jim Diamond jim.diam...@acadiau.ca Subject: Re: [Ekiga-list] direct IP to IP SIP call without SIP registrar, not working in 3.x To: Ekiga mailing list ekiga-list@gnome.org Message-ID: 20090227125627.ga26...@tux.acadiau.ca Content-Type: text/plain; charset=us-ascii On Fri, Feb 27, 2009 at 07:37 (-), Dave Higton wrote: Patrick Lee wrote: Not sure any one has asked this question before. I was able to make call without registering any SIP registrar in Ekiga ver 2.x. No need to create SIP account. Just type sip:192.168.1.34 (the remote IP address) and the call was setup. And the remote client could be x-lite. But NOT with ver 3.x, the same syntax gave me no response. It seems like I have to create a SIP account first. My environment is a complete isolated network so I simply can't register in ekiga.net for SIP account. And there is some other SIP clients so I have to stick with SIP protocol. I know SIP registration is a proper SIP operation. But I love ekiga as it allows pt-to-pt call without setting up a SIP server. But not true for ver 3.x. Any solution ? It may be worth mentioning that I have the same situation (no SIP access to the outside world, therefore Ekiga cannot possibly register to anything), the same requirement to do VoIP across our own LAN (only), and the same problem. Dave, Have you tried connecting to h323:192.168.1.34 (or IP as appropriate)? It works for me both on a LAN and over a wan with 3.0.[12] and 3.1.0. Regrettably, I have other show-stopper problems, but that's another thread. Patrick, you say you have other SIP clients, but will the h323: thing work for you in your ekiga-to-ekiga work? Jim -- Message: 2 Date: Fri, 27 Feb 2009 15:57:19 +0100 From: yannick sev...@free.fr Subject: Re: [Ekiga-list] direct IP to IP SIP call without SIP registrar, not working in 3.x To: Ekiga mailing list ekiga-list@gnome.org Message-ID: 1235746639.15492.22.ca...@achille Content-Type: text/plain; charset=utf-8 Le vendredi 27 f?vrier 2009 ? 08:56 -0400, Jim Diamond a ?crit : I know SIP registration is a proper SIP operation. But I love ekiga as it allows pt-to-pt call without setting up a SIP server. But not true for ver 3.x. Any solution ? I reshaped our wiki page about NATs, did you read this troubleshooting? http://wiki.ekiga.org/index.php/Ekiga_behind_a_NAT_router#I_have_2_Ekiga_behind_a_NAT_using_STUN:_they_can.27t_communicate And this configuration setup if you're sure to only use Ekiga exclusively inside the LAN: http://wiki.ekiga.org/index.php/Ekiga_behind_a_NAT_router#How_to_disable_STUN_with_Ekiga_3.3F @Damien, What is the command line to enable STUN back using Ekiga 3.x? -- Message: 3 Date: Fri, 27 Feb 2009 16:02:56 +0100 From: yannick sev...@free.fr Subject: Re: [Ekiga-list] PTLIB alsa plugin status To: Ekiga mailing list ekiga-list@gnome.org Message-ID: 1235746976.15492.26.ca...@achille Content-Type: text/plain; charset=utf-8 Le vendredi 27 f?vrier 2009 ? 09:37 +0100, Alec Leamas a ?crit : Derek Smithies wrote: Hi, On Fri, 27 Feb 2009, Alec Leamas
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] Incoming call failure with 3.1.1 (Damien Sandras)
Just tried today's trunk. Still segfault on all inbound calls on fully updated Ubuntu Hardy using these build instructions: http://wiki.ekiga.org/index.php/Compile_your_own_SVN_version_of_Ekiga_on_Ubuntu Is this method still accurate? A build created last week (or was it earlier this week? Cant remember) using this method would not indicate the presence of incoming call but outgoing call worked. Today's trunk indicates incoming call, but get immediate segfault when clicking accept. What I am hoping for is a working build that includes the celt ultra-low delay codec. I do have 0.5.2 celt installed since opal wouldn't configure with celt enabled unless I previously install celt on the computer. Craig Albrecht WBCL Radio Network Fort Wayne, Indiana USA Taylor University ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Contacting admins at accou...@ekiga.net (?)
Le vendredi 27 février 2009 à 17:13 +0100, Nikos Alexandris a écrit : Dear list, my apologies for the kind of off-topic post. I am trying to retrieve a forgotten password and either the Forgot Password Service does not send any replies to my address, or for some other reason they don't reach their destination. Hi, I coded the ekiga.net web interface. I just tested the forgot password service and it works with my address. I suspect something between ekiga.net server and your mail box blocks the email. (maybe a antispam service?). If you give me your username, i'll post a mail directly to you with your password. Best regards, Yannick I've never successfully used Ekiga to be honest since some of the camera models I tried to attach in my old laptop where not cooperating with Ubuntu. Therefore I was stuck in Skype. Now I have a new machine with a built-in webcam which works out-of-the-box under Ubuntu II / 64-bit. If some admin follows this list, please could you help me to retrieve my _very_ old and forgotten password? I've already mailed at accounts_at_ekiga_dot_net but I suspect that there might be a (generic) problem with mails comming from @ekiga.net reaching my mailbox!? My apologies again. Thanks, Nikos ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- Me joindre en téléphonie IP / vidéoconférence ? sip:yann...@ekiga.net Logiciel de VoIP Ekiga : http://www.ekiga.org http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] direct IP to IP SIP call without SIP registrar, not working in 3.x
Le vendredi 27 février 2009 à 16:24 +0100, Damien Sandras a écrit : Le vendredi 27 février 2009 à 15:57 +0100, yannick a écrit : Le vendredi 27 février 2009 à 08:56 -0400, Jim Diamond a écrit : I know SIP registration is a proper SIP operation. But I love ekiga as it allows pt-to-pt call without setting up a SIP server. But not true for ver 3.x. Any solution ? I reshaped our wiki page about NATs, did you read this troubleshooting? http://wiki.ekiga.org/index.php/Ekiga_behind_a_NAT_router#I_have_2_Ekiga_behind_a_NAT_using_STUN:_they_can.27t_communicate And this configuration setup if you're sure to only use Ekiga exclusively inside the LAN: http://wiki.ekiga.org/index.php/Ekiga_behind_a_NAT_router#How_to_disable_STUN_with_Ekiga_3.3F @Damien, What is the command line to enable STUN back using Ekiga 3.x? gconftool-2 -s /apps/ekiga/general/nat/stun_server stun.ekiga.net --type=string This is only needed in 3.0 because in 3.20, there is a new option in the preferences window. Ok, thx. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Contacting admins at accou...@ekiga.net (?)
Just a thank you to Yannick for his support. I am on-line :-) Cheers, Nikos signature.asc Description: This is a digitally signed message part ___ 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
[Ekiga-list] list manager: could we have this on gmane.org?
Hello, This is intended for whoever is maintaining this mailing list. I was wondering if this list can be made available via gmane.org. That way people can read this list as newsgroup on nntp server of gmane as well (list subscription would still be required). I am new to this list and I am not sure if this has been requested or looked into before. Regards and thanks. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
On Fri, 27 Feb 2009, 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? This is a great link. There are some non optimal components in the alsa plugin, or rather, things that are not safe. I have some sadness at this - the alsa plugin in ptlib was copied from the example they provided. Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: de...@indranet.co.nz ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
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) Later on, I'll try refine the documentation for PsoundChannel. cool. Email any docs you have to me directly, and I will add them to the inline documentation in the ptlib sources. Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: de...@indranet.co.nz ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] call failure
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 vista_reduced.txt.gz Description: application/gzip ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] direct IP to IP SIP call without SIP registrar, not working in 3.x
Actually there are some Tandberg endpoints in my LAN. Tandberg MXP 1700 - H323 and IP supported Tandberg E20 - SIP only In my network there is no NAT, actually some equipments are in the same subnet, i.e. no routing involved. With Ekiga 2.x, SIP connection with both Tandberg endpoints are ok, but the video codec supported is only H.261. With Ekiga 3.x, neither H323 nor SIP call was gone through. In my Tandberg box, no SIP service IP is configured. I was able to make a SIP from Ekiga 2.x to Tandberg. When the call is set up. Tandberg showed the caller SIP address is a...@w.x.y.z, where abc is my computer hostname and w.x.y.z is caller's IP. But call made from Tandberg to ekiga failed. Interesting.. I did the test particularly on SIP. For H.323 I can use Netmeeting, which is pretty stable. And all I have to find out whether two SIP clients can talk with each other without registering to SIP server. Otherwise I need a separate SIP server module running in my LAN. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
